[114697] in cryptography@c2.net mail archive
Re: questions on RFC2631 and DH key agreement
daemon@ATHENA.MIT.EDU (' =JeffH ')
Wed Feb 6 13:33:57 2008
To: "Joseph Ashwood" <ashwood@msn.com>
cc: cryptography@metzdowd.com
In-reply-to: "Joseph Ashwood" <ashwood@msn.com> 's message of
Sun, 03 Feb 2008 23:32:08 -0800
Reply-to: ' =JeffH ' <Jeff.Hodges@KingsMountain.com>
From: ' =JeffH ' <Jeff.Hodges@KingsMountain.com>
Date: Mon, 04 Feb 2008 17:18:55 -0800
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@metzdowd.com
