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