Bug#475194: D-H parameter generation is All Wrong

[sacrificial-spam-address at horizon.com]

Package: exim4-base
Version: 4.69-2

The entire premise of the script /usr/share/exim4/exim4_refresh_gnutls-params
is based on a serious misapprehension of the role of Diffie-Hellman
parmeters in performing encryption.

Parameters are values that the communicating parties must agree on,
but they are not secret in any way.  For example, the port number 25 is
a parameter of the SMTP protocol.

Many standards simply specify fixed D-H parameters, or a short menu,
for all implementations of a protocol.  (e.g. RFC3526).

The important thing is that the parameters are not key material.
The only security requirement is that they must not be dictated by
a malicious attacker; poorly chosen parameters can make an attack
easier.

To begin with, the script sets the file to mode 0400.  This is patently
ridiculous; the contents of the file are not the tiniest bit secret,
and the server sends the parameters to every spambot that attempts to
initiate a TLS connection.

Second, regenerating parameters daily is completely unnecessary.
Once per installation is fine, and shipping a fixed parameter file is
not unreasonable.  While there are attacks that can be mounted knowing
just the parameters, it's generally simpler to choose a slightly larger
prime that is N times more difficult to break rather than changing primes
N times as often.

Third, the parameter size chosen is too small.  1024 bits requires
O(2^80) effort to break, which is considered a casual security level
these days.  certtool without a --bits option defaults to 2048 bits,
a more reasonable value.

I wish I could come up with a polite way to put this, but the entire
thing smells strongly of cluon deficiency.


(Fourth, certtool sucks for 24000 random bits out of /dev/urandom
before generating a much smaller result that doesn't even need to be
cryptographically secure.  That's an egregious bug all by itself, and
has been reported.)