Re: [openssl.org #2438] Resolved: [PATCH] ecrypto/ecdsa: fix a zero change in the test suite

2012-03-01 Thread Sebastian Andrzej Siewior via RT 
* Stephen Henson via RT | 2012-02-27 17:43:48 [+0100]:

>According to our records, your request has been resolved. If you have any
>further questions or concerns, please respond to this message.

Is there a commit id or patch somewhere where I can look at the fix?

Sebastian


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

Re: Limiting EC curves in ClientHello

2012-03-01 Thread Erik Tkal 
So then the question is will this be addressed in 1.0.1 or later?


Erik Tkal
et...@me.com




On Mar 1, 2012, at 5:35 PM, Bodo Moeller wrote:

> On Thu, Mar 1, 2012 at 4:06 PM, Erik Tkal  wrote:
> 
> You mentioned previously that you can get it to specify none or one curve?  I 
> don’t see how you would specify this, as it appears the client hello 
> preparation adds all of them is any EC cipher suite is specified?
> 
>  
> Oh, sorry, you are right. Setting up negotiation for one specific curve is 
> possible for the *server*-side implementation, but the *client*-side code 
> isn't even quite there yet.
> 
> Bodo
>

[openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0

2012-03-01 Thread Stephen Henson via RT 
> [to...@tutus.se - Thu Mar 01 15:44:36 2012]:
> 
> Hi,
> 
> In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
> parser that if one has length data such as
> 
> 84 00 00 00 00
> 
> at the end of a block to be parsed, it will give "header too long" error
> even though the ASN.1 is valid. 

The last time I looked that wasn't a valid encoding. The length must be
expressed in the minimum number of octets possible, that applies to BER
as well as DER.

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

Re: Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0

2012-03-01 Thread Dr. Stephen Henson 
On Thu, Mar 01, 2012, Adrian Kotelba wrote:

> In s3_lib.c ciphers 0x3B to 0x40 and 0x67 to 0x6D with SHA256 are set
> as SSL_TLSV1. Should it be SSL_TLSV1_2?
> 

Well I've seen implementations uses them in TLS 1.0 and 1.1 and it seemed
harmless to keep that. Anything not supporting them wont use them.

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

Re: Limiting EC curves in ClientHello

2012-03-01 Thread Bodo Moeller 
On Thu, Mar 1, 2012 at 4:06 PM, Erik Tkal  wrote:

You mentioned previously that you can get it to specify none or one curve?
> I don’t see how you would specify this, as it appears the client hello
> preparation adds all of them is any EC cipher suite is specified?
>

Oh, sorry, you are right. Setting up negotiation for one specific curve is
possible for the *server*-side implementation, but the *client*-side code
isn't even quite there yet.

Bodo

RE: Limiting EC curves in ClientHello

2012-03-01 Thread Erik Tkal 
You mentioned previously that you can get it to specify none or one curve?  I 
don't see how you would specify this, as it appears the client hello 
preparation adds all of them is any EC cipher suite is specified?


Erik Tkal
Juniper OAC/UAC/Pulse Development


From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On 
Behalf Of Bodo Moeller
Sent: Thursday, March 01, 2012 11:52 AM
To: openssl-dev@openssl.org
Subject: Re: Limiting EC curves in ClientHello

On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal 
mailto:et...@juniper.net>> wrote:
I looked around and found RFC 5430 - Suite B Profile for Transport Layer 
Security (TLS), which states:

  RFC 4492 defines a variety of elliptic curves.  For cipher suites
  defined in this specification, only secp256r1(23) or secp384r1(24)
  may be used.  ...

  Clients desiring to negotiate only a Suite B compliant connection
  MUST generate a "Supported Elliptic Curves Extension" containing only
  the allowed curves.

So does this mean that OpenSSL will not support RFC 5430 / Suite B in 1.0.1?

RFC 5430 specifies that "A Suite B compliant TLS server MUST be configured to 
support the 128-bit security level, the 192-bit security level, or both 
security levels." OpenSSL can be configured for the 128-bit security level 
(using secp256r1) or for the 192-bit security level (using secp384r1), but it 
currently can't be configured to cleanly support both. (The section from which 
you quoted also says that "Clients that are willing to do both Suite B 
compliant and non-Suite B compliant connections MAY omit the extension or send 
the extension but offer other curves as well as the appropriate Suite B ones."  
I don't think that supporting Suite B means that you can't also allow non-Suite 
B compliant connections, with clients that don't support Suite B.)

So without having checked all of the formal requirements, I think that OpenSSL 
1.0.1 will support Suite B as specified by RFC 5430, even though there's not 
yet a good way to enable two or more explicitly chosen elliptic curves while 
disabling all the others.

Bodo

Re: Limiting EC curves in ClientHello

2012-03-01 Thread Bodo Moeller 
On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal  wrote:

> I looked around and found RFC 5430 - Suite B Profile for Transport Layer
> Security (TLS), which states:
>
>   RFC 4492 defines a variety of elliptic curves.  For cipher suites
>   defined in this specification, only secp256r1(23) or secp384r1(24)
>   may be used.  …
>
>   Clients desiring to negotiate only a Suite B compliant connection
>   MUST generate a "Supported Elliptic Curves Extension" containing only
>   the allowed curves.
>
> So does this mean that OpenSSL will not support RFC 5430 / Suite B in
> 1.0.1?
>

RFC 5430 specifies that "A Suite B compliant TLS server MUST be configured
to support the 128-bit security level, the 192-bit security level, or both
security levels." OpenSSL can be configured for the 128-bit security level
(using secp256r1) or for the 192-bit security level (using secp384r1), but
it currently can't be configured to cleanly support both. (The section from
which you quoted also says that "Clients that are willing to do both Suite
B compliant and non-Suite B compliant connections MAY omit the extension or
send the extension but offer other curves as well as the appropriate Suite
B ones."  I don't think that supporting Suite B means that you can't also
allow non-Suite B compliant connections, with clients that don't support
Suite B.)

So without having checked all of the formal requirements, I think that
OpenSSL 1.0.1 will support Suite B as specified by RFC 5430, even though
there's not yet a good way to enable two or more explicitly chosen elliptic
curves while disabling all the others.

Bodo

Re: Need EAP-FAST support in 0.9.8 openssl

2012-03-01 Thread Erik Tkal 
I think the changes to support the session ticket extension and session secret 
callback were not trivial, and such features would never be ported back to 
previous releases (unless it addressed a security vulnerability).

I migrated my code to use 1.0.0 in order to take advantage of this (previously 
we had a heavily modified 0.9.7 that added basically the same functionality).

  Erik


From: Muneer pasha mailto:munirpa...@gmail.com>>
Reply-To: "openssl-dev@openssl.org" 
mailto:openssl-dev@openssl.org>>
Date: Thu, 1 Mar 2012 02:17:19 -0500
To: "openssl-dev@openssl.org" 
mailto:openssl-dev@openssl.org>>
Subject: Need EAP-FAST support in 0.9.8 openssl

Hi,

The changes to support EAP-FAST is included in changes between 0.9.8n and 1.0.0.

Can this change be made available also in 0.9.8 tree?

Thanks,
Muneer

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

Re: Limiting EC curves in ClientHello

2012-03-01 Thread Erik Tkal 
I looked around and found RFC 5430 - Suite B Profile for Transport Layer 
Security (TLS), which states:

   RFC 4492 defines a variety of elliptic curves.  For cipher suites
   defined in this specification, only secp256r1(23) or secp384r1(24)
   may be used.  …

   Clients desiring to negotiate only a Suite B compliant connection
   MUST generate a "Supported Elliptic Curves Extension" containing only
   the allowed curves.

So does this mean that OpenSSL will not support RFC 5430 / Suite B in 1.0.1?

  Thanks,
  Erik


From: Bodo Moeller mailto:bmoel...@acm.org>>
Reply-To: "openssl-dev@openssl.org" 
mailto:openssl-dev@openssl.org>>
Date: Wed, 29 Feb 2012 18:52:11 -0500
To: "openssl-dev@openssl.org" 
mailto:openssl-dev@openssl.org>>
Subject: Re: Limiting EC curves in ClientHello


It appears there is no way to specify that only a subset should be used?

Yes, this is a know deficiency in the current code. I'm more familiar with the 
server side, but I think it's similar: if you set up *one* curve, then 
negotiation should happen accordingly; if you use a callback to provide curves, 
it will be expected to be able to handle any curve, which is fundamentally 
broken (a peer could be using a named curve that's not even defined yet).

So technically, there is a way to specific that only a subset should be used -- 
it's just that the subset needs to be of size 0 or 1, which isn't utterly 
flexible. We should get around to fixing that at some point.

Bodo

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

[openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0

2012-03-01 Thread Tomas Svensson via RT 
Hi,

In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as

84 00 00 00 00

at the end of a block to be parsed, it will give "header too long" error
even though the ASN.1 is valid. This is because the supplied max value
to asn1_get_length() in crypto/asn1/asn1_lib.c is used incorrectly.

It seems to me that the attached diff (against 1.0.1-beta1) is the
correct fix.

-Tomas



--- asn1_lib.c.orig 2012-01-17 15:37:43.0 +0100
+++ asn1_lib.c  2012-01-17 15:33:53.0 +0100
@@ -172,12 +172,11 @@
{
if (i > sizeof(long))
return 0;
-   if (max-- == 0) return(0);
while (i-- > 0)
{
+   if (max-- == 0) return(0);
ret<<=8L;
ret|= *(p++);
-   if (max-- == 0) return(0);
}
}
else

Openssl 1.0.1 beta3 - Some ciphers with SHA256 set as tls1.0

2012-03-01 Thread Adrian Kotelba 
In s3_lib.c ciphers 0x3B to 0x40 and 0x67 to 0x6D with SHA256 are set
as SSL_TLSV1. Should it be SSL_TLSV1_2?

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

RE: KAT for RSA encrypt/decrypt

2012-03-01 Thread Yair Elharrar 
Yerracs,
You need a pair-wise consistency test for RSA encrypt/decrypt. See FIPS 140-2 
section 4.9.2.

--Yair


-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On 
Behalf Of yerracs
Sent: Thursday, March 01, 2012 08:50
To: openssl-dev@openssl.org
Subject: KAT for RSA encrypt/decrypt


Hi All,

Is RSA encrypt/decrypt KAT(Known Answer Test) test required for power-on self 
tests for a cryptographic module?

If so, where can we find these KAT vectors for RSA encryption/decryption. I 
could only found KAT vectors for signature generation and verification.


--
View this message in context: 
http://old.nabble.com/KAT-for-RSA-encrypt-decrypt-tp33419152p33419152.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



This email and any files transmitted with it are confidential material. They 
are intended solely for the use of the designated individual or entity to whom 
they are addressed. If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, use, distribution or 
copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender 
and delete or destroy any copy of this message
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

KAT for RSA encrypt/decrypt

2012-03-01 Thread yerracs 

Hi All,

Is RSA encrypt/decrypt KAT(Known Answer Test) test required for power-on
self tests for a cryptographic module?

If so, where can we find these KAT vectors for RSA encryption/decryption. I
could only found KAT vectors for signature generation and verification.


-- 
View this message in context: 
http://old.nabble.com/KAT-for-RSA-encrypt-decrypt-tp33419152p33419152.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org