Claus Assmann | 1 Mar 2012 01:00

Re: OpenSSL 1.0.1 beta 3: some test results

OpenSSL 1.0.1-beta3 23 Feb 2012
make && make test
succeeded on:

platform: solaris64-x86_64-cc
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) 
compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -xarch=amd64
-xstrconst -Xa -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM

platform: solaris64-sparcv9-cc
options:  bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) idea(int) blowfish(ptr) 
compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v9
-xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DAES_ASM -DGHASH_ASM

platform: BSD-x86-elf
options:  bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) 
compiler: gcc -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer -Wall
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM

Thanks.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

(Continue reading)

Muneer pasha | 1 Mar 2012 08:17
Picon

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


yerracs | 1 Mar 2012 07:49
Picon

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 <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Yair Elharrar | 1 Mar 2012 09:33
Favicon

RE: KAT for RSA encrypt/decrypt

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-dev <at> openssl.org [mailto:owner-openssl-dev <at> openssl.org] On Behalf Of yerracs
Sent: Thursday, March 01, 2012 08:50
To: openssl-dev <at> 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 <at> openssl.org
Automated List Manager                           majordomo <at> 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 <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Adrian Kotelba | 1 Mar 2012 11:18

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

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 <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Tomas Svensson via RT | 1 Mar 2012 15:44
Picon
Favicon

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

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.000000000 +0100
+++ asn1_lib.c	2012-01-17 15:33:53.000000000 +0100
 <at>  <at>  -172,12 +172,11  <at>  <at> 
 			{
 			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

Erik Tkal | 1 Mar 2012 17:16
Favicon

Re: Limiting EC curves in ClientHello

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 <bmoeller <at> acm.org<mailto:bmoeller <at> acm.org>>
Reply-To: "openssl-dev <at> openssl.org<mailto:openssl-dev <at> openssl.org>" <openssl-dev <at> openssl.org<mailto:openssl-dev <at> openssl.org>>
Date: Wed, 29 Feb 2012 18:52:11 -0500
To: "openssl-dev <at> openssl.org<mailto:openssl-dev <at> openssl.org>" <openssl-dev <at> openssl.org<mailto:openssl-dev <at> 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 <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Erik Tkal | 1 Mar 2012 17:22
Favicon

Re: Need EAP-FAST support in 0.9.8 openssl

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 <munirpasha <at> gmail.com<mailto:munirpasha <at> gmail.com>>
Reply-To: "openssl-dev <at> openssl.org<mailto:openssl-dev <at> openssl.org>" <openssl-dev <at> openssl.org<mailto:openssl-dev <at> openssl.org>>
Date: Thu, 1 Mar 2012 02:17:19 -0500
To: "openssl-dev <at> openssl.org<mailto:openssl-dev <at> openssl.org>" <openssl-dev <at> openssl.org<mailto:openssl-dev <at> 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 <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Bodo Moeller | 1 Mar 2012 17:52
Picon
Favicon

Re: Limiting EC curves in ClientHello

On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal <etkal <at> 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

Erik Tkal | 1 Mar 2012 22:06
Favicon

RE: Limiting EC curves in ClientHello

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-dev <at> openssl.org [mailto:owner-openssl-dev <at> openssl.org] On Behalf Of Bodo Moeller
Sent: Thursday, March 01, 2012 11:52 AM
To: openssl-dev <at> openssl.org
Subject: Re: Limiting EC curves in ClientHello

 

On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal <etkal <at> 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


Gmane