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

Jon Callas jon at callas.org
Fri May 6 15:05:36 EDT 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> 	I have a question about the WhatsApp protocol. On page 6 of the WhatsApp Security Whitepaper, they describe their end to end encryption for media and attachments. To support encrypting in AES-CBC mode, they generate an ephemeral 256 bit key and a 128 bit IV. Then they go further and generate a second 256 bit ephemeral key for calculating the HMAC-SHA256. 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.

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.

Here's an example of a vague reason. With RSA, since decryption and signing are the same operation just using the public and private keys, using the same key for both turns each operation into an oracle for the other. I'm not sure that there's ever been a non-contrived attack, but there you have it. 

For Elgamal, there are generators that are desirable for performance, like 2. g^x is convenient to compute when g is 2. This is a fine generator for encryption, but trivially broken with signing. So don't use your encryption key for signing. In this specific case, it's also why people will say it's best not even to do Elgamal signatures. DSA, for all its own issues (nonces, hold on to that thought), is a better choice for an orthogonal reason -- signature size is proportional to the size of the hash rather than the key.

In symmetric land, particularly with AE modes and constructions, the weak reasons are that there are proofs of security that assume that the auth key and crypto keys are independent. If you do that, you don't have have to prove anything about the mixing. So it's a weak thing in that have statements about security if you're using the same key in different places. It might be secure, but we don't know. It might also blow up in your face.

Then there are the strong ones, where there is an actual attack on one part from the other. There are a whole lot of these in various places. In particular, this happens because we consider auth keys to be less valuable encryption keys for a lot of good and bad reasons. 

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. 

This leak is somewhere between irritating and fatal to them. Let's suppose that the leak makes it so that we can know that Alice's message N is broken.  Well, we were going to learn that anyway, most likely, because it's going to get a retransmit. It's interesting, but not overly useful. Also interesting but not overly useful is that if we see a good message whiz by us, but then get retransmitted, we learn something about where the noise in their comm channel is happening. 

On the other end of the scale, if they're using the same key, the auth leaks turn into crypto leaks. In the random case where they leak the auth key, we can decrypt their messages. In the case where we learn *part* of the auth key, we learn part of the crypto key and thus get an advantage into decryption. These auth errors might turn an intractable crypto break into a tractable one. And of course, if we end up learning the crypto+auth key, we can impersonate either of them to the other, and gain all the fun from that you can imagine.

Beyond even this, we now have an *incentive* to stop being a passive listener and start injecting auth faults into the system. There's a systems break that happens because of bad key hygiene that escalates something unfortunate into something catastrophic, and potentially subtly catastrophic.

Here's a slightly differently contrived thing. Key reuse, as you know, is bad. It's sometimes necessary (like with block-level disk encryption), but it's never desirable. Sometimes it also just happens for one reason or another. And also often there's the attacker-level problem of how do you know that a key was reused? If you consider Counter Mode and key reuse, then known plaintext leads to a plaintext leak on key reuse, even.

Well, if they're generating a public parameter like an IV/nonce deterministically[1] from the key, then you're giving away a key reuse because the IV is often a public parameter. At the very least, an IV reuse broadcasts a reused key and tells the attacker where to look, and in some systems, like GCM, an IV reuse is far, far worse than a key reuse.

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.

	Jon

[1] I'm using "deterministically" in an affected manner. You know what I mean.
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.0 (Build 9060)
Charset: utf-8

wsBVAwUBVyzrAvD9H+HfsTZWAQhAOgf9GVKaxSsz5fIlP6q5Ozpt6ZsZgml6NCin
TsAMnoB6OU5YeaSGMoT3xWBI0jkNY/ep31czVPmLoyLArpZbP5waD5g5anoNNb3x
2nPFPBSX0eVZSURmEdE7dQ+GCh8oiOxlppy17bK6WaybWbcebrwNTVNzDAvR8pj6
oVLoAJS5ZpEAzKDLv05bX0TiPqNqedWuIT6wDGi5QbEHBVLXnltQf4gPVxjyoRyp
YMcy6kPYPoAIk+LhQMb4OsLh9GyJIW1udiSPdFHviW8os4Nopk12CoDbablGOGwz
fnxwowHVyHb8u7+ZHoN/r7devNtpPVJpa9TOKdcQfSJ4LyWa409EXw==
=fU6X
-----END PGP SIGNATURE-----


More information about the cryptography mailing list