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

Simon Blake-Wilson writes:
>[...] an attacker should also get access to something like an
>F(f(K),.)) oracle. For example in the case of an ephemeral-static DH
>protocol where the recipient has a static public key g^x and the legimate
>peer contributes an ephemeral public key g^y, an attacker may be able to
>to at some point impersonate a legimate peer and send (g^y)^2 and
>subsequently learn the session key computed by the recipient using
>S=g^2xy. Allowing the attacker access to an F(f(K),.) oracle for any
>f:S->S, f \neq 1 of the attacker choice somehow simulates this
>possibility.

That's an excellent point, and it pretty much sinks my proposed
definition.  Thank you.  I'm afraid I don't know how to model this in
a clean way in the definition, so I have to take back my assertion that
defining a secure KDF is easy.

By the way, there is a very tricky issue here.  If we allow the attacker
to specify a truly arbitrary function f:S->S, then there is no hope
for security, because there are generic attacks that will work against
any KDF.  (For instance, taking f1(K) = x&1, f2(K) = x&3, f3(K) = x&7,
etc. lets me learn K in linear time.)  This is similar to the issue
with security against related-key attacks, and that also gets into some
definitional briar patches.

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