DH Prime Question
Hi, I am working on an application that is both a client and a server. The DH prime is stored in the binary for the server. Since the Server will exists inside the Client is there a considerable risk of embedding the DH p into the code? The alternative is to have the Server generate a 1024 bit prime when the Client starts it's Server portion, however as we know this is painfully slow. Thanks, J __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: DH Prime Question
Julian schrieb: Hi, I am working on an application that is both a client and a server. The DH prime is stored in the binary for the server. Since the Server will exists inside the Client is there a considerable risk of embedding the DH p into the code? The alternative is to have the Server generate a 1024 bit prime when the Client starts it's Server portion, however as we know this is painfully slow. Thanks, J As I understand it the prime inportance for DH parameters is that no attacker can trick you into using a special set of parameters. Insofar I'd see no problem embedding DH parameters in code, because if an attacker can modify your code than you'll have bigger problems than DH parameters. Any other opinions? Hope it helps, Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: DH Prime Question
Bernhard Froehlich wrote:
Julian schrieb:
Hi,
I am working on an application that is both a client and a server. The
DH prime is stored in the binary for the server. Since the Server will
exists inside the Client is there a considerable risk of embedding the
DH p into the code? The alternative is to have the Server generate a
1024 bit prime when the Client starts it's Server portion, however as
we know this is painfully slow.
Thanks,
J
As I understand it the prime inportance for DH parameters is that no
attacker can trick you into using a special set of parameters. Insofar
I'd see no problem embedding DH parameters in code, because if an
attacker can modify your code than you'll have bigger problems than DH
parameters.
Any other opinions?
Hope it helps,
Ted
;)
Agree with Bernhard.
Embedding doesn't seem to be a problem; many softwares use well known DH
parameters (eg: ssh). What is important is for your DH params not to be
weak, it might make be worth to look at places like RFC 4419 {Sections
6,7}, RFC2409 {Section 6 gives the Oakley groups}.
-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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: DH Prime Question
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.
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?
Thanks in advance.
J
On Apr 14, 2008, at 1:57 AM, jimmy bahuleyan wrote:
Bernhard Froehlich wrote:
Julian schrieb:
Hi,
I am working on an application that is both a client and a server.
The DH prime is stored in the binary for the server. Since the
Server will exists inside the Client is there a considerable risk
of embedding the DH p into the code? The alternative is to have
the Server generate a 1024 bit prime when the Client starts it's
Server portion, however as we know this is painfully slow.
Thanks,
J
As I understand it the prime inportance for DH parameters is that
no attacker can trick you into using a special set of parameters.
Insofar I'd see no problem embedding DH parameters in code, because
if an attacker can modify your code than you'll have bigger
problems than DH parameters.
Any other opinions?
Hope it helps,
Ted
;)
Agree with Bernhard.
Embedding doesn't seem to be a problem; many softwares use well
known DH parameters (eg: ssh). What is important is for your DH
params not to be weak, it might make be worth to look at places like
RFC 4419 {Sections 6,7}, RFC2409 {Section 6 gives the Oakley groups}.
-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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: DH Prime Question
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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: DH Prime Question
Thanks jb that clears up a lot.
j
On Apr 14, 2008, at 6:14 AM, jimmy bahuleyan wrote:
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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: DH Prime Question
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. The protocol here is TLS where each client is a server, so shouldn't each client/server have their own DH P? No. All participants share a prime generator and a modulus. A DH secret key is therefore essentially merely a random string of bits of a certain length. The corresponding public key is p^privkey mod m. Trust requires you have some mechanism to know that a given set of bits is the pubkey belonging to the other party. The benefit of DH is that once you and your correspondent have each other's public keys, you can begin encrypted communication without a handshake. There is an implicit pairwise shared secret which you can use to generate session keys via some established mechanism (see SKIP as an example). - M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
