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_ATTR_TYPES code);
..
after preprocessing of
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?
That's
Nikos Mavrogiannopoulos via RT r...@openssl.org 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
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 particular, it
[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_SSL2)
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,
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
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 isn't
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 1024
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 OpenSSH
that
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
$ openssl speed
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 1024
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 behaviour?
I hope
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 OpenSSH
that
14 matches
Mail list logo
