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 [EMAIL PROTECTED]

Reply via email to