Bug#475194: [exim-dev] Bug#475194: D-H parameter generation is All Wrong
Dear anonymous crypto-expert, On Sun, Apr 13, 2008 at 01:58:46PM +0200, Tom Kistner wrote: It's also not very important that the D-H parameters be changed often; So there still is some value in changing them? while changing them N times makes it N times as much work for an attacker that wants to read ALL of your mail, it's better to just use a larger prime and make it N times harder for an attacker to read ANY of your mail. What about doing both? :) It would help if you'd answer the question that Tom has asked three weeks ago since you seem to have knowledge that only a few people on this list have. In fact, many cryptographic standards just specify a menu of fixed D-H parameters for all implmentations for all time (e.g. RFC3526). Generating a set once at install time is also reasonable. Changing it daily is silly. 39.3 does not say daily, it says the frequency depending on your paranoia level. Now how paranoid should Debian be? I have no idea, and with my limited crypto skills, I can't give them a recommendation. Stock Exim does exacly what you want, compute D-H params exactly once. And Debian has changed the DH parameter size to 2048 bits (hoping that the patch I applied to tls-gnu.c #defining DH_BITS to 2048 and PARAM_SIZE to 2*2048 was all that needed changing). Since generation of 2048 bits DH parameters takes a long time even on recent systems, I have disabled the generation of DH parameters completely, so all Debian installations are now using a set of DH parameters generated at packae build time. We still ship the script that was used to regenerate the parameters daily, so local admins may choose to invoke it on a regular basis. I do sincerely hope that this is an acceptable compromise, I do not have sufficient crypto knowledge to be a judge. I might also mention that 1024 bits (which is O(2^80) operations to break) is considered a bit small for serious security these days. GNU TLS defaults to 2048 bits, a more reasonable default. Paranoia level again :) I'd trust the GnuTLS people to know what they're doing and go with their default. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: [exim-dev] Bug#475194: D-H parameter generation is All Wrong
Dear anonymous Crypto-Expert, There appears to be a fundamental misapprehension about the role of Diffie-Hellman parameters. Section 39.3 conflates them with the the RSA secret key, which is actual secret key material and should not be called a parameter. The D-H parameters are not key material, and do not need to be protected from inspection. In fact, they are sent in the clear to everyone who initiates a TLS session. Since the Debian package doesn't generate an RSA key at all, the restrictive permissions looked like blatant cluelessness. I've removed the references to RSA from 39.3 completely, thanks. It's also not very important that the D-H parameters be changed often; So there still is some value in changing them? while changing them N times makes it N times as much work for an attacker that wants to read ALL of your mail, it's better to just use a larger prime and make it N times harder for an attacker to read ANY of your mail. What about doing both? :) In fact, many cryptographic standards just specify a menu of fixed D-H parameters for all implmentations for all time (e.g. RFC3526). Generating a set once at install time is also reasonable. Changing it daily is silly. 39.3 does not say daily, it says the frequency depending on your paranoia level. Now how paranoid should Debian be? I have no idea, and with my limited crypto skills, I can't give them a recommendation. Stock Exim does exacly what you want, compute D-H params exactly once. I might also mention that 1024 bits (which is O(2^80) operations to break) is considered a bit small for serious security these days. GNU TLS defaults to 2048 bits, a more reasonable default. Paranoia level again :) /tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: D-H parameter generation is All Wrong
I assume you're referring to the recommendations in section 39.3 of spec.txt? That places (really secret) RSA key material in the same file. Which nicely explains the otherwise perplexing permission bits. But can you briefly explain the purpose of the RSA secret key there, and why it is not included in the Debian package? Is it used for encryption, signing, or both? It's used for RSA_EXPORT support. We've already removed that because it's completely unnecessary in practice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: D-H parameter generation is All Wrong
Marc Haber [EMAIL PROTECTED] wrote: On Wed, Apr 09, 2008 at 10:34:00AM -0400, [EMAIL PROTECTED] wrote: 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. It is, however, in accordance with upstream's recommendations. I wish I could come up with a polite way to put this, but the entire thing smells strongly of cluon deficiency. Point taken. Please give the same advice upstream and we'll follow once upstream changed their recommendations. I assume you're referring to the recommendations in section 39.3 of spec.txt? That places (really secret) RSA key material in the same file. Which nicely explains the otherwise perplexing permission bits. But can you briefly explain the purpose of the RSA secret key there, and why it is not included in the Debian package? Is it used for encryption, signing, or both? That will help me give appropriate advice upstream. (If you don't know, I can RTFS, but it gets a bit tangled.) Thank you very much! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: D-H parameter generation is All Wrong
I recently administered a stiff flaming to the Debian package maintainers for exim4, and was rebuffed with the observation that the behaviour I was complaing about was recommended by the exim specification, section 39.3. Marc Haber [EMAIL PROTECTED] wrote: On Wed, Apr 09, 2008 at 10:34:00AM -0400, [EMAIL PROTECTED] wrote: 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. It is, however, in accordance with upstream's recommendations. I wish I could come up with a polite way to put this, but the entire thing smells strongly of cluon deficiency. Point taken. Please give the same advice upstream and we'll follow once upstream changes their recommendations. So I'd like to suggest that the advice in that section undergo some considerable revision. There appears to be a fundamental misapprehension about the role of Diffie-Hellman parameters. Unlike the RSA secret key (which is actual secret key material and should not be called a parameter), the D-H parameters are not key material, and do not need to be protected from inspection. In fact, they are sent in the clear to everyone who initiates a TLS session. So if, like the Debian package does, you don't use the RSA key at all, there's no need to set restrictive permissions. In the Diffie-Hellman algorithm, the actual key is chosen fresh for each connection, and not stored on disk anywhere, ever. The only requirement is that they must not be maliciously chosen; an attacker who can choose the Diffie-Hellman modulus can make an attack easier. But there's no need to keep the values secret, any more than it's a secret that SMTP uses port 25. It's also not very important that the D-H parameters be changed often; while changing them N times makes it N times as much work for an attacker that wants to read ALL of your mail, it's better to just use a larger prime and make it N times harder for an attacker to read ANY of your mail. In fact, many cryptographic standards just specify a menu of fixed D-H parameters for all implmentations for all time (e.g. RFC3526). Generating a set once at install time is also reasonable. Changing it daily is silly. I might also mention that 1024 bits (which is O(2^80) operations to break) is considered a bit small for serious security these days. GNU TLS defaults to 2048 bits, a more reasonable default. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: D-H parameter generation is All Wrong
On Thu, 10 Apr 2008, [EMAIL PROTECTED] wrote: I recently administered a stiff flaming to the Debian package maintainers for exim4, and was rebuffed with the observation that the behaviour I was complaing about was recommended by the exim specification, section 39.3. From the headers of your message, it looks like you sent this just to myself. Please re-send to the exim development list at [EMAIL PROTECTED] I have retired from my job and am no longer doing any work on maintaining Exim. (However, I do confess that I am pretty clueless about encryption details. So any problems are no doubt my fault, but it will have to be somebody else that fixes them now. :-) Regards, Philip -- Philip Hazel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: D-H parameter generation is All Wrong
I recently administered a stiff flaming to the Debian package maintainers for exim4, and was rebuffed with the observation that the behaviour I was complaing about was recommended by the exim specification, section 39.3. Some of the original flame: Marc Haber [EMAIL PROTECTED] wrote: On Wed, Apr 09, 2008 at 10:34:00AM -0400, [EMAIL PROTECTED] wrote: 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. It is, however, in accordance with upstream's recommendations. I wish I could come up with a polite way to put this, but the entire thing smells strongly of cluon deficiency. Point taken. Please give the same advice upstream and we'll follow once upstream changes their recommendations. So I'd like to suggest that the advice in that section undergo some considerable revision. There appears to be a fundamental misapprehension about the role of Diffie-Hellman parameters. Section 39.3 conflates them with the the RSA secret key, which is actual secret key material and should not be called a parameter. The D-H parameters are not key material, and do not need to be protected from inspection. In fact, they are sent in the clear to everyone who initiates a TLS session. Since the Debian package doesn't generate an RSA key at all, the restrictive permissions looked like blatant cluelessness. In the Diffie-Hellman algorithm, the actual key is chosen fresh for each connection, and not stored on disk anywhere, ever. The only requirement for the parameters is that they must not be maliciously chosen; an attacker who can choose the Diffie-Hellman modulus can make an attack easier. But there's no need to keep the values secret, any more than it's a secret that SMTP uses port 25. It's also not very important that the D-H parameters be changed often; while changing them N times makes it N times as much work for an attacker that wants to read ALL of your mail, it's better to just use a larger prime and make it N times harder for an attacker to read ANY of your mail. In fact, many cryptographic standards just specify a menu of fixed D-H parameters for all implmentations for all time (e.g. RFC3526). Generating a set once at install time is also reasonable. Changing it daily is silly. I might also mention that 1024 bits (which is O(2^80) operations to break) is considered a bit small for serious security these days. GNU TLS defaults to 2048 bits, a more reasonable default. (As I mentioned earlier, the Debian package no longer generates an RSA key, and I can't find anything in src/tls-gnu.c that uses such a key, but there does appear to be somethink in tls-openssl.c. So I'm a bit confused about that part of things.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475194: D-H parameter generation is All Wrong
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]
Bug#475194: D-H parameter generation is All Wrong
I wish I could come up with a polite way to put this, but the entire thing smells strongly of cluon deficiency. You could have come up with a polite way to put this. There is always a polite way to tell things and when people don't tell things the polite way, this is generally because they lack some basic communication skills. I am not this package's maintainer but if I was, I would be very tempted to just ignore such an aggressively written bug report. Maybe, by chance, exim's maintainers will be in a better mood than I am signature.asc Description: Digital signature
Bug#475194: D-H parameter generation is All Wrong
On Wed, Apr 09, 2008 at 10:34:00AM -0400, [EMAIL PROTECTED] wrote: 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. It is, however, in accordance with upstream's recommendations. I wish I could come up with a polite way to put this, but the entire thing smells strongly of cluon deficiency. Point taken. Please give the same advice upstream and we'll follow once upstream changed their recommendations. Greetins Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
