Cryptography Engineering: Message Security

I’m in the middle of reading the book Cryptography Engineering. It’s essential reading for anyone writing software that includes encryption, and the 2nd edition that came out last year (2010) revises it for classroom use and self-study, while keeping it easy to read.

Part I introduces the mindset of cryptography (weakest link, professional paranoia, etc.) and the basic concepts (encryption, authentication, digital signatures, attack models).

The math used throughout the book is very light. It doesn’t get harder than abstracted equations and pseudocode. Part of the reason is because approximations are “good enough” in cryptography, or the estimates err on the side of caution. Example: for N-bit encryption, the number of random elements you’d need before a collision (“birthday attack”) is roughly 2^N/2; the actual number is higher, but dividing a number by 2 is good enough and easy to do. (So, an attacker would need to generate about 2⁶⁴ values before finding a collision on a 128-bit key.)

I’ve just finished Part II (Message Security), and thought I’d summarize some of the thoughts and recommendations by the authors.

• A good security level to target nowadays is 128 bits (or higher). This means having a key/block size of about 256 bits.
• There have been theoretical attacks against the AES winner (Rijndael) recently, but the authors still recommend it as the block cipher of choice (because it is fast, a standard, and has no practical attacks yet).
  • The older DES and 3DES shouldn’t be used because its key/block size is too small.
  • The other AES finalists are good options, too. Serpent is very conservative security-wise, but is slower than the other AES finalists. Twofish is in-between Serpent and Rijndael in terms of speed and security.
• The authors recommend using CBC for the block cipher mode, using a random IV.
  • CTR is also a very good mode (and better than CBC in some ways; for example it is a stream cipher, so it doesn’t need the whole message at the start), but it is harder to implement correctly. (Same with using a nonce-generated IV for CBC.)  CTR also doesn’t seem to be supported by mcrypt.
  • ECB is not secure.
  • OFB is similar to CTR, but has some deficiencies. CTR is always better.
  • CFB mode is not mentioned in the book, but according to Wikipedia it’s a stream version of CBC, so that could be good.
• For hash functions, the authors said that their long-term recommendation would be the winner of the SHA-3 competition. Unfortunately, the winner won’t be chosen until 2012.
  • In the meantime, they recommend using a function from the SHA-2 family — SHA-224, SHA-256, SHA-384, or SHA-512. Unfortunately, these all have known weaknesses. These weaknesses can be mitigated by using an iteration of the hash function they call SHA_d, or by using SHA-512 and truncating the output to 256 bits.
  • MD5‘s bit size is too small and is vulnerable to attacks, so it shouldn’t be used.
  • SHA-1 has a size of 160 bits, so it is also too weak for modern systems.
• For message authentication codes (MACs), the authors recommend HMAC using the SHA-256 (or better) hash function.
  • The standard GMAC is faster but only has 64 bits of security.

The rest of Part II discusses the implementation of a secure channel for transmission, and specific implementation issues with securing hardware and software.