Derived Shared Key vs Distinct Keys?

Question

I've seen a lot of 2-party applications that derive a shared key from distinct keys created by each party.

Why is this technique employed? Would it not be better to use those two distinct keys for each party (where both parties know both keys, but each key is used to encrypt and decrypt the messages of the party who created it)?

As an example, I've seen socket servers that use this. Assume 2 servers are running. Both servers send a random 256-bit key, encrypted with the other's RSA public key to each other. This leads to 2 distinct keys that both servers now know. Then both servers XOR these two keys together to derive a common key. Why this is done instead of using both keys in the way I described above?

Answer 1

For your example protocol with RSA-exchange in both directions, combining both keys to one protects against some weaknesses:

• By combining the random numbers from both sides, the result is really random, even if one of them has a weak or compromised randomness source.

• If one of the private keys is compromised, in your protocol the attacker can read all the data flowing to its owner. If we combine the random data by XOR with the other random data to derive the session key, the resulting key is still unknown to an attacker, and she can't read anything.

Of course, for the actual encryption (and authentication, i.e. a MAC key), you should then use not this combined master secret directly, but derive different keys for the different purposes from it. This avoids some replay attacks.

Answer 2

Generally, these protocols are used to generate symmetric keys from asymmetric keys. You start out with asymmetric keys because that's the only way one party can talk to another party securely without pre-arranging a shared secret. You want to wind up with a symmetric key because only a symmetric key is suitable for bulk or stream encryption.

Assume 2 servers are running. Both servers send a random 256-bit key, encrypted with the other's RSA public key to each other. This leads to 2 distinct keys that both servers now know. Then both servers XOR these two keys together to derive a common key. Why this is done instead of using both keys in the way I described above?

You are assuming there is no attack in progress. Actually, what each side knows is the following:

1) For the key it generated, only it and the intended recipient can know that key. (Because it generated it and encrypted it such that only the intended recipient can decrypt it.)

2) For the key it received, only it and whoever generated that key can know it. (It was encrypted such that only it could decrypt it, but there's no way to know who generated and encrypted it.)

So each key now has only half the security required.

Answer 3

Sometimes these distinct keys can be used for authentication and not encryption. But they can authenticate the steps of an agreement protocol such as the Diffie-Hellman key exchange or the Challenging Authentication-Agreement Protocol (CAAP). By authenticating the different components of a key exchange you can use the long term distinct keys to derive short term symmetric session keys.

As David mentioned, symmetric keys are used for stream encryption simply on the basis that symmetric algorithms like Serpent and ChaCha are generally faster than asymmetric algorithms such as RSA relying on large integer arithmetic.

To answer part of your question that I had missed, the reasoning behind using one shared and agreed key versus two distinct keys is to reduce complexity of the system. If you need to keep track of two independent stream states, it's very complex. Not only this but it reduces the amount of data you need to initially share because you are not worrying about initialization vectors or nonces for each separate cipher stream. Finally, another reason to use the singled shared key method from two keys is described in the second paper I referenced and that is for authentication of each party to the other.

For example if I give you an encrypted key to use directly in a cipher and I can get you to encrypt data under that key or know what the contents of the data are as in some protocol negotiations, you become leaky and could make certain weaknesses in an algorithm exploitable which could later be used to analyze some previous stream of data and assist in key recovery or data discovery. You do not know if I am in possession of the key or just the encrypted key. That's what the CAAP protects against.