You are viewing bramcohen

Thu, May. 19th, 2011, 09:16 am
Practical Cryptography Corrected

The book 'Practical Cryptography' is perfectly good for giving an overview of basic concepts in cryptography, but its immediate practical advice to implementers is not terribly to the point or accurate. Here is much more to the point and accurate advice.

  • For a block cipher you should use AES-128. If you don't understand your protocol well enough to know whether there are birthday attacks on your keys, you have bigger issues. (Shame on Schneier for still trying to revisit the AES design competition by yammering on about Twofish.)

  • For an encryption mode, you should always use CTR, and always use a nonce of zero, and never reuse keys.

  • For a hash function, you should use sha-256 until the winner of the sha-3 design competition is announced, and then you should use sha-3.

  • You should always do encryption as a layer outside of authentication.

  • For entropy, you should always do whatever the Python os.urandom() call does on the local platform.

  • For a data format, you should use JSON. (Not XML!)

  • For an RSA exponent, you should always use 2. Technically that's Rabin-Williams, and requires slightly different implementation, but that actually works in its favor. Rabin-Williams has a reduction to factoring, RSA does not.

  • You should never use the same key for both encryption and authentication. If you need both encryption and authentication, you should use two keys. One for encryption, and one for authentication.

  • If you're going to be using RSA, you should learn about encoding for it! This is by far the most historically error-prone part of crypto protocols, and Practical Cryptography bizarrely doesn't even mention it as an issue.

  • You should not parameterize your protocols! That just creates compatibility problems. If necessary you can parameterize it by having two values, one good for the next twenty years, and one good until the end of time, but key sizes have gotten big enough that skipping that first one should be the default.

Maybe someday Schneier will write a book which I can recommend to people who are getting started in cryptography, but I'm not holding my breath.

Are you a good programmer? Try this coding challenge.

Fri, May. 20th, 2011 03:14 pm (UTC)
lensassaman: I almost entirely agree; some nits:

I usually recommend e=2^16-1, but as you pointed out, you're really saying "don't use RSA, use Rabin-Williams."

Ian brought up some of the issues with Authenticate-then-Encrypt; frankly, I'm a fan of the way we handle it in RFC 4880, with the user-verifiable authentication, then encryption, then message authentication.

So, it looks like the only remaining thing I have an issue with is your comments on parameterization; I strongly argue that one should design one's protocol in a parameterized fashion, but provide only one option per needed component. E.g., you need a hash function; fine; design your protocol such that it supports multiple hash functions, but only specify SHA-2. By building parameterization into the protocol, transitioning to SHA-3 becomes a much less painful process.

I say this in part because of the awful experience of transitioning to 160-bit hashes after assuming MD5 in a non-parameterized fashion. Parameterization does not automatically imply multiple choices.

Fri, May. 20th, 2011 04:36 pm (UTC)
bramcohen: Re: I almost entirely agree; some nits:

Funny how I'm getting the most pushback about authenticate-then-encrypt, when it's a point where I basically agree with what Practical Cryptography says.

Having a generic handshake at the beginning of a protocol where dictionaries are exchanged to help with future upgrades is a very good idea, but I don't think that making specific hooks for particular upgrades beyond that makes life any easier in the future.

Fri, May. 20th, 2011 08:10 pm (UTC)
monocular35: Re: I almost entirely agree; some nits:

Haha, I was going to complain that they actually do recommend AtE, except they hem and haw for a couple of pages first.

Then I was going to ask how many books published in 2003 recommend (or even mention) JSON, but then I took a look at the second edition of Practical Cryptography, which was renamed to Cryptography Engineering for some reason, and it still recommends XML. Whoops.