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

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



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

What you propose is exactly the IKEv2 derivation which Hilarie was
proposing to change (except that in IKEv2 the counter goes last)

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

Design based on general principles can make a bigger difference to
practical security than a 160 vas 256-bit hash
 
> Again, this is not at all important, and it is tangential to
> what you proposed.  My apologies for the distraction.
> 

Because of the previous remark I think that this is important...

Hugo