ImperialViolet

We're at a strange point in cryptography at the moment. Two of our foundations are mortally wounded and no one seems to have a good answer to either of them. Our unfortunate foundations are SHA1 and AES.

Lots of people have debated about how important the break of SHA1 (and MD5 et al) really is. These two postscript documents with the same hash are the latest round from the “it's important!” crowd. The defense is pointing out that the postscript files are actually programs which introspect themselves and you can never trust such a document etc.

But the point is that you now have to sit down and consider if the way that you're using SHA1 is weak. That's morally wounded. A good hash function shouldn't need thought to use.

Next up, AES. The blow was delivered by DJB in this paper. I've not seen many people talking about it, but it seems to me that you now have to sit down and consider how you're using AES and how much timing information you're leaking each time you use it. That's also mortally wounded.

So, where do we go from here? (And, if you can hear the tune as you read those words you're a wise man )

Why one should never use libgcrypt

I've been using libgcrypt in a Tor related project and I must say that it's terrible:

• The public key interface is so terribly abstract they've implemented S-expressions (in C) via which you pass all the data. It's only two algorithms! The abstraction layer is several times thicker than the actual useful code!
• (yes, they do have an alternative interface to the public key code but it's little better and restricted. I'm now using the MPI code directly and implementing RSA myself. The MPI code, at least, works.)
• None of the hashes can be used progressively. Once you call read() you can't update them any more.
• Counter mode is a joke. I spent about three hours tracking down a bug only to find that their idea of counter mode was completely wrong. I've sent a patch, but no reply yet.