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 [EMAIL PROTECTED]