questions on RFC2631 and DH key agreement

[' =JeffH ']

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. 

yes.


> > 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.
             ^^
             so?


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

=JeffH


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com