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

[Andrew Donoho]

> On May 6, 2016, at 19:09 , Jerry Leichter <leichter at lrw.com> wrote:
> 
> 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.



Jerry,



	Yes, I was imprecise. Clearly, the two keys need to be independent and mutually uncorrelated. As my mobile device has a high entropy pool, I’ve gotten into the habit of using it in place of more subtle constructions. I suspect the WhatsApp people have a similar habit. It is probably much cheaper to generate the two keys and IV than to run things through a hash.



> 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).



	The above technique gives me a simple mechanism to evolve my keying strategy moving forward. Thank you for sharing it.



> Is this "as secure" as using different random E and A?  Clearly not.  

> In practice ... this is rather unlikely.

> That avoids adding any new things you have to trust - but perhaps increases the likelihood of an interaction between your hash and encryption functions.



	These are the kinds of properties you crypto algorithm folks must assert/prove. My job is to ensure I don’t violate your conditions of use. As I am coming to learn though, there is a largely undocumented art in applying crypto functions. A few rules of thumb seem to guide me well: 

1) Use just a few crypto algorithms. Learn how they interact. Isolate dependencies.
2) Many crypto sins are made moot by using another random number.
3) Don’t trust yourself. You'll never see the attack coming. Ask friends for guidance.



> 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.



	My big takeaway is that this is a mechanism that might help me enhance the security of my system over time. My main key can be migrated behind a hash function in a future version of my app without having to redistribute keys. While that won’t fix my sin of using the key for both encryption and authentication on earlier data, it will stop the ability for new messages to contribute to discovering the key.

	Thank you for sharing your insight.



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

New: Spot marks the taX™ App, <http://SpotMarksTheTaX.com>
Retweever Family: <http://Image.Retweever.com>, <http://Retweever.com>

"To take no detours from the high road of reason and social responsibility."
   -- Marcus Aurelius