[Authentication] Clarification of algorithm: dh-ietf1024-aes128-cbc-pkcs7
yaronf at gmx.com
Sun Dec 5 00:31:28 PST 2010
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.
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
> Makes sense.
>> Also, HKDF is an operator (like HMAC), not an algorithm. In other words
>> you can have HKDF-SHA1 or HKDF-SHA256.
> I imagine using HKDG without salt is sufficiently strong in this
> scenario. Is that right?
More information about the Authentication