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

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

Nicolas Williams wrote:
>  The PRF API we'll be adding to the GSS-API, for
> example, produces output that cannot then be fed to the GSS-API for use
> as any sort of key for any mechanism -- that PRF is meant for use by
> other applications, such as EAP mechanisms.
 
so you just reiterated that this PRF is intended for key-generation, right? it would be silly to claim the output is suitiable for key-genration, but the applicaiton need to invoke it multiple times with unknown construction/composition methods that are completely unspecified. Therefore I maintain the PRF description today fails to do the job it is supposed to do.

________________________________

From: Nicolas Williams [mailto:[email-masked]]
Sent: Mon 9/27/2004 9:56 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 08:59:56AM -0700, Liqiang(Larry) Zhu wrote:
> the current PRF description says:
>  The PRF output string should be suitable for use in key generation, even if the octet string input is public
> 
> Ken Raeburn wrote:
> > There is nothing that says that the output of one invocation of the PRF
> > is big enough to produce a key.
>
> The intended usage of PRF is to generate keys.

But for the same enctype as the input key?

No, I don't think so.  The PRF API we'll be adding to the GSS-API, for
example, produces output that cannot then be fed to the GSS-API for use
as any sort of key for any mechanism -- that PRF is meant for use by
other applications, such as EAP mechanisms.

So I still see no reason to modify the krb5 AES enctype's PRF to produce
256 bits of output.

> we have spent considerable effort to construct the PRF+-alike function, that is tricky,

And the construction of the PRF itself is also tricky.  The construction
you propose is a really a PRF+, so you don't avoid any complications
that way, plus we'd have to recall the AES I-D to do it.

> if PRF products an output of at least K length, our life could have been much easier.

See above.

> 
>
> > If the PRF were specified as a key generation function, perhaps.  It's
> > not.  It's for producing pseudo-random data.  One intended application
> > for it is in generation of keys, but that's not the same thing.
>
> what is a possible application of the pseudo-random data other than key generation? if the generalization can hurt the primary intended usage,  it should be removed.

See above.

> > Your suggestion doesn't seem very different from what you'd get by doing
> >     X = PRF(key, 0x00|input-string) | PRF(key, 0x01|input-string) | ...
> > under the current PRF definition, which is probably how I'd go about
> > trying to produce a key using the PRF.
>
> no, it makes our analysys difficult by moving the construction to the level of PRF, for one thing, I do not know if PRF(key, 0x00|input-string) != PRF(key, 0x01|input-string)

If the PRF is strong then we don't care if PRF(key, 0x00|input-string)
== PRF(key, 0x01|input-string) for some value of key and input-string.

Nico
--

---

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

> so you just reiterated that this PRF is intended for key-generation, right? it would be silly to claim the output is suitiable for key-genration, but the applicaiton need to invoke it multiple time…

Re-read the above paragraph.

One enctype's PRF could be used to generate keys for any other cipher in
any other cryptosystem.  You will have key-size impedance mismatches.
You will need a PRF+.  You cannot avoid the need for a PRF+ somewhere.

Nico
--