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

[Yaron Sheffer]

Hi Stef,

the combined g**(x*y) DH value is not random enough, or we wouldn't have 
needed an
"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...

Thanks,
     Yaron


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
>> case.
> Yes, I would tend to agree.
>
> Cheers,
>
> Stef