questions on RFC2631 and DH key agreement

[Joseph Ashwood]

----- Original Message ----- 
From: "' =JeffH '" <Jeff.Hodges at KingsMountain.com>
To: "Joseph Ashwood" <ashwood at msn.com>
Cc: <cryptography at 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 majordomo at metzdowd.com