On 31 Jul 2001 02:43:12 -0400, Haig C Didizian <[EMAIL PROTECTED]>
wrote:
>I was just wondering if using DH for key negociation (say, to generate a
>128 bit blowfish key) reduces the number of potential keys in a way that
>significantly affects security.
Okay, this is a VERY BRIEF explanation of DH negotiation.
The system has two public values A and B. Value A is prime.
Value B is a little more complex. Specifically, B < A, and for every
positive integer N such that N < A, there exists some number C such that
B to the power of C modulo A = N.
So, provided value A is sufficiently large, DH does *not* reduce the
number of potential keys. If the bit length of A exceeds the desired
encryption key's bit length, the number of potential encryption keys by
definition exceeds the number of potential *acceptable* encryption keys
because value B will provide at least A-1 keys.
Now, Bob and Joe want to talk.
Bob selects a positive integer W such that W < (A - 1). He holds onto W,
and computes B to the power of W modulo A to result in a number X. He
sends X to Joe.
Joe also selects a positive integer Y such that Y < (A - 1). He holds
onto Y, and computes B to the power of Y modulo A to result in a number
Z. He sends Z to Bob.
Bob raises Z to the power of W, and Joe raises X to the power of Y.
These two values are identical. (Do the math if you feel so inclined.)
Bob and Joe now have the same value K, and can use it as a symmetric
encryption key.
However, anyone *eavesdropping* can only see parameters X and Z. In
order to obtain K, he must solve for both W and Y -- and this is
computationally infeasible. Even if he knows what A and B are, this is
of no help in solving the problem.
>How much less safe is using a DH key as
>a blowfish key than using a random string, for example?
How do you get that random string from one person to the other? Anyone
eavesdropping will see it and be able to use it for decryption of
traffic. That's the problem DH solves, and it doesn't sacrifice any
existing security to do so. It would, of course, be more secure (and not
subject to man-in-the-middle attacks) to use an asymmetric public-key
algorithm on both ends -- but it would also be significantly slower.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
