Subject: [Hipsec] Salt for KEYMAT

From: Robert Moskowitz <[email-masked]>
Date: Wed, 12 May 2010 16:07:53 -0400

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?

---

From: Tobias Heer <[email-masked]>
Date: Wed, 12 May 2010 22:16:23 +0200

Am 12.05.2010 um 22:07 schrieb Robert Moskowitz:

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

BR, Tobias
  
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 12 May 2010 16:27:30 -0400

On 05/12/2010 04:16 PM, Tobias Heer wrote:
>> 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?
>>
>>      

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.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 13 May 2010 10:25:09 -0400

On 05/12/2010 04:27 PM, Robert Moskowitz wrote:
>>> 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.
>
> 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.

---

From: Miika Komu <[email-masked]>
Date: Thu, 13 May 2010 19:45:56 +0300

On 12/05/10 23:27, Robert Moskowitz wrote:

Hi,

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

there seems to be a trade off between saving bits and trying to keep the 
puzzle computation clear. What about adding a varying length field "L" 
to the puzzle and say explicitly that it doesn't affect puzzle 
computation in any way?