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

Re: IKEv2 use of HMAC-SHA-1 for Key Derivation



David:

It's more efficient, an admittedly marginal benefit, since the initial
inner and outer states can be computed once and used to derive the whole
keystream. 

--Joe

At 09:44 PM 12/3/02 GMT, David Wagner wrote:
>The Purple Streak, Hilarie Orman wrote:
>>What I've been suggesting to Hugo and Charlie is that the iterated
>>counter be prepended to K before using HMAC:
>>
>>     T1 = HMAC-SHA1(0x00 | K, S)
>>     T2 = HMAC-SHA1(0x01 | K, T1 | S) 
>>     T3 = HMAC-SHA1(0x02 | K, T2 | S |
>>     T4 = HMAC-SHA1(0x03 | K, T3 | S )
>>
>>I believe this works properly for all cases, and uses a zero-based
>>counter (a real nit).
>
>This is a tangent, but:
>
>Is there any reason to prefer the counter being part of the key
>rather than the message?  The following seems slightly better to me:
>    T1 = HMAC-SHA1(K, 0x00 | S)
>    T2 = HMAC-SHA1(K, 0x01 | T1 | S) 
>    T3 = HMAC-SHA1(K, 0x02 | T2 | S |
>    T4 = HMAC-SHA1(K, 0x03 | T3 | S )
>My version is secure if HMAC-SHA1 is a secure PRF.  Your version
>also requires that HMAC-SHA1 be secure against related-key attacks.
>
>This is almost certainly a very minor nitpick.  It seems very
>unlikely that this will make a difference in practice.  Nonetheless,
>I do like my construction a little better, on general principles.
>
>Again, this is not at all important, and it is tangential to
>what you proposed.  My apologies for the distraction.
>