Re: MD5 in openSSL internals
-Original Message- From: Venkataragavan Narayanaswamy v...@brocade.com Sender: owner-openssl-us...@openssl.org Date: Tue, 23 Apr 2013 00:29:17 To: openssl-...@openssl.orgopenssl-...@openssl.org; openssl-users@openssl.orgopenssl-users@openssl.org Reply-To: openssl-users@openssl.org Subject: MD5 in openSSL internals Hi, We are currently analyzing and understanding the security strength of the openSSL internal implementation to certify the products. In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer the following or provide me with the documentation reference 1. Does openSSL library use MD5 internally for any operation? 2. Can we have SHA256 in the ciphersuite with TLSv1.0? Thanks, Venkat
Re: MD5 in openSSL internals
On Wed, Apr 24, 2013 at 03:18:45PM +, Nikola Vassilev wrote: We are currently analyzing and understanding the security strength of the openSSL internal implementation to certify the products. In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer the following or provide me with the documentation reference 1. Does openSSL library use MD5 internally for any operation? 2. Can we have SHA256 in the ciphersuite with TLSv1.0? You're not qualified to perform this analysis. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
handling of expired certificates
Hi I am new to openssl application development. I had a question on how to handle expired certificates. So at the time of openssl connection establishment, the certificate is valid. But while the connection is still up, the certificate expires. Is the application supposed to handle this or does openssl handle this? what should be the application behavior on certificate expiry? Thanks, Vijaya
OpenSSL 0.9.8k upgrade
Hello Folks ! I have a question that I hope you can help me with. A server with OpenSSL 0.9.8k installed can be upgraded to OpenSSL 1.0.x without break any dependencies? I mean compile from the source and install the new version. Regards Sincerely Víctor Martínez. This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. *** Walmart Confidential ***
Re: FIPS_rand_set_key and FIPS_rand_seed
I found the solution, it has nothing to do with forking. Here is what i did- I was writing IN FIPS MODE message to *stdout*. When sshd forks child process to handle scp, this stdout was being passed over the pipe causing the issue. My issue got resolved after writing the FIPS mode message to *stderr*. Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-rand-set-key-and-FIPS-rand-seed-tp44828p44863.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 internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode
Hi, I complied and installed FIPS capable OPENSSL 1.0.1c and OPENSSH 6.1p1 with FIPS. While debugging i found that SSH fails for *ctr* mode of cipher operation. Here is what i get when i connect using aes256-ctr or aes128-cbc FIPS mode initialized debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 51395 debug1: Client protocol version 2.0; client software version OpenSSH_5.5p1 Debian-6+squeeze1 debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: permanently_set_uid: 101/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client-server aes256-ctr hmac-sha1 none [preauth] debug1: kex: server-client aes256-ctr hmac-sha1 none [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] aes_misc.c(73): OpenSSL internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode! debug1: do_cleanup This issue doesnt happen with aes128-cbc . What is wrong here? aes_misc(73) : #ifdef OPENSSL_FIPS fips_cipher_abort(AES); #endif How does it differentiate between different modes? Thanks, Cipher -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-internal-error-assertion-failed-Low-level-API-call-to-cipher-AES-forbidden-in-FIPS-mode-tp44864.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: AES key wrap feature unavailable in FIPS mode OpenSSL?
Hi, given the point this was posted in 2011, i hope this is resolved and i can get some help with my problem! I have a similar problem with openssl 1.0.1c compiled with FIPS 2.0.2 and OPENSSH 6.1p1. Here is the debug mode of sshd with aes256-ctr cipher FIPS mode initialized debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 51395 debug1: Client protocol version 2.0; client software version OpenSSH_5.5p1 Debian-6+squeeze1 debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: permanently_set_uid: 101/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client-server aes256-ctr hmac-sha1 none [preauth] debug1: kex: server-client aes256-ctr hmac-sha1 none [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] aes_misc.c(73): OpenSSL internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode! debug1: do_cleanup Any help is highly appreciated. Also i read in some threads that i have to use EVPs. How to use them? Is there a related patch? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/AES-key-wrap-feature-unavailable-in-FIPS-mode-OpenSSL-tp18237p44865.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: handling of expired certificates
OpenSSL does nothing about this. It's an interesting question. As for as TLS/SSL is concerned, it is only using the certificate at the time the connection is initially established, and therefore expiration (or revocation) during the application's use of the certificate is up to the application. The only practical use that I can imagine is using something in the cert (DN or an extension) for authorization decisions... /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: handling of expired certificates
On Tue, Apr 23, 2013 at 10:17:54AM -0700, Vijaya Venkatachalam wrote: So at the time of openssl connection establishment, the certificate is valid. But while the connection is still up, the certificate expires. The certificate was valid at the time it was verified, this is sufficient. Is the application supposed to handle this or does openssl handle this? Nothing needs to be done, so openssl does nothing. what should be the application behavior on certificate expiry? It should keep going. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] handling of expired certificates
OpenSSL doesn't take care of the expiration of your certificate automagically in the background and call some function in your application to asynchronously tell that the certificate you received several seconds ago has now expired. Identically, OpenSSL doesn't take care of external events that may now declare your certificate as revoked. Verify the validity of the certificate at the current time. If you want to periodically check for the validity of the certificate because you're using it for a looong session, that's up to you. -- Erwann ABALEA Le 23/04/2013 19:17, Vijaya Venkatachalam a écrit : Hi I am new to openssl application development. I had a question on how to handle expired certificates. So at the time of openssl connection establishment, the certificate is valid. But while the connection is still up, the certificate expires. Is the application supposed to handle this or does openssl handle this? what should be the application behavior on certificate expiry? Thanks, Vijaya
RE: handling of expired certificates
From: Salz, Rich OpenSSL does nothing about this. It’s an interesting question. As for as TLS/SSL is concerned, it is only using the certificate at the time the connection is initially established, and therefore expiration (or revocation) during the application’s use of the certificate is up to the application. The only practical use that I can imagine is using something in the cert (DN or an extension) for authorization decisions… If the application has the need to re-verify the certificate on SSL level, it can renegotiate the connection's SSL parameters. Alternatively, it can close down the current connection and establish a new one. Both ways cause a new handshake to be started. HTH, Patrick Eisenacher
Re: OpenSSL internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode
On Wed, Apr 24, 2013, Cipher wrote: Hi, I complied and installed FIPS capable OPENSSL 1.0.1c and OPENSSH 6.1p1 with FIPS. While debugging i found that SSH fails for *ctr* mode of cipher operation. Here is what i get when i connect using aes256-ctr or aes128-cbc FIPS mode initialized debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 51395 debug1: Client protocol version 2.0; client software version OpenSSH_5.5p1 Debian-6+squeeze1 debug1: match: OpenSSH_5.5p1 Debian-6+squeeze1 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: permanently_set_uid: 101/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client-server aes256-ctr hmac-sha1 none [preauth] debug1: kex: server-client aes256-ctr hmac-sha1 none [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] aes_misc.c(73): OpenSSL internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode! debug1: do_cleanup This issue doesnt happen with aes128-cbc . What is wrong here? aes_misc(73) : #ifdef OPENSSL_FIPS fips_cipher_abort(AES); #endif I've seen this before and it was caused by the code manually implementing ctr mode instead of using EVP. If you change it to use the corresponding EVP ciphers for CTR mode it should work. Specifically the three entries for evp_aes_128_ctr should be changed to EVP_aes_128_ctr, EVP_aes_192_ctr and EVP_aes_256_ctr respectively. 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
AES-XTS mode doesn't chain between successive calls to EVP_CipherUpdate?
Looking at the xts128.c code, it looks like the tweak is recalculated from scratch every time CRYPTO_xts128_encrypt() is called: memcpy(tweak.c, iv, 16); (*ctx-block2)(tweak.c,tweak.c,ctx-key2); It seems like this would break the chaining between successive calls to EVP_CipherUpdate, requiring that the plaintext be encrypted in its entirety with one call to EVP_CipherUpdate. Other chaining modes preserve the chaining state in the context (CTR mode, for example, saves the num). There's nothing in the XTS context structure that would preserve the tweak, though. Am I missing where this chaining occurs? Or is this a bug? Or is it a requirement that XTS mode only use a single call to EVP_CipherUpdate per data stream? (which seems to violate the definition of EVP_CipherUpdate.) I saw this in openssl-1.0.1, but I've checked that the relevant code in openssl-1.0.1e is no different. Thanks, Greg Bryant Technical Leader Cisco Systems, Inc.
Data and Signature (envelope)
I have a piece of data like a JPG and a MD from it and a signature PKCS#1 from the MD. int rc= RSA_sign(NID_sha1, md, 20, sigret, siglen, rsapriv) I send the data and the signature to someone to verify the data and they use it. Now maybe there is standard measure to package the data and the signature and that would be? x.509 (that does not make sense or does it) pkcs12 (maybe) so what would it be? Of course I have to figure out how to extract the info out of the new envelope; any suggestions? -- View this message in context: http://openssl.6102.n7.nabble.com/Data-and-Signature-envelope-tp44885.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: MD5 in openSSL internals
On Wed, Apr 24, 2013 at 03:18:45PM +, Nikola Vassilev wrote: We are currently analyzing and understanding the security strength of the openSSL internal implementation to certify the products. In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer the following or provide me with the documentation reference 1. Does openSSL library use MD5 internally for any operation? 2. Can we have SHA256 in the ciphersuite with TLSv1.0? You're not qualified to perform this analysis. OpenSSL is not open to such analysis if a documentation reference cannot be given. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: MD5 in openSSL internals
On Wed, Apr 24, 2013 at 01:55:36PM -0700, d...@deadhat.com wrote: On Wed, Apr 24, 2013 at 03:18:45PM +, Nikola Vassilev wrote: We are currently analyzing and understanding the security strength of the openSSL internal implementation to certify the products. In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer the following or provide me with the documentation reference 1. Does openSSL library use MD5 internally for any operation? 2. Can we have SHA256 in the ciphersuite with TLSv1.0? You're not qualified to perform this analysis. OpenSSL is not open to such analysis if a documentation reference cannot be given. Neither question requires any OpenSSL documentation, OpenSSL 0.9.8d implements SSLv2, SSLv3 and TLSv1.0. Anyone competent to assess the implementation knows the answers to these questions without looking at OpenSSL. The converse is not generally true: I know the answers to the questions, but I am also not competent to assess the strength of the cryptography in OpenSSL relative to other implementations of the same algorithms and protocol standards. That takes additional expertise, which the OP clearly lacks. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Data and Signature (envelope)
2013/4/24 redpath redp...@us.ibm.com I have a piece of data like a JPG and a MD from it and a signature PKCS#1 from the MD. int rc= RSA_sign(NID_sha1, md, 20, sigret, siglen, rsapriv) I send the data and the signature to someone to verify the data and they use it. Now maybe there is standard measure to package the data and the signature and that would be? x.509 (that does not make sense or does it) pkcs12 (maybe) so what would it be? Of course I have to figure out how to extract the info out of the new envelope; any suggestions? Have a look at CMS: http://www.ietf.org/rfc/rfc5652.txt https://en.wikipedia.org/wiki/Cryptographic_Message_Syntax https://www.openssl.org/docs/apps/openssl.html HTH, Kris -- View this message in context: http://openssl.6102.n7.nabble.com/Data-and-Signature-envelope-tp44885.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: Data and Signature (envelope)
I saw the CMS but I did not see how to store raw data which I need to extract? Lets assume the data was a JPG and I created signature from the MD (SHA1) how can I get the JPG use it and validate it. I looked at the PKCS7 and no mention of adding objects. Any example is best to learn assuming data (JPG) derived MD from it for a signature and I have a private key. I am assuming RSA though I would like to do ECDSA. -- View this message in context: http://openssl.6102.n7.nabble.com/Data-and-Signature-envelope-tp44885p44889.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
base + delta CRL
Hi, Can I do CRL checking by adding both the base and delta CRLs with X509_STORE_add_crl() or should I construct a complete CRL with the base and delta CRLs and then add it to the store? Thanks, -binlu
SANs for self signed certs
Hello, I have some code which I am using to generate a CSR and some code which I am using to generate a cert using my cert authority. If I view the CSR, I can see that my alt names were added correctly. If I view the cert itself, the altnames are not there. I had kind of thought that if I had a CSR with the alt names in it, the cert would get them too. Is that not correct? I am using the same CONF variable for both the CSR and the cert, but I am adding the extensions for subject alt name programmatically to the CSR (but not to the cert). I am doing this in a similar way as the mkreq.c demo by pushing my extension objects onto a stack and adding them before the X509_REQ_sign call. Do I need it in both places, or maybe just on the cert creation part and nto the CSR? Alternatively, is there a way to add subject alt names programmatically to the config as an X509_EXTENSION object? Then I could perhaps just rely on the configuration to set the alt names instead of trying to force the X509_EXTENSION into the cert. Thanks for any help
RE: MD5 in openSSL internals
First poster: We are currently analyzing and understanding the security strength of the openSSL internal implementation to certify the products. In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer the following or provide me with the documentation reference 1. Does openSSL library use MD5 internally for any operation? 2. Can we have SHA256 in the ciphersuite with TLSv1.0? Well-known respondent: You're not qualified to perform this analysis. Second respondent: OpenSSL is not open to such analysis if a documentation reference cannot be given. Me: Actually, the first poster did not describe what kind of certification is being done, and therefore we have no idea whether or not such documentation is required. We do have one proof point, the FIPS certification, that shows this documentation is not required. On the basis of that, and the fact that this is free open source software, it is not unreasonable for experienced folks to say we gave you the source, everything else is up to you. Taken by themselves, the questions are too vague to really answer. Is using MD5 as part of the connection setup internally? I would interpret question 1 to mean things like power-on selftest, etc, but it's not clear. As for the second question, I can't even understand it: do they want to know if SHA256 is in the protocol, the OpenSSL library, the OpenSSL implementation of the protocol, enabled or disabled by default, or what? My guess is that English is not the native language, and I would have been more lenient with the first poster, but based on what was written, the first respondent seems accurate to me. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Data and Signature (envelope)
From: owner-openssl-us...@openssl.org On Behalf Of redpath Sent: Wednesday, 24 April, 2013 18:10 I saw the CMS but I did not see how to store raw data which I need to extract? Lets assume the data was a JPG and I created signature from the MD (SHA1) how can I get the JPG use it and validate it. I looked at the PKCS7 and no mention of adding objects. The PKCS7_* API, and the newer and more complete CMS_* API, is designed to do most of the work for you. PKCS7_sign or CMS_sign takes the data as a BIO to allow streaming from a (large) file or pipe or such, but if you have your data in memory just use a mem-BIO; computes a signature* using a given privatekey and cert(s); and produces the result structure, or if streaming sets-up to produce it. * By default these APIs do the two level signature: hash the data, put that hash into AuthenticatedAttributes along with other stuff, hash AuthenticatedAttributes and pk-sign that hash. You can specify _NOATTR to reduce this to just hash the data and pk-sign that (first) hash. I hope you didn't mean the *commandline* utility pkcs7. Despite the name, that handles only p7b objects, i.e. degenerate PKCS7 containing no actual data or signature used only to transport cert(s) or (less often) CRL(s). To do proper-pkcs7 signed or encrypted at commandline, use smime or cms with format PEM or DER. Any example is best to learn assuming data (JPG) derived MD from it for a signature and I have a private key. If you really want to do it yourself, the older PKCS7_ module exposes the C structs, which you could fill in and then I think plain (nonstream) i2d_ or PEM_write_ should work, although I haven't tested. I am assuming RSA though I would like to do ECDSA. These APIs will use any privatekey for which a signature scheme is available; that's RSA DSA ECDSA (or pedantically EC; openssl uses the same EC_KEY struct for ECDSA and ECDH). (In general openssl routines using EVP_PKEY will handle many key types, that's exactly what the EVP level is for.) I still encounter a few reliers (or other systems) now and then who don't support ECDSA, though less than a few years ago. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Data and Signature (envelope)
On Wed, Apr 24, 2013 at 10:35:04PM -0400, Dave Thompson wrote: I am assuming RSA though I would like to do ECDSA. These APIs will use any privatekey for which a signature scheme is available; that's RSA DSA ECDSA (or pedantically EC; openssl uses the same EC_KEY struct for ECDSA and ECDH). (In general openssl routines using EVP_PKEY will handle many key types, that's exactly what the EVP level is for.) For some time CMS did not support ECDSA (recipient public keys), only RSA was supported. Has that changed recently? One needs to recipient public keys to encrypt the message key to each recipient, which is different from the sender key used for signing. There was no code for that last time I looked, is there a suitable standard for using ECDSA with CMS recipients? I just tried with 1.0.1e and could only encrypt to an RSA recipient. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
