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 openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
