[Authentication] Clarification of algorithm: dh-ietf1024-aes128-cbc-pkcs7

[Yaron Sheffer]

Hi Stef,

According to the RFC, the salt is not absolutely essential, but is 
highly recommended. One way to get it is for one of the peers to 
generate it (just a few random bytes) and send it during the DH exchange 
- I haven't looked at the code so I don't know how difficult this might be.

Also note that the RFC mentions that the salt should be 
integrity-protected ("public nonces exchanged and authenticated"). I 
suppose that we are relying on the dbus infrastructure for source 
authenticity and for traffic integrity, so this is not an issue in our case.

Thanks,
     Yaron

On 12/05/2010 12:28 AM, Stef Walter wrote:
> On 2010-11-27 14:49, Yaron Sheffer wrote:
>> No matter how you do it, you'd want the hash algorithm to be part of the
>> algorithm set for future algorithm agility, for example
>> dh-ietf1024-*sha256*-aes128-cbc-pkcs7.
> Makes sense.
>
>> Also, HKDF is an operator (like HMAC), not an algorithm. In other words
>> you can have HKDF-SHA1 or HKDF-SHA256.
> Right.
>
> I imagine using HKDG without salt is sufficiently strong in this
> scenario. Is that right?
>
> Cheers,
>
> Stef