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 12:52 pm (UTC)
I see. But there many scenarios where not reusing keys is impractical. And even if you never reuse keys, why not use a random nonce?
As a I said, encrypt-then-authentication is the only way mathematically proven to work with any secure encryption and authentication schemes. See the proof in, e.g., "Introduction to Modern Cryptography" by Katz & Lindell. If you use authenticate-then-encrypt, you may get an insecure scheme even if using secure cryptography & authentication schemes. (It may be secure for particular schemes, but it's much more safer to use the route that is guaranteed to work)
Fri, May. 20th, 2011 04:34 pm (UTC)
There are two meanings of 'key', one is a key that you use for encryption, the other is an input into CTR mode. You can renegotiate the input of CTR mode for each time you use it, using the key for encryption to do that each time.
You could use a random nonce, but it complicates things a bit and gives you more bits than you need - one-time key has 128 bits, random nonce has somewhere south of 256 bits.
I'm fairly skeptical of proofs of security, because historically they haven't really demonstrated the things they claimed reliably, and every time I've seen a protocol which tries to do authentication outside of encryption it's a mess, and I put a big premium on simplicity and analyzability when it comes to protocol design, because those have a real effect on likelihood of breakage.
Sat, May. 21st, 2011 01:17 pm (UTC)
Sorry, I don't follow you. CTR has 3 inputs: the messge, the key, and the nonce/IV. Are you calling the nonce a key? It doesn't make sense to me, because the nonce is public, a key is not.
I understand that not reusing keys and using the same nonce can be secure, but it is impractical.
I agree that proofs may be not enough, but they don't hurt, either. If a have a choice between something proven secure and something that is probably secure, but may be not, it's a clear choice to me.
If the protocols you've seen are a mess, then it's the protocols fault, not of the technique.