On Sun, Dec 05, 1999 at 12:26:02AM +0100, Bodo Moeller wrote:
[parts of lengthy explanation deleted]
Bodo,
thank you very much for your effort to write this explanation.
Seems I misunderstood significant part of the DH handling.
"Go back to the start, do not get 4000DM, restart studying the issue" (or
so it would sound in Monopoly :-)
> handshake. The exponent x is secret; y := g^x mod p is sent
> to the client (in clear). The client picks its own random exponent
> x' (without knowing the optional exponent length that the server can
> use) and sends y' := g^x' mod p to the server. The result is
> that client and server both can compute the number g^(x*x') mod p:
> The server computes it as y'^x mod p, the client computes as
> y^x' mod p. But someone who observes the whole handshake cannot
> compute this number.
Ah, I see.
> Not even the client and server can re-compute it later once they have
> forgotten their respective secret number (x or x'); this features is
> known as forward secrecy. Because of this, DH ciphersuites make a lot
> of sense even for non-DSA servers.
:-)
> module this prime. If everyone were using the same prime, obviously
> it would become quite an interesting target for attackers; succesful
> attacks are not feasible using current knowledge and technology, but
> better safe than sorry.
:-) So it seems a good compromise to have these parameters generated
once during the installation for use at this site and not use fix
coded values.
> > - While strolling through mod_ssl I have seen 512bit and 1024bit DH params.
> > I cannot use both at the same time, so is it good enough to have one
> > of it and read it in at startup time?
>
> Export ciphersuites limit DH prime size to 512 bits, otherwise 1024
> bits are reasonable. I don't know of any export-crippled software
> that even supports DH ciphersuites, so you only need parameters with
> 1024 bit primes. If you wanted to provide both sizes, 512 and 1024,
> you in fact could do so with OpenSSL -- it's just that things would
> become more complicated: Instead of simply using SSL_CTX_set_tmp_dh,
> you'd have to provide a callback function that selects appropriate
> parameters when called at handshake time.
I see. Seems I have to go through the appropriate code to find it.
Since I have seen 512bit and 1024bit in mod_ssl, I should find things
there.
Anyway, in s_server.c (and the derived sslwrap 512bit keys are used, so
512bit is not that uncommon, if people used these examples with OpenSSL...)
> This depends exclusively on how paranoid you are. If you have to
> protect very valuable secrets, then refreshing the parameters
> may make sense. However the actual DH keys (the secret exponents x)
> should be frequently refreshed;
> SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE);
> ensures that a new exponent will be created for each handshake.
> If you use certain other kinds of parameters than
> DH_generate_parameters returns (see example code in ssltest.c -- look
> for DSA_dup_DH), then the SSL_OP_SINGLE_DH_USE option even becomes
> essential.
Ok, I will check into ssltest.c.
Many thanks,
Lutz
(Thanks of course also to Steve for his addition)
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
