questions on RFC2631 and DH key agreement

[Joseph Ashwood]

----- Original Message ----- 
From: "' =JeffH '" <Jeff.Hodges at KingsMountain.com>
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 majordomo at metzdowd.com