questions on RFC2631 and DH key agreement

[Hal Finney]

Jeff Hodges writes:
> If a purportedly "secure" protocol employing a nominal DH exchange in order to 
> establish a shared secret key between a requester and responder, employs 
> widely known published (on the web) fixed values for g ("2") and p (a 
> purportedly prime 1040 bit number) for many of it's implementations and 
> runtime invocations, what are the risks its designers are assuming with 
> respect to the resultant properties of ZZ?

This can be reasonably safe, if p is chosen properly. There is no problem
with using g=2, with the right p. The main issue is that with current
technology, a 1040 bit p stands a substantial chance of being broken.
A 1024 bit special-form number was factored last year, with claims that
the technique might apply to general RSA moduli of that size. Finding
discrete logs takes similar work.  A widely reused p value would be a
fat target for such an effort.

> I suspect that many implementations will simply use the equivalent of whatever 
> rand() function is available to get the bits for their private keys directly, 
> and will likely not reallocate private keys unless the implementation or 
> machine are restarted. So if the random number generator has known flaws, then 
> there may be some predictability in both the public keys and in ZZ, yes? 
> Additionally there's the previously noted issue with the values of static 
> private keys slowly leaking.

I'm not sure about this leaking, I asked Ashwood for clarification.
Certainly if the secret exponents are poorly chosen, the system will be
insecure. I would not necessarily assume that rand() is being used; I
would hope in this day and age that people would know better than that.
/dev/random on Linux&Mac and CryptGenRandom on Windows should provide
adequate security for this use, and hopefully the implementors would be
aware of the need for secure random numbers.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com