0
$\begingroup$

Consider a connection protocol where, after jumping through several other hoops, Alice and Bob know each others' public keys; and they now want to do a RSA-handshake-kind-of-thing to come up with a symmetric key for subsequent communication.

  • Alice randomly generates a 32-byte secret seed s_a, and Bob generates s_b.
  • They use asymmetric encryption to send the keys to each other.
  • Now both Alice and Bob want to independently generate a shared secret key s to symmetrically encrypt the rest of their conversation.

In this final step of deriving the shared secret, are there any pitfalls to look out for? I can think of several deterministic approaches - e.g.

  1. Multiply the two seeds and stretch the product:
    s = hash(s_a ⨉ s_b)
  2. Concatenate the two seeds in ascending order, and stretch the result:
    s = hash(concat(sort(s_a, s_b)))
  3. Use the smaller key as a hash key to hash the larger one. s = hash(s_smaller, s_larger)
  4. Just use the smallest of the two keys.

Do we need to be careful here? Is there any reason to prefer one of these over the others?

Improve this question
$\endgroup$
3
  • 2
    $\begingroup$ What happens if one party deliberately picks a bad key, e.g. all-zero? $\endgroup$ – SEJPM♦ Jul 15 '20 at 18:43
  • $\begingroup$ I'd rather use a KDF with the concatenation of both parts as input keying material (which means that the KDF should have KDF-extraction functionality, as the input is 64 bytes). Then you can create one more more session keys out of that (possibly with an intermediate master session key). I'd also split the sending keys of Alice and Bob - you generally want to use different keys in each direction. $\endgroup$ – Maarten Bodewes♦ Jul 16 '20 at 13:42
  • $\begingroup$ And beware that just knowing each other's public keys doesn't mean authentication - even when they are trusted; you still need to validate that (at least one of the) calculated session keys are identical. $\endgroup$ – Maarten Bodewes♦ Jul 16 '20 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.