Re: [Hipsec] Salt for KEYMAT

[Robert Moskowitz <[e-mail]>]

On 05/12/2010 04:27 PM, Robert Moskowitz wrote:
> On 05/12/2010 04:16 PM, Tobias Heer wrote:
>> Am 12.05.2010 um 22:07 schrieb Robert Moskowitz:
>>
>>> In draft-krawczyk-hkdf-01.txt:
>>>
>>> Ideally, the salt value is a random (or pseudorandom) string of the
>>> length HashLen. Yet, even a salt value of less quality (shorter in
>>> size or with limited entropy) may still make a significant
>>> contribution to the security of the output keying material; designers
>>> of applications are therefore encouraged to provide salt values to
>>> HKDF if such values can be obtained by the application.
>>>
>>> Currently KEYMAT uses I& J which is 128 bits of nonce for the salt. 
>>> This is better than nothing; the question is should I& J be 
>>> increased in size (Tobias and I have discussed making them 128 bits 
>>> each), add a nonce HIP parameter, or do something else? Actually for 
>>> SHA-384 you would need even a larger salt, so what is the desire here?
>>>
>> We had discussed making the salt size (wherever it comes from) depend 
>> on the HIT_SUITE. This doesn't work perfectly because the cipher for 
>> esp also depends on the shared secret and it is independent from the 
>> HIT. Making the dependency work in the other direction (salt length 
>> depends on esp suite) isn't correct either. Making it the maximum of 
>> both could work but it would be slightly more complicated.
>
> Actually the salt size seems to only be linked to the hash used. 
> Currently for HIP that is SHA-1, SHA-256, or SHA-384. This places a 
> salt size recommendation of 160, 256, or 384 bits respectively 
> regardless of the key sizes pulled out of the Expand phase. So tying 
> this to the HIT_SUITE makes sense as this is where the hash used 
> within HIP is specified. Just what do we do, make I & J sizes vary 
> with the hash or add a HIP parameter to get the additional bits.
>
> Note that making I & J bigger should NOT impact puzzle calculation. 
> That is determined by the hash used and the value of K. Or at least 
> that is my reading of the puzzle mechanism; those that have actually 
> coded it are welcomed to comment.

So what I am going with is that I & J are RHASH-len/2 bits long.

This will be 80, 128, or 192 bits.

K is still 8 bits, thus limiting the puzzle to a 64 bit proof at worst case.