[Cfrg] Fwd: Hash-Based Key Derivation (fwd)

John Wilkinson writes:
>Getting back to the original topic of the NIST HKDF proposal, several
>people suggested that they were uncomfortable with the construction
>H_i = H( i || SV || contextID ), which is the one suggested in the
>HKDF proposal, with some optional arguments suppressed.
>
>Most of these same people suggested instead something along the lines
>of K_i = PRF( H(SV), i || contextID ), where H(SV) is the key input to
>the PRF, and ( i || contextID ) is the "message" input to the PRF.
>HMAC and CMAC were both suggested as suitable PRFs.
>
>Neither HMAC, nor CMAC retains any security guarantee as a PRF if the
>key is not chosen uniformly at random. If we assume that H(SV) is
>uniformly random, given that SV may not be, then we should have no
>concern with the NIST HKDF.

I don't agree with the last statement.  As I have written before (I
apologize for repeating myself), H(i || SV || ...) puts more stress on
the hash than PRF(H(SV), i || ...) does.  For the latter, we only need
H() to be good at producing uniformly random output *once*, and for the
case when *the attacker has limited (or no) control over the input to
the hash*.  For the former, we need H() to be good at producing uniformly
random output *on many closely related inputs*, and *when large parts
of the input can be entirely controlled by the attacker*.  Dealing with
producing many uniformly random outputs is precisely what PRFs are
good at.  And dealing with (non-secret) inputs that can be controlled
by the attacker is also exactly what PRFs are good at.  PRF(H(SV), i ||
...) uses the H() and PRF() primitives for what they are best at, not
what they are worst at.  For this reason, I would think that PRF(H(SV),
i || ...) would be a better design.

Basically, I'm talking about limiting how much we rely on the random
oracle model -- or, almost equivalently, limiting how much stress we put
on the hash function to behave well in scenarios it wasn't necessarily
designed for.

I think the NIST KDF is sub-optimal, and could be improved.  I don't
understand the argument that would be better to leave it unchanged.
But hey, I don't want to overstate the case.  It's not the end of
the world to leave the NIST KDF as is.  It's probably secure as it is.
My comment is only that one can do better: one can reduce the likelihood
of security failure, through more thoughtful design.  But if the powers
that be decide they prefer the current form, it's not a big deal.
Frankly, it's pretty rare for the crypto to be the weakest point in any
real system anyway, so even if the crypto isn't the very best it could
be, that might still be ok.

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