* 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
_
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 o
> [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
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 t
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. Set
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
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(2
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 (previous
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 on
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 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
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.o
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 c
13 matches
Mail list logo
