I\'ve seen a lot of 2-party applications that derive a shared key from distinct
ID: 651096 • Letter: I
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?
Explanation / Answer
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.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.