I'd scrawled:
> > 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?

Joseph Ashwood graciously replied:
> 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. 


> > 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.

what about just using bytes from /dev/urandom on *nix?

> > 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.

Ok, I can see that from ya = g ^ xa mod p  ...  ya doesn't change if g, xa, 
and p don't change.

> 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.

Are you saying here that if p (and g) are static, then one has some 
opportunity to brute-force guess the private key that some long-running 
instance is using, if it doesn't otherwise re-allocate said private key from 
time to time?

thanks again,


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to