Over a relatively short period of time, I’ve noticed a trend in the design of infrastructures that involve mechanisms for carrying out some cryptographic goal. Failure abounds, and it’s obvious why. Sometimes, the system is designed by someone who’s as qualified to do the job as a blind chimpanzee is to perform quadruple bypass surgery while riding a unicycle in rush hour traffic on I-85. You can’t expect a fruitful outcome, to say the least. If you can’t make the correct diagnosis, you can’t treat the problem at hand, which finds most of these shoddy systems lacking in fundamental components, because the appropriate design goals were never established. This leads to horrible design decisions, which are usually the result of sheer incompetence.
What I’ll outline below isn’t, by any means, an exhaustive list of everything you’ll ever need, given that requirements change along with each scenario, but this covers a teaspoon full of some important components that require themselves to be the result of good decisions. I’ll mix the practical components with a little theory, and bombard you with some indispensable resources. If you’ve ever wanted a simple, opinionated answer on how one should begin designing a secure channel, this’ll point you in the right direction. To keep things simple, consistent, and predominantly standards-oriented, the following advice is centered about a block cipher – the AES.
Of Key Lengths and Security Levels
I’ll start things off with something I can’t really blame on everyone, since there are environments that are so tightly constrained that every little “bit” is noticed; that is, symmetric key length. If you come to the cryptographic community for advice regarding a conservative key length, the answer you receive will likely be two-fold. First, you’ll hear “128-bit” as a good value, but we’re not talking about the key length itself. For example, one might say something along the lines of, “Use a 256-bit key and claim a 128-bit design strength.” Look at the “design strength” as the level of security you expect. Some cryptographers will design block ciphers based on this conservative philosophy, while others won’t. I believe it’s good advice, so I recommend following it, if you can. Just as I implied at the beginning of this paragraph, implementing this in practice might not be a viable solution, due to tight constraints, so strive to get as close to 128 bits of security out of your 128-bit keys as possible. As a general proverb that Confucius didn’t say, but probably could have pulled off, “The superior developer who wants n bits of security will use 2n bits of key material.” Don’t worry; you’re not inferior if constraints say you can’t, but do your best.
The Flemish. A fish. A snake. A choice to make.
Time and time again, I hear the lay developer state, in a breath of confidence, “I prefer Twofish,” or, “I like Serpent the best.” My canned, interrogative response is usually, “Would you care as to elaborate why?” I get all sorts of answers, from, “Uhh, I just do,” to, “AES is insecure. That’s why the NSA allowed it to become a standard.” (I’ve already thrown in two cents and a nickel about why the latter answer is unfounded and speculative, and why I believe the standardization of Rijndael, along with the entire AES competition itself, has been a success, in terms of building the cryptographic character of Rijndael, as well as leading us in the right direction for selecting new primitives to serve as standards.) I’ve long been an advocate of numerous design principles exhibited by Twofish, and Serpent was, without a doubt, the figurative panzer of the bunch; it’s with utmost respect that they’re included in my batch of recommended block ciphers for when you can’t use the AES or when niche environments call for something else. But, when you can – use it. It’s simplistic, elegant, and has more cryptanalysis thrown at it than any of the other finalists – Twofish and Serpent included. Not only that, but it’s withstanding that cryptanalysis. Nobody can blame you for using it. It’s a solid way to preserve message confidentiality.
Manipulating Is Often Worse Than Divulging
Already anticipating the answer, with my retort coiled and ready to strike, one of the first questions I’ll ask a developer is, “What are your security goals for a channel between Alice and Bob?” Fortunately, a smidgen of hope exists, thanks to those who’ve done their homework. All too often, though, I’ll hear, “All we care about is that nobody can read the traffic between Alice and Bob.” How ’bout, “No, that’s not all you care about.” At least, it’s not all you should care about. This issue nips at the heels of the one thing folks will likely remember me by, as far as my cryptographic endeavors go – the need for message authentication. Heaven knows I use it excessively, but this is one virtue I lose no sleep over proselytizing about. Some folks mistakenly look at ciphertext as plaintext that has been sprayed with OFF! repellent, such that any curious, malicious mosquitoes (malsquitoes, if you will) would be quickly deterred from any potential attempt at latching on.
Unfortunately, S. C. Johnson & Son isn’t in the cryptography business, and even when using a good block cipher mode of operation, such as CTR or CBC, ciphertext is still malleable. It follows that being able to perform controlled alterations to ciphertext, where the ciphertext decrypts into something meaningful, is, in many cases, even more severe than simply being able to read a ciphertext’s corresponding plaintext. To remedy this, a good solution is CMAC, a block cipher-based MAC that preserves integrity, and works quite nicely with the AES. To be one of the most important aspects of a secure channel, this goes unnoticed far more often than is comfortable to accept. Put it at the top of your list.
Looking For A Good Recipe
Many a developer is capable of grasping the mathematical theory of cryptography, or at least understanding the reasons for my suggestions above. If they were to be summarized, with a little extra spice added, it might sound a little somethin’ like this:
- Use AES in CTR mode for preserving message confidentiality.
- Use CMAC-AES for preserving message integrity.
- Encrypt first, then authenticate.
- Use 256-bit keys for both.
Introductory literature on cryptography doesn’t immerse you into the more intricate notions of cryptographic security, but if you were to ask me what properties to expect in an encryption plus authentication scheme, I’d tell you that satisfying IND-CCA2 and INT-CTXT is a mighty good start. If we compute a SUF-CMA MAC, like CMAC-AES, on the ciphertext of an IND-CPA-secure encryption scheme, like AES in CTR mode, we can achieve the aforementioned properties of IND-CCA2 and INT-CTXT. Obviously, this is the Encrypt-then-Authenticate composition; although I agree with the philosophies for Authenticate-then-Encrypt (AtE), Encrypt-then-Authenticate (EtA) is the easiest to get right – simply put. Simplicity is king, so it’s not a difficult recommendation to make. Wait, wait, wait. “All of this acronym splatter, yet I have no clue as to what it means.” No worries mate. Here you go.
- IND-CPA = Indistinguishability under Chosen-Plaintext Attack
- IND-CCA2 = Indistinguishability under Adaptive Chosen-Ciphertext Attack
- INT-CTXT = Integrity of Ciphertexts
- SUF-CMA = Strong Unforgeability under Chosen-Message Attack
Now that I’ve thrown a wad of terms at you, that can’t be deduced without theory. I’ll point you to some superb reference material, should you wish to connect the “why” to the “what” that I’ve just provided for you. It may comfort you to know that this is a general opinion amongst cryptographers, and has been examined expansively. Substance-wise, you’re about to get your fill of references. In 2000, Mihir Bellare and Chanathip Namprempre published the paper entitled, “Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm,” which I hold to be a seminal contribution to the analysis of how a generic composition correlates to notions of indistinguishability, non-malleability, and integrity. A year later, Hugo Krawczyk established a solid case for the Encrypt-then-Authenticate composition, in his must-read paper, “The order of encryption and authentication for protecting communications (Or: how secure is SSL?).” After digesting this all-you-can-eat buffet of eggs, bacon, livermush, and theory, you’ll be content with placing your bets on the acronyms looming above.
Speaking of acronyms, let’s look at another mechanism for satisfying both confidentiality and integrity that aims in a slightly different direction: EAX. Mihir Bellare, Phillip Rogaway, and David Wagner bring us this authenticated mode of operation that promotes core principles such as – and these are always soothing words to a conservative cryptographer – “efficiency, simplicity, elegance, ease of correct use, and provable-security guarantees.” Mmm mmm mmm. That’s nice. EAX is an AEAD scheme, or authenticated-encryption with associated data; it’s a two-pass scheme, as well, since it makes one pass for encryption, and another for authentication. In essence, EAX is derived from a generic composition construction, dubbed EAX2, with its two keys being collapsed into one. EAX2 instantiates CTR mode for encryption, then OMAC1 for authentication. (Note that the CMAC construction I mentioned earlier is equivalent to OMAC1.)
If, as the designers say, you favor the generic composition approach, then EAX2 is a good selection; as such, EAX makes sense. And not to forget about its icing – it’s free of patents, as well as the intent of being patented. If you’re wondering where this fits in, on my list of recommendations, EAX takes the place of a generic composition that encrypts first with AES in CTR mode, then authenticates with CMAC-AES. Look at it as a hybrid mode that handles both encryption and authentication by employing a block cipher, such as AES. Two figurative birds. One solvent stone. Pigeons and pebbles aside, both encryption and authentication demand being addressed, and properly so, regardless of which avenue your constraints have you stroll down. Use this as a compass. This is only the beginning of a lengthy end, but if you can say you’ve got this down, then you’re makin’ good time.
