Re: [Hipsec] Salt for KEYMAT

[Robert Moskowitz <[e-mail]>]

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.