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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
