DH Prime Question

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

DH Prime Question

Julian-35
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: DH Prime Question

Bernhard Fröhlich-2
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 (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DH Prime Question

jimmy bahuleyan
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: DH Prime Question

Julian-35
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 List                    [hidden email]
> Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: DH Prime Question

jimmy bahuleyan
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: DH Prime Question

Julian-35
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 List                    [hidden email]
> Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: DH Prime Question

Michael Sierchio
In reply to this post by Julian-35
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 List                    [hidden email]
Automated List Manager                           [hidden email]