1.0.1 FIPS and CRYPTO_set_mem_functions
Hi, I just recognized that openssl 1.0.1 prevents setting of alloc, re-alloc and free functions if compiled with FIPS support. Can anybody give the background, why this was changed (compared to 0.9.8)? Thanks a lot Dirk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
smime tool, binary and verify
A simple echo foo | openssl smime -encrypt/sign | openssl smime -decrypt/verify works dandy. But was surprized to find that the verify breaks when '-binary' is used. Canonical example below. Would like to understand why, Thanks, Dw. #!/bin/sh # Generate a self signed cert to use for testing. # openssl req -new -x509 -out cert.pem -keyout cert.key -subj /CN=foo -nodes echo foo \ | openssl smime -sign -signer cert.pem -inkey cert.key \ | openssl smime -verify -CAfile cert.pem echo foo \ | openssl smime -binary -sign -signer cert.pem -inkey cert.key \ | openssl smime -binary -verify -CAfile cert.pem Generating a 1024 bit RSA private key ++ ..++ writing new private key to 'cert.key' - foo Verification successful foo Verification failure 140735223591388:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:1097: 140735223591388:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:410: __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES CCM encryption of large incoming pdata (file) by blocks
On Wed, Mar 06, 2013, Matej Kenda wrote: I am working on a solution which includes encryption of files of arbitrary size (at least up to 2 GB) to be encrypted with AES CCM with 256-bit key and uploaded to a server. CCM isn't really the mode to use for that, GCM is better. There are two reasons. One is that you need to know the length of the AAD and plaintext in advance before you can process any data: this makes it unusable for things like streaming for CMS. The second reason is that the stanard (RFC 3610) has this requirement (T is the tag): If the T value is not correct, the receiver MUST NOT reveal any information except for the fact that T is incorrect. The receiver MUST NOT reveal the decrypted message, the value T, or any other information. You can only check the tag if you've processed all the ciphertext so if you were handling it in parts you'd have to either buffer everything or perform two passes. The only way round this is to violate the standard and reveal some of the plaintext on the fly. 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 throughput
Does anyone have an idea what kind of AES throughput is achievable on a Cortex A9 700MHz core? Is 20Mbps within reach, say with AES 256 CBC mode? Thanks, Weijun.
Re: Are Openssl Random Number Generator NIST compliant ?
On 6 March 2013 03:55, Nayna Jain naynj...@in.ibm.com wrote: Hi all, Are RAND_seed(), RAND_add() NIST SP 800-151A compliant ? 800-151 does not appear to exist, got a link? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: APIs forbidden in FIPS mode
On Wed, Mar 06, 2013, Rahul Godbole wrote: I get this error with FIPS mode set Low level API call to digest SHA1 forbidden in FIPS mode I have a bunch of OpenSSL APIs being called. Can someone tell me what APIs are classified as low level APIs that are forbidden in FIPS mode? You have to use EVP in FIPS mode. 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
Re: APIs forbidden in FIPS mode
So any of the API s like AES_cbc_encrypt, SHA1, PKCS5_PBKDF2_HMAC_SHA1, RSA_private_decrypt etc will not work in FIPS mode? I am using many low level API s like these in our crypto module. Now if I change my libcrypto to FIPS capable libcrypto, do I have to change al these API s to EVP? Tarani On Wed, Mar 6, 2013 at 8:48 AM, Dr. Stephen Henson st...@openssl.orgwrote: On Wed, Mar 06, 2013, Rahul Godbole wrote: I get this error with FIPS mode set Low level API call to digest SHA1 forbidden in FIPS mode I have a bunch of OpenSSL APIs being called. Can someone tell me what APIs are classified as low level APIs that are forbidden in FIPS mode? You have to use EVP in FIPS mode. 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
Re: APIs forbidden in FIPS mode
On Wed, Mar 06, 2013, Taraniteja Vishwanatha wrote: So any of the API s like AES_cbc_encrypt, SHA1, PKCS5_PBKDF2_HMAC_SHA1, RSA_private_decrypt etc will not work in FIPS mode? I am using many low level API s like these in our crypto module. Now if I change my libcrypto to FIPS capable libcrypto, do I have to change al these API s to EVP? Should've been a bit clearer. You have to use EVP for ciphers and digests, so AES_*, SHA1_* and SHA2* etc calls will fail. RSA_private_decrypt is fine and PKCS5_PBKDF2_HMAC_SHA1 uses EVP internally so that is OK too. 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
Re: AES CCM encryption of large incoming pdata (file) by blocks
Dear Steve, Dne sreda, 06. marec 2013 12:40:50 UTC+1 je oseba Dr. Stephen Henson napisala: On Wed, Mar 06, 2013, Matej Kenda wrote: I am working on a solution which includes encryption of files of arbitrary size (at least up to 2 GB) to be encrypted with AES CCM with 256-bit key and uploaded to a server. CCM isn't really the mode to use for that, GCM is better. There are two reasons. One is that you need to know the length of the AAD and plaintext in advance before you can process any data: this makes it unusable for things like streaming for CMS. Thank you for the advice. Unfortunately I am currently not in the position to select AES mode, but I will forward your observations to designers of the cryptographic concept. You can only check the tag if you've processed all the ciphertext so if you were handling it in parts you'd have to either buffer everything or perform two passes. My first attempt was to load complete file in memory and encrypt it in one call to EVP_EncryptUpdate. It worked fine for files smaller that 16 MB, however output buffer was not filled with encrypted data for larger input buffers. EVP_EncryptUpdate returned success (OpenSSL 1.0.1c) This failed attempt made me think of different solutions. Authenticity of the uploaded encrypted file is verified on the server as well, because tag size and the size of the file is known. The only way round this is to violate the standard and reveal some of the plaintext on the fly. Why would plaintext need to be revealed? Regards, Matej
Re: Saving the SessionID/Ticket and rebooting. What is needed?
On Wed, Mar 06, 2013 at 08:37:06PM +0100, Peter Sand wrote: I currently can save the SSL_SESSION in RAM and reuse it as SSL Session ID when reconnecting. The idea is to save it in Flash and reuse after power on again. I've looked at saving the Session like it is done in s_client -sess_out arg / -sess_in arg but a lot of functions to serialize SSL_SESSION ssl.h : PEM_read_bio_SSL_SESSION() ssl.h : PEM_write_bio_SSL_SESSION() are unfortuneately stubbed way below. And I have no filesystem... All you need is i2d_SSL_SESSION and d2i_SSL_SESSION, so no PEM routines required. Just store the result of i2d in RAM and after reboot run d2i and re-use the resulting session. The session object stores the peer certificate so be prepared for up to 16K of data (though in practice 1K is closer). This said, what's wrong with not saving the session across reboot? Just negotiate a new one. Saving session keys in non-volatile memory poses a greater risk of compromise. 1. Am I correct to observe that I have to save the whole SSL_SESSION to be able to use the SSL Session ID? Yes. 2. Is my assumption correct: Would it be enough to save the TLS Ticket IDs length data? IIRC you don't need to explicitly manage session tickets they're part of the serialized session. 4. Any way to avoid saving the whole SSL_SESSION? Save the whole session. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Saving the SessionID/Ticket and rebooting. What is needed?
Have you looked at http://www.matrixssl.org/ ? On 07/03/13 08:37, Peter Sand wrote: Hello, My current solution is a cut down version of OpenSSL adapted for an embedded solution. So there is no filesystem etc. A lot of underlying functions are stubbed. I currently can save the SSL_SESSION in RAM and reuse it as SSL Session ID when reconnecting. The idea is to save it in Flash and reuse after power on again. I've looked at saving the Session like it is done in s_client -sess_out arg / -sess_in arg but a lot of functions to serialize SSL_SESSION ssl.h : PEM_read_bio_SSL_SESSION() ssl.h : PEM_write_bio_SSL_SESSION() are unfortuneately stubbed way below. And I have no filesystem... I have started looking at options. Questions 1. Am I correct to observe that I have to save the whole SSL_SESSION to be able to use the SSL Session ID? 2. Is my assumption correct: Would it be enough to save the TLS Ticket IDs length data? 3. I tried to just save the TLS Ticket ID but I cannot get it to work. a. SSL_CTX_get_tlsext_ticket_keys() - FLASH b. REBOOT c. Init stuff d. FLASH - SSL_CTX_set_tlsext_ticket_keys() e. Connect (does not work) Can somebody please verify that this should work or not? 4. Any way to avoid saving the whole SSL_SESSION? 5. Any other way to do it? :) Thanks in advance! Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES throughput
Build openssl on your platform and do openssl speed aes to get the result. Regards, Huang Le (Eric, Alibaba DevOps) On Mar 6, 2013 8:16 PM, Weijun Zhu wei...@silvustechnologies.com wrote: Does anyone have an idea what kind of AES throughput is achievable on a Cortex A9 700MHz core? Is 20Mbps within reach, say with AES 256 CBC mode? Thanks, Weijun.
where does one file a bug report ?
Is there a bugzilla site or similar for openssl ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: where does one file a bug report ?
See the README for instructions, under the SUPPORT section: http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=README;hb=refs/heads/master Matt On 6 March 2013 23:10, Dennis Clarke dcla...@blastwave.org wrote: Is there a bugzilla site or similar for openssl ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS support with shared libraries on FreeBSD 9.1
I am having issues with FIPS_mode() in a shared library on FreeBSD 9.1.
I have read and reread the OpenSSL FIPS User Guide. It am sure I am
following the steps correctly. If I link static with 'fipsld', FIPS_mode()
works correctly. As a sanity check, I tried the same openssl with fips build
process on both NetBSD 6.0.1 and Ubunto 12.10. NetBSD failed and Ubunto
worked. Has anyone been able to get FIPS mode to work with shared openssl
libraries on any of the BSDs?
My test is:
1) install openssl-fips-2.0.2 to ~/src
a) Download openssl-fips-2.0.2.tar.gz
b) cd ~/src
c) tar -xfz openssl-fips-2.0.2.tar.gz
d) cd openssl-fips-2.0.2
e) ./config
f) make
g) sudo make install
2) Install openssl-1.0.1e
a) Download openssl-1.0.1e.tar.gz
b) cd ~/src
c) tar -xfz openssl-1.0.1e.tar.gz
d) cd openssl-1.0.1e
e) ./config fips shared
f) make depend
g) make
3) Build test program using shared libraries (attached)
a) cd src/fips
b) cc -I../openssl-1.0.1e/include fips.c -L../openssl-1.0.1e -lcrypto
-o fips
c) export LD_LIBRARY_PATH=../openssl-1.0.1e
d) ./fips
Enabling FIPS MODE: failed
Perhaps openssl not built with fips support?
34376208808:error:2D06B06F:FIPS
routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232:
4) Build test program using static libraries
a) cd src/fips
b) PATH=/usr/local/ssl/fips-2.0/bin:$PATH
c) export FIPSLD_CC=cc
d) fipsld -I../openssl-1.0.1e/include fips.c -L../openssl-1.0.1e
-lcrypto -o fips -static
e) ./fips
Enabling FIPS MODE: successful
In case attachment gets stripped, fips.c src is:
#include stdio.h
#include string.h
#include openssl/err.h
#include openssl/crypto.h
int main(int argc, char *argv[])
{
//Setting up FIPS MODE:
if ( FIPS_mode() ) {
printf(FIPS MODE is already enabled\n);
} else {
printf(Enabling FIPS MODE: );
if( FIPS_mode_set( 2 ) ) {
printf(successful\n);
} else {
printf(failed\n);
printf(\nPerhaps openssl not built with fips support?\n\n);
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
exit( 1 );
}
}
exit( 0 );
}
--
Larry Baird
Global Technology Associates, Inc. 1992-2012| http://www.gta.com
Celebrating Twenty Years of Software Innovation | Orlando, FL
Email: l...@gta.com | TEL 407-380-0220
#include stdio.h
#include string.h
#include openssl/err.h
#include openssl/crypto.h
int main(int argc, char *argv[])
{
//Setting up FIPS MODE:
if ( FIPS_mode() ) {
printf(FIPS MODE is already enabled\n);
} else {
printf(Enabling FIPS MODE: );
if( FIPS_mode_set( 2 ) ) {
printf(successful\n);
} else {
printf(failed\n);
printf(\nPerhaps openssl not built with fips support?\n\n);
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
exit( 1 );
}
}
exit( 0 );
}
Re: APIs forbidden in FIPS mode
Is there any fips flag that I can set while compiling OpenSSL 1.0.1.c so that any usage of low level APIs will result in a compilation error? On Wed, Mar 6, 2013 at 8:47 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Wed, Mar 06, 2013, Taraniteja Vishwanatha wrote: So any of the API s like AES_cbc_encrypt, SHA1, PKCS5_PBKDF2_HMAC_SHA1, RSA_private_decrypt etc will not work in FIPS mode? I am using many low level API s like these in our crypto module. Now if I change my libcrypto to FIPS capable libcrypto, do I have to change al these API s to EVP? Should've been a bit clearer. You have to use EVP for ciphers and digests, so AES_*, SHA1_* and SHA2* etc calls will fail. RSA_private_decrypt is fine and PKCS5_PBKDF2_HMAC_SHA1 uses EVP internally so that is OK too. 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
