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

Hi Simon, 

> 
> This seems like the best attempt at a definition that I've seen. My only
> thought is whether 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. (I suspect formalizing f and how the attacker specifies it
> gets messy, but this does seem like a vaguely realistic required 
property
> in some cases.)
> 

That's an excellent point: KDFs need to resist manipulation of the secret 
input value, but the standard PRF notion doesn't seem to cover that.  Of 
course, the existing PRF-based KDFs (e.g. in TLS) may easily resist 
manipulation of the secret input value, but it may not be right to credit 
that to some formal security arguments about PRFs.

The existing PRG-based KDFs (e.g. HKDF from NIST and ANSI) may lack any 
formal security arguments whatsoever, but they probably also resist secret 
input value manipulation attacks.  Since a PRG seems a simpler thing than 
a PRF, I wonder if simpler formal security definitions and arguments can 
be supplied for such a KDF (in a threat model limited to one use of the 
secret value, as typical for making a DH shared secret into a symmetric 
key).  A KDF would need to be both a PRG and 1-way, perhaps more generally 
to not leak information, but surely there are some arguments around .

So, from a security architecture point of view, it may make sense to use 
one tool for making a raw DH shared secret into a symmetric key and 
another different tool for making subsidiary secrets out of a master 
secret.  The first tool needs to resist manipulation of the input secret 
but only has to worry about single use of the secret (or maybe double use 
:first for Alice and second for Bob?).  The second tool does not need to 
resist manipulation of the master secret, but may be subject to a larger 
number of queries, so the existing PRF notion may be perfect.

Yet another, third tool may be best suited for producing pseudorandomness 
from highly biased sources of min-entropy.  But maybe it's not too 
ambitious to find one definition and one tool can cover all three tasks 
either.