[Cryptography] Why two keys? [was: Re: WhatsApp, Curve25519 workspace etc.]

[Jerry Leichter]

>> Typically it is considered bad practice to use one key for two
>> different purposes.  Also the proof of security for encrypt-then-MAC
>> relies in subtle ways on the keys being different, so reusing the key
>> can be insecure -- certainly true for CBC-MAC when the same block
>> cipher is used for encryption.  Entropy is not really the issue here,
>> since the encryption and MAC keys can safely be generated using a PRNG.
> 	The rules of good and bad crypto practice are truly hidden. Ferguson, Schneier and Kohno are leaving some things out. Is there another book I should be consulting for added guidance?
> 
> 	This rule, in particular, makes a great deal of sense. Using a second, independent high entropy key provides a kind of cryptographic “firewall" between the two operations. OTOH, I do not want to get into the habit of Creeping Cargo Cult Crypto. I want to implement the minimum to be secure. More complexity just adds places for lurking errors. Hence, in my system, I’ve just used a single key for both operations.
Note that "additional entropy" is not generally a requirement here.  Mainly what's necessary is that knowing one key gives you no help in learning the other.

A common technique is to derive keys for different purposes from a common master key.  For example, given master key M, you might use E = H(0 || M) as your encryption key and A = H(1 || M) as your authentication key.  H, obviously, has to be a cryptographically secure one-way hash.  M must have at least as many bits as E and A, but could well have more.  But there's little reason to go nuts about this.  0 and 1 are arbitrary - people will often do things like E = H("Encrypt" || M).

Is this "as secure" as using different random E and A?  Clearly not.  Perhaps there's a weakness in H which allows one to get A from E or E from A.  Or perhaps there's some really odd connection between your encryption and authentication algorithms and H, used this way, that allows one to break the combination.  In practice ... this is rather unlikely.

Of course, you now have to trust that H's properties are secure.  You could, as an alternative, build H from a primitive (like your encryption function) in such a way that the security properties of H that you relay on can be derived from the security properties of the encryption algorithm you're already relying on.  That avoids adding any new things you have to trust - but perhaps increases the likelihood of an interaction between your hash and encryption functions.

The main advantage of this approach is that you can easily derive new keys for new purposes without having to generate and securely store new random bits.  The more you can isolate different cryptographic contexts from each other - so that even a leak of a key in one context provides no help in breaking messages in another - the better.

                                                        -- Jerry