Re: FIPS support with shared libraries on FreeBSD 9.1
I am facing the same issue and getting same error on FreeBED 9.1 as below. FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: Only thing different is I am using openssl-fips-2.0.5. Did anyone get solution for this problem? --Girish -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-support-with-shared-libraries-on-FreeBSD-9-1-tp44123p47256.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
Do you still see an error if you specify one cipher? f.e. AES256-SHA? On 2013-11-07 22:26, Dave Thompson wrote: From: owner-openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, November 07, 2013 11:02 On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: > I am using SSL_CTX_set_client_cert_cb to provide the client > certificate when needed. I have a problem in that OpenSSL 1.0.1e > does not trigger this callback for all websites that I expect it > to, only some. Instead on the failing sites there is an SSL > handshake failure after the client verifies the server certificate: You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? OP's log shows protocol hasn't reached the CertReq -> ClientCert steps so at this point nothing about the client cert should matter. (And in any case the signature *on* the cert is by the CA key, unless it's self signed, in which case using it for client-auth would be really silly. From the log, unless OP "fixed" it, the server cert looks like a DIY CA, and if someone does that for the server I would expect it for clients also.) To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a "custom" root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? > SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake > failure, errno 0 > > Interestingly if I compile against 1.0.0k then there is no failure > and the callback *is* triggered for all sites (that I have tried > so far anyway). Sounds like a problem with TLSv1.2. If your client certificate is only 512-bits it may not be wide enough to sign a SHA384 digest, or some other TLSv1.2 parameter issue. Client hasn't even selected the cert yet. And although I agree a PCAP is better in general than a less-complete program log, just looking at the headers in the log you can see the client offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) so there definitely isn't any SHA-2 issue. But something else related to TLSv1.2 does seem likely. Possibly the new larger size (as OP observed), or the new extensions, although the initial negotiation apparently worked fine with both. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. Capture the traffic with "tcpdump -s0 -w file ..." and look with "wireshark -r file". If you don't understand the wireshark output, post the (binary) PCAP file containing just one failed TLS handshake, perhaps also a PCAP file with a succesful TLS handshake. I do notice the second ClientHello -- in response to server request -- using 1.0.1 re-offers TLSv1.2. I thought it was good practice when we know the server has previously rejected something not to re-offer it, but I don't recall where I saw this and I might well be wrong. Even so the server should negotiate down (as it did initially) or at minimum send an alert, not just close. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
> From: owner-openssl-users On Behalf Of Viktor Dukhovni > Sent: Thursday, November 07, 2013 11:02 > On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: > > > I am using SSL_CTX_set_client_cert_cb to provide the client > > certificate when needed. I have a problem in that OpenSSL 1.0.1e > > does not trigger this callback for all websites that I expect it > > to, only some. Instead on the failing sites there is an SSL > > handshake failure after the client verifies the server certificate: > > You can test with s_client(1) and compare results. Is your client > certificate an RSA certificate? How many bits of public key? Is > its signature SHA1 or SHA256? > OP's log shows protocol hasn't reached the CertReq -> ClientCert steps so at this point nothing about the client cert should matter. (And in any case the signature *on* the cert is by the CA key, unless it's self signed, in which case using it for client-auth would be really silly. From the log, unless OP "fixed" it, the server cert looks like a DIY CA, and if someone does that for the server I would expect it for clients also.) To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a "custom" root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? > > SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake > > failure, errno 0 > > > > Interestingly if I compile against 1.0.0k then there is no failure > > and the callback *is* triggered for all sites (that I have tried > > so far anyway). > > Sounds like a problem with TLSv1.2. If your client certificate is > only 512-bits it may not be wide enough to sign a SHA384 digest, > or some other TLSv1.2 parameter issue. > Client hasn't even selected the cert yet. And although I agree a PCAP is better in general than a less-complete program log, just looking at the headers in the log you can see the client offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) so there definitely isn't any SHA-2 issue. But something else related to TLSv1.2 does seem likely. Possibly the new larger size (as OP observed), or the new extensions, although the initial negotiation apparently worked fine with both. > Attaching a PCAP file of the traffic is much more useful than hex > packet dumps. Capture the traffic with "tcpdump -s0 -w file ..." > and look with "wireshark -r file". If you don't understand the > wireshark output, post the (binary) PCAP file containing just one > failed TLS handshake, perhaps also a PCAP file with a succesful > TLS handshake. > I do notice the second ClientHello -- in response to server request -- using 1.0.1 re-offers TLSv1.2. I thought it was good practice when we know the server has previously rejected something not to re-offer it, but I don't recall where I saw this and I might well be wrong. Even so the server should negotiate down (as it did initially) or at minimum send an alert, not just close. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: sha256, was RE: SSL_set_msg_callback for application_data(23)
On Thu, Nov 07, 2013 at 03:51:38PM -0500, Dave Thompson wrote: > To support the (four original) SHA-2 hashes as such, yes. > But: if you want to sign (and I think verify?) SHA2 and DSA or ECDSA, > you need the new signature/hash mechanism in 1.0.0, and if > you want TLSv1.2 suites using HMAC-SHA256/384 you need 1.0.1. Furthermore, with OpenSSL 0.9.8, SSL_library_init() does not enable the SHA2 digests. You need OpenSSL_add_all_algorithms() or a suitable subset for that. So SSL/TLS applications based on 0.9.8 can't generally handle SHA2 digests in peer certificates. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: sha256, was RE: SSL_set_msg_callback for application_data(23)
Yes, I need to sign and verify so 1.0.0 or 1.0.1 even better. Thanks so much for the info. -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, November 07, 2013 3:52 PM To: openssl-users@openssl.org Subject: sha256, was RE: SSL_set_msg_callback for application_data(23) To support the (four original) SHA-2 hashes as such, yes. But: if you want to sign (and I think verify?) SHA2 and DSA or ECDSA, you need the new signature/hash mechanism in 1.0.0, and if you want TLSv1.2 suites using HMAC-SHA256/384 you need 1.0.1. > -Original Message- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Martin Hecht > Sent: Thursday, November 07, 2013 07:20 > To: openssl-users@openssl.org > Subject: Re: SSL_set_msg_callback for application_data(23) > > openssl >= 0.9.8 > > On 06.11.2013 17:08, Patetta, Nicholas wrote: > > Anyone know which version of OPENSSL is needed to support SHA256? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How do I sign an input using the V2.1 and not V1.5 version
If you mean the RSA-PSS scheme that was added in PKCS#1 v2.1, that isn't supported by rsautl. Try pkeyutl with -pkeyopt rsa_padding_mode:pss . Remember that the PKCS#1 v2.1 standard still includes the original (v1_5) and OAEP schemes which rsautl does support. The man page and usage message for rsautl both say the default is -pkcs meaning the v1_5 scheme. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ameet Lann Sent: Thursday, November 07, 2013 10:14 To: 'openssl-users@openssl.org' Subject: *** Spam *** How do I sign an input using the V2.1 and not V1.5 version Hi, We are trying to work with the openssl with the v2.1 and not the v1.5 from the command line. But it is not documented anywhere how to tell the openssl to work with one version or the other. For example we run the command: openssl rsautl -sign in sha256.bin -out signature.bin -inkey my_key.pem But we have no idea what version is used in doing this operation. So can you help us. Best regards, Ameet Lann
sha256, was RE: SSL_set_msg_callback for application_data(23)
To support the (four original) SHA-2 hashes as such, yes. But: if you want to sign (and I think verify?) SHA2 and DSA or ECDSA, you need the new signature/hash mechanism in 1.0.0, and if you want TLSv1.2 suites using HMAC-SHA256/384 you need 1.0.1. > -Original Message- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Martin Hecht > Sent: Thursday, November 07, 2013 07:20 > To: openssl-users@openssl.org > Subject: Re: SSL_set_msg_callback for application_data(23) > > openssl >= 0.9.8 > > On 06.11.2013 17:08, Patetta, Nicholas wrote: > > Anyone know which version of OPENSSL is needed to support SHA256? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How do I sign an input using the V2.1 and not V1.5 version
Hi, We are trying to work with the openssl with the v2.1 and not the v1.5 from the command line. But it is not documented anywhere how to tell the openssl to work with one version or the other. For example we run the command: openssl rsautl -sign in sha256.bin -out signature.bin -inkey my_key.pem But we have no idea what version is used in doing this operation. So can you help us. Best regards, Ameet Lann
RE: about openldap client ssl
Hi: When I use SSL authentication in LDAP client, If I set the "TLSVerifyClient demand" on openldap server side, then I'll got below error (set TLSVerifyClient as never/allow/try, I can login, but will have authentication failure in LDAP log) LS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate. 527b9a89 connection_read(16): TLS accept failure error=-1 id=1028, closing 527b9a89 connection_close: conn=1028 sd=16 Server config: TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3 TLSCACertificateFile /opt/etc/openldap/cert/CA.crt TLSCertificateFile /opt/etc/openldap/cert/ldap1.test.com.crt TLSCertificateKeyFile /opt/etc/openldap/cert/ldap1.test.com.key TLSVerifyClient demand Client config: uri ldaps://ldap1.test.com:636 bind_policy soft ldap_version 3 base dc=test,dc=com TLS_CACERT/opt/etc/openldap/CA.crt TLS_CERT /opt/etc/openldap/ldap1.test.com.crt TLS_KEY /opt/etc/openldap/ldap1.test.com.key TLS_REQCERT demand Any idea from you?
about openldap client ssl
Hi: If I set the "TLSVerifyClient demand" on openldap server side, then I'll got below error (set TLSVerifyClient as never/allow/try, I can login, but will have authentication failure in LDAP log) LS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate. 527b9a89 connection_read(16): TLS accept failure error=-1 id=1028, closing 527b9a89 connection_close: conn=1028 sd=16 Server config: TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3 TLSCACertificateFile /opt/etc/openldap/cert/CA.crt TLSCertificateFile /opt/etc/openldap/cert/ldap1.test.com.crt TLSCertificateKeyFile /opt/etc/openldap/cert/ldap1.test.com.key TLSVerifyClient demand Client config: uri ldaps://ldap1.test.com:636 bind_policy soft ldap_version 3 base dc=test,dc=com
Re: Read keys written with PEM_write_RSAPublicKey(), via command-line
On Thu, 7 Nov 2013, Dr. Stephen Henson wrote: On Thu, Nov 07, 2013, Dimitrios Apostolou wrote: how can I read the details of a public key written by PEM_write_RSAPublicKey()? I have tried all the "openssl pkey" and "openssl rsa" combinations without much success, unfortunately. If possible you should use PEM_write_RSA_PUBKEY instead. Otherwise for OpenSSL 1.0.0 and later you can use the (currently undocumented: about to fix that) -RSAPublicKey_in option. It works: openssl rsa -in $FILENAME -pubin -RSAPublicKey_in -text Dear Steve, you're a lifesaver. Thanks! Dimitris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ssl handshake failure in 1.0.1 but not 1.0.0
On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: > I am using SSL_CTX_set_client_cert_cb to provide the client > certificate when needed. I have a problem in that OpenSSL 1.0.1e > does not trigger this callback for all websites that I expect it > to, only some. Instead on the failing sites there is an SSL > handshake failure after the client verifies the server certificate: You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? > SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake > failure, errno 0 > > Interestingly if I compile against 1.0.0k then there is no failure > and the callback *is* triggered for all sites (that I have tried > so far anyway). Sounds like a problem with TLSv1.2. If your client certificate is only 512-bits it may not be wide enough to sign a SHA384 digest, or some other TLSv1.2 parameter issue. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. Capture the traffic with "tcpdump -s0 -w file ..." and look with "wireshark -r file". If you don't understand the wireshark output, post the (binary) PCAP file containing just one failed TLS handshake, perhaps also a PCAP file with a succesful TLS handshake. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem with TLS 1.2 client
Hello, I'm having quite weird problem with openssl (head version). I'm doing following test: Step 1: ./openssl s_client -connect some.server.org:443 -cipher "DEFAULT" I'm getting following error: CONNECTED(0003) 140453250619072:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In the tcpdump I see that ClientHello is sent and then server closes connection (FIN, FIN-ACK, ACK) Then I try ./openssl s_client -connect some.server.org:443 -cipher "ALL" This works perfectly, I get certificate & following session details: Protocol : TLSv1.2 Cipher: DHE-RSA-AES256-GCM-SHA384 As you can see above, server accepts cipher DHE-RSA-AES256-GCM-SHA384. But when I try to specify this cipher on command line: ./openssl s_client -connect some.server.org:443 -cipher "DHE-RSA-AES256-GCM-SHA384" ... again remote server closes remote connection. Unfortunately I don't know what kind of software is running on server side and it seems like problem is there. I've tried to reproduce such problem with few old versions of openssl but with no success. Also I've checked gnutls-cli and it works OK. Does anybody has any guess what could potentially cause this problem? PS: my version of openssl s_client has patch for PR#2771 (the one committed today) Kris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Read keys written with PEM_write_RSAPublicKey(), via command-line
On Thu, Nov 07, 2013, Dimitrios Apostolou wrote: > > how can I read the details of a public key written by > PEM_write_RSAPublicKey()? I have tried all the "openssl pkey" and > "openssl rsa" combinations without much success, unfortunately. > If possible you should use PEM_write_RSA_PUBKEY instead. Otherwise for OpenSSL 1.0.0 and later you can use the (currently undocumented: about to fix that) -RSAPublicKey_in option. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Read keys written with PEM_write_RSAPublicKey(), via command-line
Hello list, how can I read the details of a public key written by PEM_write_RSAPublicKey()? I have tried all the "openssl pkey" and "openssl rsa" combinations without much success, unfortunately. Thanks in advance, Dimitris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RHEL rpm and FIPS validation
Steve Marquess wrote on 11/07/2013 09:02:05 AM: > > Is there a basis for asserting FIPS 140 validation with > > openssl-0.9.8e-26.el5_9.1|(none), or must the original RPM be used? > > You'll need to ask Red Hat; it's their proprietary validation. From a > quick glance it appears to be a knock-off of the open source based > OpenSSL FIPS Object module you're probably confusing it with. Thanks for the rapid and insightful response! --woody -- Dr. Robert "Woody" GBS Cybersecurity & Weaver Privacy IT Security Architect Cell: 301-524-8138 -- Shick's Law: There is no problem a good miracle can't solve.
Re: FIPS_mode_set wrapper not available on pre-1.0.1 versions
On Wed, Nov 06, 2013, Karthik Krishnamurthy wrote: > I have an application built across various Unix flavors that uses > OpenSSL for SSL/TLS communication. I wanted to enable FIPS mode for my > application. But, it seems like not all OpenSSL version provides the > FIPS_mode_set wrapper function. > > Basically, I want to be able to seamlessly call FIPS_mode_set and > based on whether the libcrypto.so that gets loaded at runtime was > built with OPENSSL_FIPS or not, it should return 1 or 0. This is > something that OpenSSL 1.0.1 and later provides due to the presence of > FIPS_mode_set wrapper available in o_fips.c. How could I achieve > something like this in older OpenSSL versions? > > One obvious way is to dlopen the OpenSSL library and then later dlsym > FIPS_mode_set. Is there another way to accomplish this? > FIPS_mode_set is only present in FIPS capable versions of OpenSSL 0.9.8: there it is implemented in the validated module itself. OpenSSL versions of OpenSSL 1.0.1 and later always include an FIPS_mode_set function but it just returns an error if OpenSSL isn't FIPS capable. So without modifying OpenSSL dlopen/dlsym would work on other versions of OpenSSL. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS_mode_set wrapper not available on pre-1.0.1 versions
I have an application built across various Unix flavors that uses OpenSSL for SSL/TLS communication. I wanted to enable FIPS mode for my application. But, it seems like not all OpenSSL version provides the FIPS_mode_set wrapper function. Basically, I want to be able to seamlessly call FIPS_mode_set and based on whether the libcrypto.so that gets loaded at runtime was built with OPENSSL_FIPS or not, it should return 1 or 0. This is something that OpenSSL 1.0.1 and later provides due to the presence of FIPS_mode_set wrapper available in o_fips.c. How could I achieve something like this in older OpenSSL versions? One obvious way is to dlopen the OpenSSL library and then later dlsym FIPS_mode_set. Is there another way to accomplish this? Thanks, Karthik __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RHEL rpm and FIPS validation
On 11/07/2013 08:39 AM, Robert W Weaver wrote: > Greetings, > > Apologies if this has been covered before, but I couldn't find it in a > search. > > I'm trying to deploy FIPS 140 validated crypto to a RHEL 5 box as part > of a FISMA covered project. > > I think the relevant policy is > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1320.pdf > which states "The version of the RPM containing the validated module is > version 0.9.8e-22.el5_8.3." > > The rpm has moved on, and the version the support person wants to use > is openssl-0.9.8e-26.el5_9.1|(none) . > > Is there a basis for asserting FIPS 140 validation with > openssl-0.9.8e-26.el5_9.1|(none), or must the original RPM be used? You'll need to ask Red Hat; it's their proprietary validation. From a quick glance it appears to be a knock-off of the open source based OpenSSL FIPS Object module you're probably confusing it with. An alternative is to use the OpenSSL FIPS Object Module 1.2 (cert #1051) or preferably the newer 2.0 module (cert #1747). You can use either of those to create your own RPM. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Is aesni-intel module required for openssl
On Wed, Nov 06, 2013, sarav.sars wrote: > Is it necessary to load aesni-intel module like 'modprobe aesni-intel' ? > Loading this module makes no difference in openssl speed output. > > openssl speed -elapsed -evp aes-128-cbc > > before loading aesni-intel module > > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes > aes-128-cbc 561737.40k 598685.65k 610372.15k 610802.35k > 611521.88k > > after loading aesni-intel module > > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes > aes-128-cbc 563835.61k 598692.84k 608343.64k 610805.42k > 611524.61k > Which version of OpenSSL are you using? The latest (1.0.1) includes direct AES-NI support in the software algorithm implementation and not via ENGINE. You can shut off AES-NI support via the environment variable OPENSSL_ia32cap: for example: OPENSSL_ia32cap=~0x202 openssl speed -evp aes-128-cbc Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RHEL rpm and FIPS validation
Greetings, Apologies if this has been covered before, but I couldn't find it in a search. I'm trying to deploy FIPS 140 validated crypto to a RHEL 5 box as part of a FISMA covered project. I think the relevant policy is http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1320.pdf which states "The version of the RPM containing the validated module is version 0.9.8e-22.el5_8.3." The rpm has moved on, and the version the support person wants to use is openssl-0.9.8e-26.el5_9.1|(none) . Is there a basis for asserting FIPS 140 validation with openssl-0.9.8e-26.el5_9.1|(none), or must the original RPM be used? advTHANKSance, --woody -- Dr. Robert "Woody" GBS Cybersecurity & Weaver Privacy IT Security Architect Cell: 301-524-8138 -- Shick's Law: There is no problem a good miracle can't solve.
Re: Seeding the PRNG failed
Did a truss on the command and see some srandom error.
kioctl(5, 22528, 0x, 0x) Err#25 ENOTTY
kioctl(5, 22528, 0x, 0x) Err#25 ENOTTY
statx("/dev/srandom", 0x0FFDC3F0, 176, 0) Err#2 ENOENT
This srandom device is currently not present. Not sure if this is causing
the seeding to fail.
If this device needs to be setup, can you please point me to where I can
find some info on how to set this up.
--
View this message in context:
http://openssl.6102.n7.nabble.com/Seeding-the-PRNG-failed-tp47193p47215.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL_set_msg_callback for application_data(23)
openssl >= 0.9.8 On 06.11.2013 17:08, Patetta, Nicholas wrote: > Anyone know which version of OPENSSL is needed to support SHA256? Thanks. > > > > -Original Message- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of Raullen Chai > Sent: Tuesday, November 05, 2013 3:27 PM > To: openssl-users@openssl.org > Subject: SSL_set_msg_callback for application_data(23) > > Hi, > > I've noticed that a callback mechanism is provided to observe protocol > messages, i.e., > https://www.openssl.org/docs/ssl/SSL_CTX_set_msg_callback.html . > > However, application_data(23) cannot be monitored using this callback > function. Wondering if there is a similar callback for > application_data(23) ? > > Appreciated! > -- > -- > Best Regards > (Raullen) Qi Chai > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DH parameters distributed with OpenSSL
Hello, there are two sets of DH parameters, is there a difference? ./crypto/dh/dh2048.pem ./crypto/dh/dh512.pem ./crypto/dh/dh192.pem ./crypto/dh/dh4096.pem ./crypto/dh/dh1024.pem ./apps/dh2048.pem ./apps/dh512.pem ./apps/dh4096.pem ./apps/dh1024.pem In DH parameters in ./apps there reference to "Assigned Number for SKIP Protocols", where can be the document downloaded? Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DH parameters distributed with OpenSSL
Hello, there are two sets of DH parameters, that is the difference? ./crypto/dh/dh2048.pem ./crypto/dh/dh512.pem ./crypto/dh/dh192.pem ./crypto/dh/dh4096.pem ./crypto/dh/dh1024.pem ./apps/dh2048.pem ./apps/dh512.pem ./apps/dh4096.pem ./apps/dh1024.pem In DH parameters in ./apps there reference to "Assigned Number for SKIP Protocols" (http://www.skip-vpn.org/spec/numbers.html) . The site down, where can be the document downloaded? Thanks signature.asc Description: OpenPGP digital signature
RE: Is aesni-intel module required for openssl
>From https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/ch03s02s03.html check with root running "openssl engine -c -tt" Carl From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of sarav.sars [sarav.s...@gmail.com] Sent: 07 November 2013 05:48 To: openssl-users@openssl.org Subject: Is aesni-intel module required for openssl Is it necessary to load aesni-intel module like 'modprobe aesni-intel' ? Loading this module makes no difference in openssl speed output. openssl speed -elapsed -evp aes-128-cbc before loading aesni-intel module type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 561737.40k 598685.65k 610372.15k 610802.35k 611521.88k after loading aesni-intel module type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 563835.61k 598692.84k 608343.64k 610805.42k 611524.61k -- View this message in context: http://openssl.6102.n7.nabble.com/Is-aesni-intel-module-required-for-openssl-tp47216.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Is aesni-intel module required for openssl
The Linux kernel module isn't necessary for OpenSSL. -- Erwann ABALEA Le 07/11/2013 06:48, sarav.sars a écrit : Is it necessary to load aesni-intel module like 'modprobe aesni-intel' ? Loading this module makes no difference in openssl speed output. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Is aesni-intel module required for openssl
Is it necessary to load aesni-intel module like 'modprobe aesni-intel' ? Loading this module makes no difference in openssl speed output. openssl speed -elapsed -evp aes-128-cbc before loading aesni-intel module type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 561737.40k 598685.65k 610372.15k 610802.35k 611521.88k after loading aesni-intel module type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 563835.61k 598692.84k 608343.64k 610805.42k 611524.61k -- View this message in context: http://openssl.6102.n7.nabble.com/Is-aesni-intel-module-required-for-openssl-tp47216.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
