Library

Last year I ran across this 2009 post by Bruce Schneier entitled “Another New AES Attack“. It got me thinking about and dissecting the Rijndael algorithm which most of you know as AES (Advanced Encryption Standard). This research surprised me, I found that AES has only three variants. These variants are best known by their key sizes of 128, 192, or 256 bits, but they also specify the rounds, or iterations, made during the transformation. The surprise was the underlying algorithm, Rijndael, has no such limitation. Funny enough this is exactly Schneier’s recommendation from the above article:

… At this point, I suggest AES-128 at 16 rounds, AES-192 at 20 rounds, and AES-256 at 28 rounds. Or maybe even more; we don’t want to be revising the standard again and again.

Then today, two years later, another related post from the same author “New Attack on AES” with the same recommendation.

So what does this mean for me and my software?

Well that depends on how sensitive the data is, how long you intend to store it, and how accessible is the stored cipher.

For instance, SSL uses AES-128 after the initial key exchange; however, this does not mean SSL is broken (ok it is, but for other reasons). Since the SSL session key is short-lived, and the data is not stored anywhere (well, not suppose to be), there really isn’t a major concern here. The same is likely true even for your own software, transient data encrypted for short periods of time.

Well wait a minute you ask, “what about those credit cards I have encrypted in my database?” Frankly this still isn’t much of a concern. Credit cards actually aren’t that ‘sensitive’ to begin with, they get compromised all the time (Thanks Sony). Further most credit cards expire within two years, which is about how long the most gratuitously over optimistic attack could occur. So no, I would not reinvent the way you store credit cards. I would however make sure your not storing the encryption key in that database :)

So why would I concern myself with this? Well we are well within the era of SaSS/Cloud computing and often enough we need to encrypt and store data for our users. So we have to ask ourselves how sensitive this data is, how much damage can be done by accessing the data. Thinking of services like LastPass and 1Password, they store potentially sensitive data for long periods of time. Of course if I were going to attack those services, I’d likely go after the pass phrase, not the raw crypto key, but still. These services could easily benefit from extended rounds of Rijndael algorithm.

Another classic place to improve is locally encrypted storage. This was what I was playing with when I wrote the ModifiedRijndael class. It allows you to specify key sizes from 128~4k in 64bit increments, and any compatible number of Rounds. So if you want to play around with unlocking the Rijndael algorithm from the AES constraints try it out:

        ModifiedRijndael r = new ModifiedRijndael();
        r.BlockSize = 128;
        r.KeySize = 128;
        r.Rounds = 20;
        r.GenerateIV();
        r.GenerateKey();
        ICryptoTransform alg = r.CreateEncryptor();

Sum it up: The above articles and information is really only just that right now, information. I don’t see many people needing this kind of added security when encrypting data. A classic place for me to want something like this would be when uploading a file to something like DropBox. The problem is, I would likely generate the key from a password. The password is much easier to attack than the AES-128 algorithm. So until we can solve the password entropy issue there just doesn’t seem like much point in moving beyond AES for *most* cases.