Lutz Jaenicke <[EMAIL PROTECTED]> in ulf.openssl.users:
> while working on Postfix/TLS (and following the discussion about DH
> things and the history of SSL), I think about including DSA certificate
> support into the package.
> Since the documentation about this issue is pretty (ahem) thin, I have
> some questions left:
> - When using DH, I do need DH parameters. These parameters are used for
> random number purposes. Right?
No. Good random numbers are additionally needed. DH parameters
consist of a prime p, a generator g of some subgroup of (Z/pZ)*,
and optionally the length to be used for DH exponents. When DH
parameters are used, the library randomly creates an exponent x
of the given length or, if none is given, of the length of p.
Parameters p and g are public, they are sent in clear during the
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.
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.
> - In s_server.c, these parameters are hard coded. If the first assumption
> is right, then using the same parameters in my application would be
> quite stupid. Right?
Not really, the parameters are public anyway and can be reused.
However fixed parameters may simplify attacks -- the known efficient
algorithms for discrete logarithms (i.e. for computing x from y or
x' from y') are based on building large tables for a given p
which then can be used to compute arbitrary discrete logarithms
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. Also, unless you know the PRNG seed used to
generate the parameters and can verify that they were indeed computed
from it, you cannot know whether the published parameters include some
trapdoor that allows the person who created the parameters to solve
DLs and hence break DH more easily than expected.
> - 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.
> - How critical is the lifetime of the parameters? Is it good enough, to
> generate them once during setup (by user action) or would it be better to
> generate new ones letīs say once by night from a cron job.
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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
