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

[Hugo Krawczyk <[e-mail]>]

On 28 Oct 2005, D. J. Bernstein wrote:

> Hugo Krawczyk writes:
> > Firststep:  K=H(SV || [context-information1])
> > Second step:Hi=PRF(K, counter++ || [context-information2]
>
> How do we build PRFs? By hashing the key and the input. So this

No.I do not recommend (actually I object to) the approach of building a
PRF by "hashing the key and the input". That is an error-prone approach
which easily leads, for example, to define PRF(K,M)=SHA-1(M||K) which, as
I said in a previous posting, assumes SHA-1 is collision resistant and
therefore insecure. I use well-structured constructions based on as weak
as possible requirements from the hash function. In HMAC, for example, it
is the pseudo-random property of the compression function. If you are
going to say that we do not know how pseudorandom this compression functon
is then I will certainly agree with you (which is the case for almost
everything else in cryptography) But it certainly states a well-defined
property of the compresion function that can be judged relative to current
cryptanlytical knowledge. In particular, for all we know today HMAC-SHA-1
is a good PRF while SHA-1(M||K) is not.

In addition, when you specify a scheme with a generic PRF (and analyze it
accordingly) you allow for different implementation of the PRF including
non hash-based ones such as AES in CBC-MAC mode

> construction boils down to something like H(H(SV,context),counter++). Or
> maybe you want H(H(H(SV,context),counter++),H(SV,context)) because you
> don't really trust your H. Or perhaps you meant
>
>  H(SV,H(counter++,H(H(H(SV,context),counter++),H(SV,context))))
>
> because security is really measured by the number of H's, right? Whoops,
> looks like the added implementation difficulty made me double-increment
> the counter, which I'll have to fix; nobody said security was easy!

I do not know what you are trying to say. The counter++ was a short hand
expression to avoid using i explicitly as counter (which NIST does not
mandate) and saving the i=i+1 notation outside the Hi. It was not meant as
a programming specification just to simplify presentation.

>
> ---D. J. Bernstein, Professor, Mathematics, Statistics,
> and Computer Science, University of Illinois at Chicago
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg
>


_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg