Julian wrote:
My fear is that get a hold of P will allow for someone else to use it to
start a protocol disassembly. For instance anyone could create a
DHE-RSA-AES256-SHA TLS server and use P to listen for connections, of
course if would have to have a cert signed by CA to proceed even if they
have P.
Without certificates (anon-DH), yes someone could do a man-in-the-middle
attack; with certificates they would be hard pressed, since they
wouldn't have the server's private key. As for listening, no matter what
P you use a listener could easily follow the protocol; but TLS is
designed to be resilient, so he couldn't get hold of the session keys.
The protocol here is TLS where each client is a server, so shouldn't
each client/server have their own DH P?
Or am I looking at this wrong, since I am using distributed PKI, then
exposing P is moot?
P,G are DH parameters which both the server and client need to know.
Normally they are public knowledge; if the server and client don't share
the P,G, then the server sends it to client (DH can't work if both don't
have the same P,G).
So, what happens is
client makes a random value Y which is private.
server makes a random value X which is private.
client uses {P,G} to make public value Y' from Y.
server uses {P,G} to make public value X' from X.
exchanges X',Y' and both arrive at a common value Z.
The security of DH lies in the fact that any attacker given knowledge of
X',Y',G,P cannot derive X or Y (Discrete Logarithm problem) and hence
cannot derive Z. And normally all systems generate X,Y for each DH exchange.
Hope that helps.
-jb
--
Real computer scientists don't comment their code. The identifiers are
so long they can't afford the disk space.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
