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.


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
> User Support Mailing List
> Automated List Manager

__________________________________________________ ____________________
OpenSSL Project
User Support Mailing List
Automated List Manager