Subject: RE: Concern: Does kcrypto imply that PRF is really a PRF

From: "Paul Leach" <[email-masked]>
Date: Mon, 27 Sep 2004 11:44:38 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Monday, September 27, 2004 11:33 AM
> To: Paul Leach
> Cc: Nicolas Williams; Liqiang(Larry) Zhu; Jeffrey Altman; ietf-krb-
> [email-masked]; Ken Raeburn
> Subject: Re: Concern: Does kcrypto imply that PRF is really a PRF
> 
> >>>>> "Paul" == Paul Leach <[email-masked]> writes:
> 
>     Paul> [Paul Leach] Whereas I'm curious why the PRF for AES _isn't_
>     Paul> an HMAC.
> 
> 
> Note that you don't really want a PRF for a string2key function.  The
> requirements for string2key are somewhat different than requirements
> for a PRF.  When I last looked at literature on the string2key problem
> (aronud 2000), the requirements for a string2key function were not
> even well understood.  The state of the art seemed to be throwing
> things together with a lot of hashing and hoping something reasonable
> came out.
> 
> In particular, everything about a PRF depends on having a strong key
> as one of the inputs.  Once you have that, you can get fairly simple
> constructions especially if you are willing to assume that you have a
> strong primitive like an ideal block cipher.
[Paul Leach] I don't understand any of this message. HMAC's are not
string2key functions -- they are keyed hashes. Their properties have
been extensively studied. Do a Google on "Hugo Krawczyk" and "HMAC".

---

From: "Paul Leach" <[email-masked]>
Date: Mon, 27 Sep 2004 12:38:05 -0700

WRT HMAC:
For simplicity and clarity, in my examples I've been using SHA1(k,
input), but they really should be HMAC-SHA1.

And it would be nice if the PRF allowed the key to be arbitrary length.

Or, putting aside the requirement of using the primitives in kcrypto for
a moment, the DH key derivation I think one wants is this

ki = HMAC-SHA1(k_dh, n_c | n_k | i)
k = truncate(k0 | k1 ..., N)

(Or maybe we want HMAC-SHA256 for 256 bit keys?)