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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 27 Sep 2004 10:40:19 -0700

Nicolas Williams wrote:
> You will have key-size impedance mismatches.
> You will need a PRF+.  
 
that is because I do not think you intended to say you allow applications to generate a 256 bit keys via a PRF of a 56 key-size enctype. no matter how clever your PRF+ is, it is not going to do you any good.
 
do you agree with me on this point before we proceed further.

________________________________

From: Nicolas Williams [mailto:[email-masked]]
Sent: Mon 9/27/2004 10:33 AM
To: Liqiang(Larry) Zhu
Cc: Ken Raeburn; Paul Leach; [email-masked]
Subject: Re: Concern: Does kcrypto imply that PRF is really a PRF

On Mon, Sep 27, 2004 at 10:28:55AM -0700, Liqiang(Larry) Zhu wrote:
> Nicolas Williams  wrote:
> > You cannot avoid the need for a PRF+ somewhere.
>
> I disagree, the PRF+ in IKEv2 and PEAP deals with the fact the output of PRF is not long enough.
> 
> if our PRF output is long enough for constructing keys with suitable attack resistance strength(that is exactly what I proposed for our PRF to do), what is the need of PRF+?

Larry, you're not reading my replies.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Sep 2004 12:47:22 -0500

> that is because I do not think you intended to say you allow applications to generate a 256 bit keys via a PRF of a 56 key-size enctype. no matter how clever your PRF+ is, it is not going to do you…

Just because the resulting key cannot have more entropy than the input
key does not make it useless to derive larger keys from smaller keys.

It would be nice to have a PRF for the AES enctype that produced 256
bits of output, however, if use PRF+ techniques to achieve this then we
complicate the analysis of the resulting PRF as compared to the PRF in
kcrypto.

So, while I would like the AES enctype's PRF to output 256 bits I'd also
like any such PRF not to be constructed like a PRF+, but by using, say,
a hash function that produces 256-bit hashes.

> do you agree with me on this point before we proceed further.

Evidently I don't.  First off I disagree that it doesn't do me any good
to generate larger keys from smaller keys -- we do this all the time in
string2key()!  Second one can use a PRF+ to get enough output material
to make a key as large as the underlying PRF's input.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 27 Sep 2004 14:03:43 -0400

On Sep 27, 2004, at 13:40, Liqiang((Larry)) Zhu wrote:
> that is because I do not think you intended to say you allow 
> applications to generate a 256 bit keys via a PRF of a 56 key-size 
> enctype. no matter how clever your PRF+ is, it is not going to do you 
> any good.
>  

I would disagree with that.  The generated key space is still only 
2^56, but that doesn't mean AES shouldn't be allowed to be used.  It 
would be deceptive to suggest that the full 128- or 256-bit key space 
is available, but that's a different matter.  (If you're going to 
impose that restriction, you might also re-examine whether we should 
allow 256-bit AES keys to be generated from passwords at all.)

As for key generation, a combine-keys type operation should be possible 
using the PRF -- use the PRF of each key, which keys could be of 
different types and could generate different length PRF output, and 
combine them in some way to provide input to the random-to-key 
function.  (So my comment in the "static-static DH proposal" thread 
Friday night was wrong -- if the PRF reveals part of the input, it's 
clearly unsuitable, because the random-to-key operation eventually used 
may be for another encryption type and may not be wise to use with 
non-random input.)