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

Andrew Donoho awd at ddg.com
Fri May 6 16:57:25 EDT 2016


>> On Thu, 2016-05-05 at 13:40 -0500, Andrew Donoho wrote:
>> 
>> As the first key already has a
>> significant amount of entropy and is only used once, why isn’t it
>> reused for the HMAC-SHA256 calculation? On the face of it, it looks
>> redundant for a single use key.




Ben and Jon,



	Thank you both for sharing your insight.



> On May 6, 2016, at 11:23 , Benjamin Kreuter <brk7bx at virginia.edu> wrote:
> 
> 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.

	Of course, making sure that the HMAC key is truly independent of the signing key is also possibly a problem. For example, when I prepare to encrypt a file, I can easily imagine naïvely creating the IV, AES key, and HMAC key sequentially. If you can predict the PRNG, then the public IV gives you some clues to the keys. Hence, inverting the order and, to guard against prediction, allocating an IV to throw away before creating the ephemeral keys has some value. Or am I being too suspicious about the low levels of entropy in my PRNG. (In my case, these keys will be generated on a mobile device. Mobile devices tend to have, from what I can see, some of the best entropy sources in systems today.)



> On May 6, 2016, at 14:05 , Jon Callas <jon at callas.org> wrote:
> 
> The concept here in a broad form is called "key hygiene." The idea is that you should only use a key for one purpose. If you're going to encrypt with it, you shouldn't also use it for integrity. 
> 
> Sometimes there are vague reasons for it, and sometimes specific. Sometimes there are weak reasons, and sometimes there are strong reasons.



[An excellent discussion of why to implement key hygiene snipped. Thank you for sharing that.]



> Let me contrive a hypothetical. Suppose Alice and Bob are talking and we're passively observing. Let us also presume that there's some sort of slow leak of authenticity through -- whatever. Timing, passive oracle, whatever. But let's suppose that they are on a noisy line and because of something we can learn the auth key with ~2^30 retransmits. 




	In the case of WhatsApp, these ephemeral keys are generated per file being transmitted. Hence, I think this attack is largely moot. But I take your point. Which is: develop good design habits that are robust when your protocol is used in unforeseen ways.



[Further snippage. Blame Tamzen/Perry for my editing of your fine answer.]



> So all of this is why key hygiene is a good thing. There are plenty of places where it doesn't matter. In a perfect system, it shouldn't matter. But in real systems it can and does matter, from a crypto standpoint as well as engineering standpoints. It's good practice to get into. It's probably okay to use the same key a lot of the time. But it's always okay to have two separate keys, and sometimes maximally bad not to. There are many subtle issues that you just don't have to worry about if auth keys and crypto keys are independent.



	This pattern of inserting randomness into a system's design is clearly key. My current system, which emits less than 5K messages per user-year, appears to emit orders of magnitude fewer messages than are necessary for your attack. Nonetheless, I’ll be revising future versions to have a independent authentication key.



	Again, thank you both for sharing your time and expertise.



Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
awd at DDG.com, +1 (512) 750-7596, twitter.com/adonoho

Essentially, all models are wrong, but some are useful.
	— George E.P. Box





More information about the cryptography mailing list