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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 27 Sep 2004 08:59:56 -0700

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. 

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

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

> 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.

> 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) 

________________________________

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

On Sep 27, 2004, at 02:14, Liqiang((Larry)) Zhu wrote:

> 2) the PRF for AES-256-CTS in particular is a bad one (as defined
> draft-raeburn-krb-rijndael-krb):
>
>     pseudo-random function    tmp2 = SHA-1(octet-string)
>                               PRF = E(protocol-key, tmp2, zero-IV)
>
> This is because the output of this PRF is only 160 bits long, which is
> not suitable for use in generating a 256 bit key.

There is nothing that says that the output of one invocation of the PRF
is big enough to produce a key.  Multiple invocations may be needed. 
For a 256-bit key, obviously, more than one 160-bit string has to be
generated.

> An improved version would be
>
>     pseudo-random function    tmp1 = SHA-1(0x00 | input-octet-string) |
> SHA-1(0x01 | input-octet-string) | ...
>                               tmp2 = truncate tmp1 to 256 bits
>                               PRF = E(protocol-key, tmp2, zero-IV)

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.

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.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Sep 2004 11:56:55 -0500

> 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.

> 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.

> 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: Sam Hartman <[email-masked]>
Date: Mon, 27 Sep 2004 14:44:52 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

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

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

This was considered.  The current PRF construction is quite solid for
what it does.  I didn't know how to generate a single function that
was a clear right choice and generated k-bit keys with the primitives
available.  No one else in the WG seemed to be thinking about the
problem at the time.

At the time I was not aware of the work discussing proofs for
mac-based PRFs.  Even so, I'm not sure this really helps you much.

--Sam