[114714] in cryptography@c2.net mail archive
Re: questions on RFC2631 and DH key agreement
daemon@ATHENA.MIT.EDU ("Hal Finney")
Wed Feb 6 20:28:59 2008
To: Jeff.Hodges@KingsMountain.com
Cc: cryptography@metzdowd.com
Date: Wed, 6 Feb 2008 09:35:08 -0800 (PST)
From: hal@finney.org ("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@metzdowd.com
