Phil Zimmermann: Beware of Snake Oil Crypto (1997)
philzimmermann.com
philzimmermann.com
It's a credit to Zimmerman's article that he doesn't leave it at "don't write your own block ciphers", adding that you need to understand block cipher modes (we should stop calling ECB mode "ECB mode", by the way, and start calling it "the default mode"). But obviously, this 1997 article doesn't nearly cover the bases on all the other things you have to do correctly to not end up with trivially breakable cryptography. A lot of those things weren't even known to the public in 1997.
An even more important point is that Zimmerman is talking about cryptography implemented in its strongest, safest venue: data at rest. As implemented by most developers today, crypto ends up in a far more exposed venue: one where a server holds a secret key and uses crypto not to protect a file but to enforce policy. Despite being the 2011 common case for crypto, this is a far harder scenario to get right, because adversaries can devise ways to query the key-holder to learn things about the plaintext, ciphertext, and behavior of the system as a whole.
My advice: don't trust crypto at all outside of TLS, GPG/PGP, and SSH. And know that of those three systems, two were broken relatively recently.
Good advice, but they weren't broken, just mistakes in their implementation.
That bugged me on two levels: first, the idea that there haven't been terrible bugs in e.g. SSL3, and second that an implementation bug means "just upgrade OpenSSL", when it's more like "the discovery of buffer overflows and attendant years of chaos".
I am jumpy about this topic, though.
So let me just say that while key management is hard, even if you stipulate that your key management is perfect, you are probably still boned. The simple task of exchanging real time messages between two parties with secure keys is treacherously hard to implement.
But read them to learn how to break cryptosystems, and then go do that. Don't read them and then try to build something. They're missing details too.
1) don't do the modern day equivalent of an Enigma-style 'cillies', ie doing something that reduces the entropy of your key generator (not using the full range of possible values, not having a random distribution of values, etc)
2) Make sure that the decryption time does not vary with the number of correctly guessed bits of the key, ie don't stop a decryption attempt in the real system if you discover that the decryption must be wrong part way through.
3) Make sure that your randomly generated keys don't ever generate keys that create a degenerate crypto text
4) Make sure that you don't use a key for longer than it's cryptoperiod
that's just a small sample of the gotchas that can ping you. And in that list, I'm only worrying about plain decryption of the message, without worrying about 'minor' details such as identifying that a party is who they say they are, man-in-the-middle attacks, replay attacks (resending a recorded encrypted message later on, to open access to something), injecting messages into the communication and so on.
Second, even for data at rest problems, _Applied_ is a terrible resource.
Just get _Practical Cryptography_ and burn your copy of _Applied_. Schneier co-authored _Practical_. It's a great book.
(I haven't spent that much time on crypto, and so as a general rule we don't do implementation projects).
Also, it's my impression that start of the art papers aren't really necessary to start off with. The implementation errors people make in their code are flaws that have long been published, sometimes for decades.
Best advice: do deep research on TLS. For every feature, do a directed search of the literature and do experimentation to try to figure out why that feature is there. Most of the features in TLS exist as a countermeasure to some attack. Follow this tack all the way down the stack, starting with the high-level protocol features and working your way all the way down through the block cipher modes and configuration that it uses.
TLS has definitely had more severe issues, but then, it's also the most widely deployed (so undiscovered flaws are more likely to be discovered). On the other hand, it's also solving the most complicated problem of the three.
Give it time; we'll find something horrible out about ISAKMP.
And I personally think we all own Mr Zimmerman a debt of gratitude. I don't think I could have handled the stress of what he had to go through with the US Government.
Today, your reasonable choices for block cipher modes are CTR and CBC.
And: (If you have a library that does any of the "authenticated modes" like CCM, OCB, GCM, or EAX, your reasonable choices are those 4 constructions, all of which are based on CTR mode.)
But your comment gave me hives, because CTR mode is in its most simple application (no parallel, no precomputation, no seeking, no lossiness) already easy to spectacularly fuck up, and some of the things you pointed out as benefits of CTR come with additional pitfalls.
Finally, what is a "default" in a standard is different from a "default" as provided by a library. ECB is the "default" because (a) it usually is the default, and (b) it requires the least amount of configuration. In 2011, it is still sadly common to see trivially breakable ECB in new apps, and that's because crypto libraries are structured in ways that make ECB the de facto default.
But even then with these great libraries there is much room for mistakes, openssl is just horrible to use IMO.
The good kind of crypto library is Keyczar. Keyczar removes degrees of freedom; it says, "you don't tell me what block cipher to use, and you don't remember that your messages need a MAC, and you don't choose the order operations happen in, and your keys are all going to be from a CSPRNG, and you'll use this keystore, and that will be that". There are a very few other libraries like that (Guttman's cryptlib is another).
Unfortunately, nobody uses libraries like that. They use OpenSSL (via their language's bindings to it) which seems to work until it blows up in their face during a pentest.
My best advice is to use Bouncycastle's PGP implementation, which again removes all the degrees of freedom and has the benefit of building on very well studied constructions (poorly regarded constructions, but survivors nonetheless).
I mean, I've done my homework: I know enough to not call myself an expert, yet also know enough to avoid every crypto-algorithm like the plague until I've thoroughly investigated it and its "competitors."
In case this is what you were implying: it is absolutely not the case that the big problem with OpenSSL is that it'll let you use Camellia in ECB or 512 bit ElGamal. The problem is that there are (a) more things you can do terribly wrong with AES-256-CBC than there are things you ar likely to do with wrong with, say, C memory handling, and (b) things you have to do well beyond encrypting soundly with AES-256-CBC to make your system work as a whole.
I don't know enough about even my own countries' legal systems, and certainly not about America's. So my question is: Supposed you got sued back then, had to pay, and now try to get the money back, because the patents the suit was based on were invalidated by prior art. Would that work? (Sorry, not a crypto-question at all, more like a legal one.)