[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