> The -dsaparam option to dhparam converts DSA parameters to DH and sets the
length parameter.

Note that this isn't actually safe to do in general; it's OK for ephemeral DH
with no re-use of private keys.

A shortcoming of our internal format (following from a similar shortcoming of
the TLS DH format) is that DH groups and DH public keys don't come with the
subgroup order or cofactor: so in general we can't validate that the DH share
received from the peer is in the expected subgroup (or even that the generator
is for a prime-order subgroup in the first place), because we don't need what
that subgroup is.

For servers, we could change DH parameter generation to either create "safe
primes" with the exponent length set to the recommended length plus one, or to
create Lim-Lee primes and avoid that small-subgroup safety margin. (Or enhance
the internal data format and add subgroup checks, which has some advantages and
some disadvantages. With Lim-Lee primes, with this we'd have twice the
necessary computational cost.)

For clients, when we receive a DH key from the server in the ServerKeyExchange
message, there's not much we can do about unnecessarily long exponents in
general because that message lacks the information needed to decide about
exponent length. We can hope that the generator is for a prime-order subgroup
or otherwise that the DH prime is a "safe prime", but I don't think that this
is generally guaranteed by the TLS specification: so someone might get a
practical attack from it. What we could do is check for well-known DH groups
and set the exponent length accordingly. Has anyone ever done a survey for TLS
servers supporting DH, to check how widely used well-known groups are vs.
custom DH groups?


It used to be the case that DH was little supported in SSL/TLS. Now it's more
widely supported, but there's also ECDH support. My immediate reaction about
this DH performance issue would be to recommend using ECDH instead. Given the
complications, is improving the classical DH case worth the effort?

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to