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
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:
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
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()
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
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
On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal 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)
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 4:06 PM, Erik Tkal et...@juniper.net 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
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
[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.
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 et...@juniper.net wrote:
You mentioned previously that you can get it to
* 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
13 matches
Mail list logo
