[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary of key derivation thread



I guess that by DHVAL you mean g^xy.
If you want to involve g^xy in each step of the key derivation do it
through the input not the key. Doing it through the key means that you
only support prfs with arbitrary-length key. For example you exclude AES,
3-DES, etc. If you include g^xy in the input part then you support all prfs.

Now, while I agree that by puting g^xy in the input to the prf you
increase the work factor for an exhaustive search, you must also be aware
that by doing so you also open the design to potential shortcut attacks
on the prf. The theory of prf's shows that it is
unadvisable (and sometimes insecure) to use the same quantity (in this
case g^xy) to derive both the key and the input to the prf. Expanding on
this issue would require a long academic discussin. The bottom line is: 
I would not strengthen the scheme against 2^160 exhaustive search and
open the scheme to other vuknerabilities (which are of theoretical nature
today but may be practical tomorrow). 
And, AGAIN, if 2^160 is not enough for you then use stronger prfs!!!!

Am I repeating myself?

Hugo

On Thu, 5 Dec 2002, The Purple Streak, Hilarie Orman wrote:

> The high entropy problem can be solved without use of SHA-2.  The
> method I proposed is for condensing the D-H value down to more than
> one internal key.  Call these the CONDKEYs.  Each one's length is the
> length of the output of the hash function.  You can use a prf or a
> hash to derive them, but the prefix to hash must vary for each one.
> Generate enough CONDKEYs so that their total length exceeds the entropy
> of the DH exchange.
> 
> CONDKEY0 = intn_key_func(0x00 | DHVAL, some_other_stuff )
> CONDKEY1 = intn_key_func(0x01 | DHVAL, some_other_stuff)
> ...
> 
> When deriving a long session key, use the CONDKEYs in sequence:
> 
> key_func(CONDKEY0, 0x00 | other_stuff)
> key_func(CONDKEY1, 0x01 | other_stuff)
> key_func(CONDKEY0, 0x02 | other_stuff)
> ...
> 
> For HMAC vs. hash, IKE uses HMAC to its advantage in authentication,
> and that shouldn't be changed; it seems immaterial whether or not it
> uses it for key derivation.
> 
> Hilarie
>