Practical Cryptography Corrected

[bramcohen]

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

Comments

What are the guarantees of Python os.urandom?

[ext_565820]

Can you explain/elaborate on the guarantees of Python's os.urandom()?

Re: What are the guarantees of Python os.urandom?

[bramcohen]

Mostly that it actually calls whatever the appropriate underlying native API is.

[ciphergoth]

I would directly recommend an AEAD mode like GCM rather than even mentioning CTR mode.

[bramcohen]

I still view those as too complicated and speculative to recommend, given that the CPU overhead of separate encrypt and hash passes generally isn't a bottleneck.

[shinigami31]

The CTR nonce MUST be random. It cannot be the same value, or zero as you have suggested. Doing so leads to chosen-plaintext attacks.

Authentication should be done after encryption because this is the way that can be proved to work for any encryption and authentication schemes.

[bramcohen]

If you never reuse keys, as I recommended, then the nonce can be fixed. Trying to reuse keys and change the nonce is just doing the same thing, where the nonce is really acting as a key, and with a whole lot of bits of security removed because of related blocks being used throughout the message.

I have no idea what 'proved to work' you're babbling about.

[shinigami31]

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)

[bramcohen]

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.

I almost entirely agree; some nits:

[ext_367222]

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.

Re: I almost entirely agree; some nits:

[bramcohen]

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.

Re: I almost entirely agree; some nits:

[monocular35]

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.

'that's entropy and I hope that you're all down with it'

[themusicgod1]

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

Disagreed. If you need entropy, you should use real random numbers. If that isn't waht os.urandom() does on your platform, you should rewrite your platform to make it do that.

If that incurs too much overhead you should talk to your isp, random.org, your local network admin, the person who designed your computer or whatever. But if you need random numbers there is a source for them.

( bramcohen -> jwz -> exoskeleton -> masuimi -> ruthanolis -> themusicgod1 -> caponex -> pope_guilty -> bramcohen )

Re: 'that's entropy and I hope that you're all down with it'

[bramcohen]

Wow, that service is one truly awful security horror which it never even occurred to me someone might do.