KDF definition and goal [was: [Cfrg] Fwd: Hash-Based Key Derivation]

[David Wagner <daw at cs.berkeley.edu>]

Dan Bernstein writes:
>Here's the standard example. The legitimate users exchange authenticated
>public keys g^x and g^y, and an independent authenticated random H. They
>compute the Diffie-Hellman shared secret g^xy and a short hash H(g^xy).
>If the attacker can't distinguish g^xy from a uniform random group
>element then, by the leftover-hash lemma, the attacker can't distinguish
>H(g^xy) from a uniform random short string.

Ok.  Now I get it.  I see what you're saying, and it makes sense.
That kind of protocol hadn't occurred to me.  (I guess you are assuming
that H is chosen by a party who won't be malicious, which is reasonable.)

Thanks for the detailed explanation.  That was very helpful.

To make a pre-fixed 2-universal hash work in this context, it seems
we need it to be the case that:
  (a) the 2-universal hash function is chosen by a party who is
  known not to be malicious, and its value is authenticated so
  that everyone can know it came from that party; and,
  (b) all inputs to the hash function are chosen by users who are
  known not to be malicious, and are authenticated so that everyone
  can verify that they came from those users.
In this case, a 2-universal hash function fixed in advance will
work (for some choice of security parameters).

It seems that all of these conditions need to hold true if we want
to use the Leftover Hash Lemma.  There are also protocols where these
conditions do not hold, and where a hash function chosen and fixed in
advance is not secure.

So it sounds like 2-universal key derivation has to be used with some
care, and cannot be blindly applied to all protocols.  If we were going
to replace the NIST KDF with a 2-universal based KDF, then we would
probably need some extra precautionary usage notes describing what
conditions the protocol must satisfy.

Is that right?

>There are some serious limitations here, notably the short H output
>length, but the limitations shouldn't be exaggerated.

Yup.  Thank you for your clarifying email.

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg