----- Original Message -----
From: "' =JeffH '" <[EMAIL PROTECTED]>
To: "Joseph Ashwood" <[EMAIL PROTECTED]>
Cc: <cryptography@metzdowd.com>
Sent: Monday, February 04, 2008 5:18 PM
Subject: Re: questions on RFC2631 and DH key agreement
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?
*nix /dev/urandom should work well, the entropy harvesting is reasonably
good, and the mixing/generating are sufficient to keep it from being the
weak link.
> 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?
Yep, my typos show I'm far from perfect. I meant "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?
Actually I'm saying that if p and g do not change, then there is no
additional leakage of the private key beyond what Eve can compute anyway.
There are many, many factors involved in any deep security examination,
making it truly a business decision with all the complexities involved in
that, and very easy to get wrong.
Joe
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
