1. Statement of Purpose

There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files.

-Bruce Schneier, “Applied Cryptography”

Kid Sister Crypto is a project dedicated to the idea that there are times when you don’t need, and are unwilling to pay for (in terms of code complexity and computational cost), crypto strong enough to defeat major governments. Sometimes, crypto systems only strong enough to defeat your kid sister are sufficient. Examples of uses that fall into these categories are hash functions for data structures and simple pseudo-random number generators.

But that even in cases where “kid sister” strength crypto is sufficient, you don’t want to use an algorithm designed by some dilettante with no knowledge of cryptography or even awareness that a cryptosystem (however weak) is what they’re designing- it is much better to use a system designed by some dilettante with some knowledge of cryptography, and doing so explicitly as designing a crypto system. It’d be better still if a real cryptanalyst were to do this, but they’re all busy inventing (and breaking) major-government-proof ciphers, so this is what you get.

The name is picked explicitly to remind everyone that this is not a cryptosystem that will protect you against major governments.

Continue Reading »

Popularity: 17% [?]

Bet you didn’t see that coming!

I’ve decided that I’m going to punt on the pipeline stuff and declare what I have for JConch to be the 1.0 version. I’m going to spend some quality time getting the system into Ivy, and then I’m going to declare JConch done until I hear otherwise. I’ve created a few issues over at the Google Code page — if there are other enhancements you’d like to see in JConch, that’s the place to put them.

This is the last post I’m going to do here about JConch — from here on out, I’m going to be posting all this stuff to the GoogleCode wiki or the mailing list. If you want to get updates, subscribe to the Google Group:

Subscribe to JConch Discussion Group

Email:

Visit this group

You can also subscribe to the RSS feed for the group here.

Popularity: 3% [?]

(Since I and the update-bot are the entirity of the JConch Discussion Group, I’m announcing this here.)

I just released JConch 0.3 over at the Google Code page for JConch (API here). This includes introducing the type-safe CacheMap, moving the old-school non-generic version over to ObjectCacheMap, and moving into functional Groovy land with the oh-so-succinct-in-usage GroovyCacheMap. With all those changes, I updated the CacheMapExamples wiki page quite a bit, including sneaking the crazy-slick Groovy usage way in at the bottom.

Also in this release was the typed MultiKey stuff, with its blatant and shameless violation of the Liskov Substitution Principle. I put that in mainly to make user code slightly easier when people are working with the CacheMap.

I’ve been screwing around with the pipeline stuff a bit, but don’t really like it quite yet, so we’ll see how that works out.

Popularity: 2% [?]

One of the things that has always fascinated me about dynamic languages is how you go about testing them.

See, the trick is that when I write a closed implementation of some sort — whether it be a closed class or module — I’ve got some concept of the boundaries that my object’s state could be in. I’ve got a system which is locked in, probably with some state-machine-like semantics. So my unit tests wrap the flows that I understand, and verify that trying to violate those flows fails in some known way, and then I have reasonable confidence that things are good.

But dynamic languages that offer open implementations (like Perl, Groovy, and Ruby) really shoot that approach in the foot. Anything can be touched, and anything can be changed, and there’s nothing you (the original implementor) can do about it. This means that your unit test suite is going to be more incomplete, in the sense that your unit tests will exercise a much smaller portion of the field of possible ways in which your code might be used.

Worse, a common pattern in dynamic language development relies on external intervention in order to have it make sense. It’s extremely postmodern, actually: the code is gibberish without a context, making calls to methods and variables that simply don’t exist unless you have some kind of intervention. At this point, efforts to unit test are doomed to failure, because without the external intervention, there is nothing meaningful to test. With the external intervention, you’re really talking about an integration test.

Any interesting example of this is the particular case of controllers and views in Grails and Rails. Controllers are notoriously difficult to unit test, because they’re riddled with dynamically provided methods. Efforts to solve this via mocking are really treading on dangerous ground.

My solution right now is to not unit test them at all.
Continue Reading »

Popularity: 9% [?]

I want to share this article with everyone. In addition to being exceedingly well written and cogent, it also says things I’ve been trying to say for years- and makes me want to say things I hadn’t thought of before. Go read it, trust me.

Unfortunately, this article made my mind want to metaphorically jump on the horse and gallop off in all directions, so the ensuing post may not be as coherent as it might be.

Continue Reading »

Popularity: 8% [?]