答复： Re: [PATCH] to add a switch to openssl's compression methords
在 10:23 下午 的 5/24/2011 上，在讯息 20110524142324.ga29...@panix.com 中，Thor Lancelot Simon t...@panix.com 写入： On Tue, May 24, 2011 at 05:10:03PM +0800, GuanJun He wrote: Hi, This is a patch to add a switch to openssl's compression methords(if compression methords are configured to compile in, 'config zlib').Add an environment variable to control compression methords on and off.As you know,more and more architectures have hardware compression methords already, to get benifit from the hardware compression, and to get a good performance,we need a switch as this. I don't understand this. Are you suggesting that some hardware mechanism is trying to compress data _after_ OpenSSL handles it? Turning off compression in OpenSSL won't help with this, since the resulting SSL/TLS stream will stil be basically uncompressible. Or, are you suggesting that some hardware mechanism has compressed the application-layer data _before_ OpenSSL sees it, and thus the compression in OpenSSL is just a waste of cycles? thank you very much for your reply! And sorry for my unclear descriptions. I mean OpenSSL compresses data before the encryption(zlib compiled in), having a massive performance impact (throughput decrease, CPU load increase) on platforms with cryptographic hardware.So, when using openssl with zlib compiled in, we expect to have a switch provided to user to configure whether compression is on or off.then, if on platforms with cryptographic hardware, users can simply turn the compression off. Do you have any advice to this? and please feel free to comment. Either way, it might be better to add explicit support for offloading compression to hardware. This can be done through /dev/crypto on NetBSD, for example, but unfortunately OpenSSL's engine for /dev/crypto is old and does not know how to use this feature. This may be another feature I think.And also, I'm interested in it. thanks a lot, Guanjun Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2524] openssl 1.0.0d bug report/ query
Hi Steve, I'm using curl 7.21.6 to make the request. When I build it with openssl 0.9.8i uppercase hostnames work fine. However, when I build curl with openssl 1.0.0d I get a 400 (bad request) with uppercase hostnames, but only with https requests. Http requests are fine. Any ideas? Kind Regards, Sam. -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: 24 May 2011 18:29 To: Gardner, Sam Cc: openssl-dev@openssl.org Subject: [openssl.org #2524] openssl 1.0.0d bug report/ query [sam.gard...@echostar.com - Mon May 23 12:29:05 2011]: Hi, I have recently upgraded from openssl 0.9.8i to 1.0.0d, and noticed that if the host name is in upper case that I get a 400 (bad request) when doing a https request. This was working in version 0.9.8i. My OS is Linux. Is there a fix for this? I'm not sure this has anything to do with OpenSSL. Which application are you specifying the host name? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
New Timing Attack on OpenSSL ECDSA
Hi all, Is there any plan for implementing counter measures against the newly discovered vulnerability in ECDSA operations of OpenSSL? For those not aware of it, here is the US-CERT link of this vulnerability : http://www.kb.cert.org/vuls/id/536044 Here is also the original paper that contains the vulnerability details : http://eprint.iacr.org/2011/232.pdf The patch suggested by the paper seems simple enough. It can be enhanced by adding a random multiple of the order to the scalar k. Is there any objection for getting this merged into OpenSSL source? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2524] openssl 1.0.0d bug report/ query
Hi Steve, I'm using curl 7.21.6 to make the request. When I build it with openssl 0.9.8i uppercase hostnames work fine. However, when I build curl with openssl 1.0.0d I get a 400 (bad request) with uppercase hostnames, but only with https requests. Http requests are fine. Any ideas? Kind Regards, Sam. -Original Message- From: Stephen Henson via RT [mailto:r...@openssl.org] Sent: 24 May 2011 18:29 To: Gardner, Sam Cc: openssl-dev@openssl.org Subject: [openssl.org #2524] openssl 1.0.0d bug report/ query [sam.gard...@echostar.com - Mon May 23 12:29:05 2011]: Hi, I have recently upgraded from openssl 0.9.8i to 1.0.0d, and noticed that if the host name is in upper case that I get a 400 (bad request) when doing a https request. This was working in version 0.9.8i. My OS is Linux. Is there a fix for this? I'm not sure this has anything to do with OpenSSL. Which application are you specifying the host name? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2533] [PATCH] Setting SSL_MODE_RELEASE_BUFFERS crashes with DTLS
Setting SSL_MODE_RELEASE_BUFFERS should be ignored for DTLS, but instead causes
the program to crash. This is due to missing version checks and is fixed with
this patch.
Best regards
Robin
--- ssl/s3_pkt.c11 May 2011 13:37:52 - 1.72.2.7.2.7
+++ ssl/s3_pkt.c25 May 2011 11:13:58 -
@@ -247,7 +247,8 @@
if (i = 0)
{
rb-left = left;
- if (s-mode SSL_MODE_RELEASE_BUFFERS)
+ if (s-mode SSL_MODE_RELEASE_BUFFERS
+ SSL_version(s) != DTLS1_VERSION SSL_version(s)
!= DTLS1_BAD_VER)
if (len+left == 0)
ssl3_release_read_buffer(s);
return(i);
@@ -866,7 +867,8 @@
{
wb-left=0;
wb-offset+=i;
- if (s-mode SSL_MODE_RELEASE_BUFFERS)
+ if (s-mode SSL_MODE_RELEASE_BUFFERS
+ SSL_version(s) != DTLS1_VERSION SSL_version(s)
!= DTLS1_BAD_VER)
ssl3_release_write_buffer(s);
s-rwstate=SSL_NOTHING;
return(s-s3-wpend_ret);
dtls-release-buffers-bug-1.0.1.patch
Description: Binary data
dtls-release-buffers-bug-1.0.0.patch
Description: Binary data
Fwd: New Timing Attack on OpenSSL ECDSA
David, Would your ECDSA implementation be subject to the following timing attack? Original Message Subject:New Timing Attack on OpenSSL ECDSA Date: Wed, 25 May 2011 15:59:58 +0200 From: Mounir IDRASSI mounir.idra...@idrix.net Reply-To: openssl-dev@openssl.org Organization: IDRIX To: openssl-dev@openssl.org Hi all, Is there any plan for implementing counter measures against the newly discovered vulnerability in ECDSA operations of OpenSSL? For those not aware of it, here is the US-CERT link of this vulnerability : http://www.kb.cert.org/vuls/id/536044 Here is also the original paper that contains the vulnerability details : http://eprint.iacr.org/2011/232.pdf The patch suggested by the paper seems simple enough. It can be enhanced by adding a random multiple of the order to the scalar k. Is there any objection for getting this merged into OpenSSL source? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: ??? Re: [PATCH] to add a switch to openssl's compression methords
On Tue, May 24, 2011 at 07:45:34PM -0600, Guan Jun He wrote: ? 10:23 ?? ? 5/24/2011 ? 20110524142324.ga29...@panix.com ??Thor Lancelot Simon t...@panix.com ??? On Tue, May 24, 2011 at 05:10:03PM +0800, GuanJun He wrote: Hi, This is a patch to add a switch to openssl's compression methords(if compression methords are configured to compile in, 'config zlib').Add an environment variable to control compression methords on and off.As you know,more and more architectures have hardware compression methords already, to get benifit from the hardware compression, and to get a good performance,we need a switch as this. I don't understand this. Are you suggesting that some hardware mechanism is trying to compress data _after_ OpenSSL handles it? Turning off compression in OpenSSL won't help with this, since the resulting SSL/TLS stream will stil be basically uncompressible. I mean OpenSSL compresses data before the encryption(zlib compiled in), having a massive performance impact (throughput decrease, CPU load increase) on platforms with cryptographic hardware. It seems to me you've said two differnt things, and I don't know which you mean. Do you mean on platforms with hardware compression methods or on platforms with cryptographic hardware? Or do you have a platform with both features, and a version of OpenSSL modified to take advantage of the platform's hardware cryptographic features, but not the platform's hardware compression features? I was in that situation for some time. I personally think that compression in OpenSSL needs to be made a first-class transform such that it can be handed off to engines. Though of course the engine interface needs other enhancements to deal with platforms that can do fused transforms like compress-then-encrypt-then-MAC, or full-on SSL record handling. But it would be a start. I think it should also be the case that compression (or not) should be selectable via the existing interface for setting options on the SSL_CTX. That would provide a more elegant way of dealing with the issue you're seeing (which I assume is triggered by an increased number of peers who want to do compression at the SSL layer because of the support for this in Chrome and in Google's server software) rather than an environent variable work-around. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: New Timing Attack on OpenSSL ECDSA
Hi John, thanks for forwarding. There has been a short thread on this on attack-interest yesterday and today. The way that these timing attacks work is that the attacker will time a lot of crypto operations (in this case the ECDSA signing operation) and then exploit the fact that the time taken by the algorithm depends to some extent on the private key or on another secret value (in this case the secret k used in ECDSA signing). If the signing operation has a branch on the bits of the secret key, so that a 1 bit will cause an operation that takes longer that if a 0 bit is present, then this will cause a key-dependent timing. In elliptic curve cryptography, the secret is always the exponent used in the exponentiation routine. I think our implementation is safe against this type of attacks. We use a sliding window method for exponentiation, so that the branching takes place on windows. The exponent is broken up into 4- bit windows. There is a loop over all the windows, and each window gets processed by a switch statement to determine what ec_group_element should get multiplied into the accumulator r. In the case in which all the bits of the window are zero, then this is a multiplication by the identity element, and we can skip that multiplication if we want. However, I put in a dummy operation to make sure that a multiplication gets done even when the window is all zero: case 0x0: /* multiply by IE, which we don't need to actually perform */ //printf(multiplying r by 1\n); // ec_group_elementH_print(x0); printf (\n); #ifdef DUMMY_MULT ec_group_mult(dum, dum, r, C); #endif break; So as long as the compiler doesn't optimize away that ec_group_mult() operation, the execution time of the exponentiation routine ought to be independent of the exponent. I have skimmed over the paper, and it turns out that the dependency on the exponent that they exploit is the fact that the openssl exponentiation for binary curves skips over the initial zero bits in the exponent. The signature only leaks information when there are a significant number of leading zeros. It would not be hard to write a function that collected timing information based on different exponents, and could estimate/detect this sort of vulnerability. That would be a *great* thing to add to our test suite. But since it doesn't need to go inside the canister, let's put off implementing it until after next Tues ;-) David On May 25, 2011, at 7:52 AM, John Foley wrote: David, Would your ECDSA implementation be subject to the following timing attack? Original Message Subject:New Timing Attack on OpenSSL ECDSA Date: Wed, 25 May 2011 15:59:58 +0200 From: Mounir IDRASSI mounir.idra...@idrix.net Reply-To: openssl-dev@openssl.org Organization: IDRIX To: openssl-dev@openssl.org Hi all, Is there any plan for implementing counter measures against the newly discovered vulnerability in ECDSA operations of OpenSSL? For those not aware of it, here is the US-CERT link of this vulnerability : http://www.kb.cert.org/vuls/id/536044 Here is also the original paper that contains the vulnerability details : http://eprint.iacr.org/2011/232.pdf The patch suggested by the paper seems simple enough. It can be enhanced by adding a random multiple of the order to the scalar k. Is there any objection for getting this merged into OpenSSL source? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: New Timing Attack on OpenSSL ECDSA
Hi, David. So what is the meaning of the Affected status for OpenSSL? Is that simply because ECDSA is supported by OpenSSL? Or did they actually test against an implementation that exhibited the vulnerability? Either way, FIPS 140-3 will only require protection against non-invasive attacks at level 3 and higher. Cheers, Paul _ Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 | paul.suh...@quantum.com mailto:paul.suh...@quantum.com Preserving the World's Most Important Data. Yours.(tm) From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of David McGrew Sent: Wednesday, May 25, 2011 8:25 AM To: John Foley Cc: openssl-dev@openssl.org Subject: Re: New Timing Attack on OpenSSL ECDSA Hi John, thanks for forwarding. There has been a short thread on this on attack-interest yesterday and today. The way that these timing attacks work is that the attacker will time a lot of crypto operations (in this case the ECDSA signing operation) and then exploit the fact that the time taken by the algorithm depends to some extent on the private key or on another secret value (in this case the secret k used in ECDSA signing). If the signing operation has a branch on the bits of the secret key, so that a 1 bit will cause an operation that takes longer that if a 0 bit is present, then this will cause a key-dependent timing. In elliptic curve cryptography, the secret is always the exponent used in the exponentiation routine. I think our implementation is safe against this type of attacks. We use a sliding window method for exponentiation, so that the branching takes place on windows. The exponent is broken up into 4-bit windows. There is a loop over all the windows, and each window gets processed by a switch statement to determine what ec_group_element should get multiplied into the accumulator r. In the case in which all the bits of the window are zero, then this is a multiplication by the identity element, and we can skip that multiplication if we want. However, I put in a dummy operation to make sure that a multiplication gets done even when the window is all zero: case 0x0: /* multiply by IE, which we don't need to actually perform */ //printf(multiplying r by 1\n); // ec_group_elementH_print(x0); printf (\n); #ifdef DUMMY_MULT ec_group_mult(dum, dum, r, C); #endif break; So as long as the compiler doesn't optimize away that ec_group_mult() operation, the execution time of the exponentiation routine ought to be independent of the exponent. I have skimmed over the paper, and it turns out that the dependency on the exponent that they exploit is the fact that the openssl exponentiation for binary curves skips over the initial zero bits in the exponent. The signature only leaks information when there are a significant number of leading zeros. It would not be hard to write a function that collected timing information based on different exponents, and could estimate/detect this sort of vulnerability. That would be a *great* thing to add to our test suite. But since it doesn't need to go inside the canister, let's put off implementing it until after next Tues ;-) David On May 25, 2011, at 7:52 AM, John Foley wrote: David, Would your ECDSA implementation be subject to the following timing attack? Original Message Subject: New Timing Attack on OpenSSL ECDSA Date: Wed, 25 May 2011 15:59:58 +0200 From: Mounir IDRASSI mounir.idra...@idrix.net mailto:mounir.idra...@idrix.net Reply-To: openssl-dev@openssl.org Organization: IDRIX To: openssl-dev@openssl.org Hi all, Is there any plan for implementing counter measures against the newly discovered vulnerability in ECDSA operations of OpenSSL? For those not aware of it, here is the US-CERT link of this vulnerability : http://www.kb.cert.org/vuls/id/536044 Here is also the original paper that contains the vulnerability details : http://eprint.iacr.org/2011/232.pdf The patch suggested by the paper seems simple enough. It can be enhanced by adding a random multiple of the order to the scalar k. Is there any objection for getting this merged into OpenSSL source? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless
Re: New Timing Attack on OpenSSL ECDSA
Hi all, The paper is clearly indicating that they successfully mounted a practical attack againt OpenSSL TLS implementation that uses elliptic curves and ECDHE_ECDSA based ciphers. They used the OpenSSL s_server utility and the versions indicated in their paper is 0.9.8o and 1.0.1a. I'm not aware of any changes in this part of OpenSSL since these versions were release so all current OpenSSL version are vulnerable. David: Can explain a little more you argument? I couldn't find the code referenced in your email in the OpenSSL source and I'm not sure how the details you gave are linked to OpenSSL implementation. As I stated in my first email, the paper comes with a temporary patch that should mitigate this issue. Is there any one working on this? I think it should be taken seriously even if ECDSA based ciphers are not widely used. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 5/25/2011 7:20 PM, Paul Suhler wrote: Hi, David. So what is the meaning of the “Affected” status for OpenSSL? Is that simply because ECDSA is supported by OpenSSL? Or did they actually test against an implementation that exhibited the vulnerability? Either way, FIPS 140-3 will only require protection against non-invasive attacks at level 3 and higher. Cheers, Paul *_* Paul A. Suhler| Firmware Engineer |Quantum Corporation| Office:949.856.7748 | paul.suh...@quantum.com mailto:paul.suh...@quantum.com *Preserving the World's Most Important Data. **Yours**.™* *From:*owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] *On Behalf Of *David McGrew *Sent:* Wednesday, May 25, 2011 8:25 AM *To:* John Foley *Cc:* openssl-dev@openssl.org *Subject:* Re: New Timing Attack on OpenSSL ECDSA Hi John, thanks for forwarding. There has been a short thread on this on attack-interest yesterday and today. The way that these timing attacks work is that the attacker will time a lot of crypto operations (in this case the ECDSA signing operation) and then exploit the fact that the time taken by the algorithm depends to some extent on the private key or on another secret value (in this case the secret k used in ECDSA signing). If the signing operation has a branch on the bits of the secret key, so that a 1 bit will cause an operation that takes longer that if a 0 bit is present, then this will cause a key-dependent timing. In elliptic curve cryptography, the secret is always the exponent used in the exponentiation routine. I think our implementation is safe against this type of attacks. We use a sliding window method for exponentiation, so that the branching takes place on windows. The exponent is broken up into 4-bit windows. There is a loop over all the windows, and each window gets processed by a switch statement to determine what ec_group_element should get multiplied into the accumulator r. In the case in which all the bits of the window are zero, then this is a multiplication by the identity element, and we can skip that multiplication if we want. However, I put in a dummy operation to make sure that a multiplication gets done even when the window is all zero: case 0x0: /* multiply by IE, which we don't need to actually perform */ //printf(multiplying r by 1\n); // ec_group_elementH_print(x0); printf (\n); #ifdef DUMMY_MULT ec_group_mult(dum, dum, r, C); #endif break; So as long as the compiler doesn't optimize away that ec_group_mult() operation, the execution time of the exponentiation routine ought to be independent of the exponent. I have skimmed over the paper, and it turns out that the dependency on the exponent that they exploit is the fact that the openssl exponentiation for binary curves skips over the initial zero bits in the exponent. The signature only leaks information when there are a significant number of leading zeros. It would not be hard to write a function that collected timing information based on different exponents, and could estimate/detect this sort of vulnerability. That would be a *great* thing to add to our test suite. But since it doesn't need to go inside the canister, let's put off implementing it until after next Tues ;-) David On May 25, 2011, at 7:52 AM, John Foley wrote: David, Would your ECDSA implementation be subject to the following timing attack? Original Message *Subject: * New Timing Attack on OpenSSL ECDSA *Date: * Wed, 25 May 2011 15:59:58 +0200 *From: * Mounir IDRASSI mounir.idra...@idrix.net mailto:mounir.idra...@idrix.net *Reply-To: * openssl-dev@openssl.org mailto:openssl-dev@openssl.org *Organization: * IDRIX *To: * openssl-dev@openssl.org mailto:openssl-dev@openssl.org Hi all, Is there any plan for implementing counter measures against the newly discovered vulnerability in ECDSA operations of
