Re: AES-NI in 1.0.1

So if you directly use the AES API you used to have a little better performance, but now you don't get the AES-NI support and so are a factor slower when using it. Is this the normal and expected behaviour? >>> I hope this isn't true. If it is, it means applications

Re: AES-NI in 1.0.1

On Sun, Mar 18, 2012 at 07:24:25PM +0100, Andy Polyakov wrote: > >> So if you directly use the AES API you used to have a little better > >> performance, > >> but now you don't get the AES-NI support and so are a factor slower when > >> using it. > >> > >> Is this the normal and expected behaviou

Re: AES-NI in 1.0.1

>>> 1.0.1: >>> $ openssl speed aes-128-cbc: >>> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 >>> bytes >>> aes-128 cbc 110450.10k 120831.36k 122216.11k 123465.05k >>> 123909.46k >>> >>> $ openssl speed -evp aes-128-cbc: >>> type 16 bytes 64 b

Re: AES-NI in 1.0.1

On Sun, Mar 18, 2012 at 07:16:27PM +0100, Andy Polyakov wrote: > Hi, > > > 1.0.1: > > $ openssl speed aes-128-cbc: > > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > > bytes > > aes-128 cbc 110450.10k 120831.36k 122216.11k 123465.05k > > 123909.46k > > > >

Re: AES-NI in 1.0.1

>> So if you directly use the AES API you used to have a little better >> performance, >> but now you don't get the AES-NI support and so are a factor slower when >> using it. >> >> Is this the normal and expected behaviour? > > I hope this isn't true. If it is, it means applications like OpenS

Re: AES-NI in 1.0.1

Hi, > 1.0.1: > $ openssl speed aes-128-cbc: > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes > aes-128 cbc 110450.10k 120831.36k 122216.11k 123465.05k 123909.46k > > $ openssl speed -evp aes-128-cbc: > type 16 bytes 64 bytes256 bytes

Re: AES-NI in 1.0.1

On Sun, Mar 18, 2012 at 05:57:24PM +0100, Kurt Roeckx wrote: > > So if you directly use the AES API you used to have a little better > performance, > but now you don't get the AES-NI support and so are a factor slower when > using it. > > Is this the normal and expected behaviour? I hope this

AES-NI in 1.0.1

Hi, I was looking at the AES-NI support in 1.0.1, and it seems that it now has been merged in EVP (but test/test_aesni still exists in HEAD). This has the following effect: 1.0.0h: $ openssl speed aes-128-cbc: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128

Re: macro expanding error

On Sun, Mar 18, 2012, yushang wrote: > Hi all, > I'm compiling openssl-0.9.8p on Windows and find a strange thing in > crypto/err/err_all.c , for example , > the original declaration in crypto/store/store.h(line 390) is > ... > X509_NAME *STORE_ATTR_INFO_get0_dn(STORE_ATTR_INFO *attrs, > STORE_ATT

[openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0

> [k...@roeckx.be - Sun Mar 18 01:03:05 2012]: > > On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote: > > I can confirm that removing the "no-ssl2" part gets me a TLS > > instead of SSLv3 connection. > > The problem seems to be this code in s_client.c: > #if !defined(OPENSSL_NO_S

Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0

On 03/17/2012 05:32 PM, Bodo Moeller wrote: >>> My reading of RFC4492 is that the ECC ciphersuites apply only to TLS >>> 1.0 or later. According to it: "This document describes additions to TLS >>> to support ECC, applicable both to TLS Version 1.0 [2] and to TLS >>> Version 1.1 [3]. In particu

Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0

"Nikos Mavrogiannopoulos via RT" writes: [...] > Indeed interesting. I downloaded 1.0.0h from source I saw the behavior > you describe. The issue is triggered on the version 1.0.0h as > distributed by debian. I don't see anything obviously related in the list of Debian-specific patches:

Re: [openssl.org #2765] openssl negotiates ECC ciphersuites in SSL 3.0

On 03/17/2012 09:03 PM, Stephen Henson via RT wrote: >> [n...@gnutls.org - Sat Mar 17 16:08:24 2012]: >> >> >> I captured the handshake (attached), and it seems the client >> advertises TLS 1.2. Could it be that the fallback is on the lowest >> supported version rather than the next available? >