Subject: RE: [Cfrg] AES-based PRF - comment please

From: Ran Canetti <[email-masked]>
Date: Thu, 10 Apr 2003 13:17:40 -0400

I very much agree that this "pseudorandomness extraction" function is best 
treated separately from straightforward key derivation.
But I'd say that it also deserves to be separate also from the DH component.
In fact, it probably deserves being a component by itself,
both from an engineering point of view and from a conceptual/theoretical 
pont of view. (It may well be useful in contexts other than DH-based key
exchange.)

Ran

> From [email-masked] Thu Apr 10 12:10:48 2003
> 
> From an engineering standpoint, it seems to me that the responsibility for
> producing uniformly random output bits should be put onto the DH component.
> I'm thinking of the following structure:
> 
>  - a DH component, which takes public keys as input and outputs a (uniformly
> unpredictable) secret, and
> 
>  - a key derivation component, which takes a (uniformly unpredictable) secret
> and some set of public data (e.g. nonces, labels, and so forth) and produces a
> set of unpredictable keys.
> 
> Using this structure, we get the benefits that we've isolated the well-solved
> problem, and that the DH component can be swapped out for other components (e.g.
> symmetric or asymmetric key transport, elliptic curve variants, out-of-band
> keys, or whatever).  Also, this separation can help the key derivation component
> meet other secondary design goals, such as providing forward security (in the
> sense of the 'serial' method in "Increasing the lifetime of a key", by Abdalla
> and Bellare, - Asiacrypt 2000, online at
> http://www.cs.ucsd.edu/users/mihir/papers/rekey.html).
> 
_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Uri Blumenthal <[email-masked]>
Date: Thu, 10 Apr 2003 13:47:49 -0400

> treated separately from straightforward key derivation.

Yes.

> But I'd say that it also deserves to be separate also from the
 > DH component. In fact, it probably deserves being a component
 > by itself, both from an engineering point of view and from
 > a conceptual/theoretical pont of view. (It may well be useful
 > in contexts other than DH-based key exchange.)

 From a coneptual point of view, since this function is likely to
be dependent on DH output structure, it probably belongs with DH.

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 11 Apr 2003 19:17:34 +0300 (IDT)

what happened to UH?
give me a source of public randomness and I extract all the secret entropy
(computational entropy)

My IKE proposal: use prf as UH