[Authentication] Clarification of algorithm: dh-ietf1024-aes128-cbc-pkcs7
yaronf at gmx.com
Wed Dec 8 01:28:07 PST 2010
the combined g**(x*y) DH value is not random enough, or we wouldn't have
"extractor" anyway. Or in the words of real cryptographers
(http://people.csail.mit.edu/dodis/ps/hmac.ps, sec. 1.1):
... We are in a situation similar to that of an imperfect source of
randomness [...] In particular, g**xy cannot be used directly as a
cryptographic key, but rather as a source from which to extract a
shorter string [...] of full computational entropy.
But I think it's still random enough (and we don't assume active
attackers) that we don't need the salt value...
On 12/08/2010 01:14 AM, Stef Walter wrote:
> On 2010-12-05 02:31, Yaron Sheffer wrote:
>> 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.
> It's possible, but since the DH public key values are already completely
> random it seems to me that it would add no additional security. But
> crypto is unintuitive, and that's why I was asking.
>> 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
> Yes, I would tend to agree.
More information about the Authentication