----- Original Message ----- From: "' =JeffH '" <[EMAIL PROTECTED]>
Sent: Saturday, February 02, 2008 12:56 PM
Subject: Re: questions on RFC2631 and DH key agreement

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?

It is assuming that the total value of the data protected by those parameters never crosses the cost to break in the information value lifetime. For 1040 bits this is highly questionable for any data with a lifetime longer than 6 months.

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,

Very bad idea, for two reasons, the rand() function does not have sufficient internal state, and the rand() function is far from cryptographically strong.

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?

All flaws in the private key generator will show in the public key selection, do yes.

Additionally there's the previously noted issue with the values of static
private keys slowly leaking.

Only if the value of p changes, if the value of p remains static, then the private key doesn't leak. A simple proof of this is simple, Eve can easily, and trivially generate any number of public/private key pairs and thereby generate any number of viewable sets to determine the unknown private key. Joe
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to