Re: [openssl-users] NID_Name equivalent in a certificate
Bonjour, NID_name correspond to the OID id-at-name. There's no equivalent field in a certificate that maps to an OID. The OID id-at-name designs the attribute supertype name, which shouldn't be present in a certificate, but can nevertheless be present. Anywhere. -- Erwann ABALEA Le 29/04/2015 07:19, Mailer Mailer a écrit : Hi, Can some one let me know what is the equivalent field in a certifcate that maps to NID_Name? Thank you, Tom ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Is it possible to add a Client Hostname to an SSL Client Certificate?
Hello, I recently implemented a secured communication between two sites in which one acts as the server and the other as the client. To accomplish this, I used openssl to generate self-signed CA, Server and Client certificates (the calls are made using cURL). It all works beautifully and, testing my proof-of-concept has shown that if one of the pieces is missing from the equation (CA, Server, Client certificates), the communication ceases. But once I showed my work to people in my company, one of them asked me why did I choose not to add the client hostname to the Client Certificate, thus making it usable only by that specific client. And so I started searching online for ways to do it, but found nothing. I also looked into the openssl site and documentation and found nothing there either. The truth is that I don't even know if this is possible or even if this is the right question to ask. But can it be done? And if so, could you show me how, or where should I go to get more information on how to accomplish this? If you need more information on how I setup this communication, please let me know and I will be glad to share it here. Thanks,Alex ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is it possible to add a Client Hostname to an SSL Client Certificate?
But once I showed my work to people in my company, one of them asked me why did I choose not to add the client hostname to the Client Certificate, thus making it usable only by that specific client. You put to put the client name or ipaddr in the subjectAltName extension field. Then you'd have to put code on your server to verify that. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Performance problems with OpenSSL and threading
Can I safely assume that if I call FIPS_mode_set(0) and get a successful return
value then I don’t need to lock when there are callbacks for type 39 and 40
locks (for OpenSSL 1.0.1 and 1.0.2)?
-Bryan
On Apr 28, 2015, at 10:22 AM, John Foley fol...@cisco.com wrote:
In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1) has
returned with a successful return value.
In the future, this may change if/when OpenSSL does another FIPS validation.
CMVP has changed the implementation guidance that requires the POST to run
automatically without user intervention. Any future FIPS validations would
be subject to the new rules. Hence, the behavior of FIPS_mode_set() may
change in the future if OpenSSL decides to pursue another validation.
On 04/28/2015 12:43 PM, Bryan Call wrote:
What do you mean by “FIPS POST has completed”?
-Bryan
On Apr 24, 2015, at 4:17 PM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
Some of the algorithms still invoke the FIPS flavor of the algorithm even
when FIPS is disabled. For example, this code is from EVP_DigestUpdate().
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
return ctx-update(ctx, data, count);
#endif
}
In 1.0.1, locks 39 and 40 are:
# define CRYPTO_LOCK_FIPS39
# define CRYPTO_LOCK_FIPS2 40
You should try adding some logic to skip the lock in your lock handler when
the lock ID is 39 or 40. Again, it should be safe to not lock on these two
as long as the FIPS POST has completed.
On 04/24/2015 05:56 PM, Bryan Call wrote:
In my last email I ran the benchmark on Fedora 21 (big mistake). Here
are the results when running it back on the 28/56 core RHEL 6.5 server
showing contention in a different place (fips). Is there a reason it
would be calling into the FIPS code to get a lock of FIPS is not enabled?
Contention log:
[Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for lock -
total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40
[Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for lock -
total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39
Line in in fips that see the contention the most:
[bcall@bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' |
sort | uniq -c | sort -rn
875379 471
288338 107
275472 127
Different lock types and their contention frequency (multiple benchmarks):
875379 40 - in fips.c
563810 39 - also in fips.c
440518 1
44145 18
17447 2
11356 10
1377 19
687 12
532 25
302 33
239 9
58 16
40 21
32 11
19 3
1 14
Code to diable FIPS and log:
#ifdef OPENSSL_FIPS
int mode = FIPS_mode();
Debug(ssl, FIPS_mode: %d, mode);
mode = FIPS_mode();
if (mode) {
FIPS_mode_set(0);
Debug(ssl, FIPS_mode: %d, mode);
}
#endif
[Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0
-Bryan
On Apr 24, 2015, at 10:56 AM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
When you create the private key given to SSL_CTX, be sure to instantiate
a private key for each thread as well. If you share the same key across
all threads, this can introduce contention.
Here are the type 1 2 locks:
# define CRYPTO_LOCK_ERR 1
# define CRYPTO_LOCK_EX_DATA 2
Have you checked the OpenSSL error log to see what errors are being
generated?
Also, if you disable FIPS, does the thread contention still occur?
On 04/24/2015 01:36 PM, Bryan Call wrote:
We are using a single SSL_CTX across all the threads, so I will create
multiple SSL_CTX per thread. I implemented dynlock callbacks yesterday,
but I didn’t see them being used in the tests I did. I also added
atomic counters to see what type of locks are having contention (see
logs below):
Most of the lock contention seems to be around type 2 and type 1 locks
when calling our lock callback. In the FIPS/POST and SSL_CTX
recommendations, in your previous email, what types of locks would those
help with?
Log output:
[Apr 24 10:21:24.339] Server {0xb31} ERROR: SSLUtils.cc
http://sslutils.cc/:178 (SSL_locking_callback) contention for lock -
total contention: 3938 waiting: 1 file:
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line:
496 type: 2
[Apr 24 10:21:24.754] Server {0xb10a000} ERROR: SSLUtils.cc
http://sslutils.cc/:178 (SSL_locking_callback) contention for lock -
total contention: 1350 waiting: 1 file:
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c
line: 343 type: 1
-Bryan
On Apr 23, 2015, at 4:46 PM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
Looking at your call stack, it appears you're
Re: [openssl-users] Performance problems with OpenSSL and threading
Correct. Locks 39/40 are only useful while the POST is running. Once
the POST completes, the POST status never changes again unless the POST
runs again. The only way to run the POST is by invoking
FIPS_mode_set(1). But there should be no reason to invoke
FIPS_mode_set(1) more than once unless you want to provide some sort of
run-time FIPS mode toggle capability.
You're asking in the context of Apache, right? Apache just has a global
FIPS on/off knob in the config. If set, FIPS is enabled for the
lifetime of the process and never disabled/re-enabled. You would invoke
FIPS_mode_set(1) once prior to spinning up the worker threads.
Therefore, the POST would be finished prior to any multi-threaded
processing.
On 04/29/2015 01:53 PM, Bryan Call wrote:
Can I safely assume that if I call FIPS_mode_set(0) and get a
successful return value then I don’t need to lock when there are
callbacks for type 39 and 40 locks (for OpenSSL 1.0.1 and 1.0.2)?
-Bryan
On Apr 28, 2015, at 10:22 AM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1)
has returned with a successful return value.
In the future, this may change if/when OpenSSL does another FIPS
validation. CMVP has changed the implementation guidance that
requires the POST to run automatically without user intervention.
Any future FIPS validations would be subject to the new rules.
Hence, the behavior of FIPS_mode_set() may change in the future if
OpenSSL decides to pursue another validation.
On 04/28/2015 12:43 PM, Bryan Call wrote:
What do you mean by “FIPS POST has completed”?
-Bryan
On Apr 24, 2015, at 4:17 PM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
Some of the algorithms still invoke the FIPS flavor of the
algorithm even when FIPS is disabled. For example, this code is
from EVP_DigestUpdate().
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
return ctx-update(ctx, data, count);
#endif
}
In 1.0.1, locks 39 and 40 are:
# define CRYPTO_LOCK_FIPS39
# define CRYPTO_LOCK_FIPS2 40
You should try adding some logic to skip the lock in your lock
handler when the lock ID is 39 or 40. Again, it should be safe to
not lock on these two as long as the FIPS POST has completed.
On 04/24/2015 05:56 PM, Bryan Call wrote:
In my last email I ran the benchmark on Fedora 21 (big mistake).
Here are the results when running it back on the 28/56 core RHEL
6.5 server showing contention in a different place (fips). Is
there a reason it would be calling into the FIPS code to get a
lock of FIPS is not enabled?
Contention log:
[Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention
for lock - total contention: 70662 waiting: 16 file: fips.c line:
471 type: 40
[Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention
for lock - total contention: 71605 waiting: 2 file: fips.c line:
107 type: 39
Line in in fips that see the contention the most:
[bcall@bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d '
' | sort | uniq -c | sort -rn
875379 471
288338 107
275472 127
Different lock types and their contention frequency (multiple
benchmarks):
875379 40 - in fips.c
563810 39 - also in fips.c
440518 1
44145 18
17447 2
11356 10
1377 19
687 12
532 25
302 33
239 9
58 16
40 21
32 11
19 3
1 14
Code to diable FIPS and log:
#ifdef OPENSSL_FIPS
int mode = FIPS_mode();
Debug(ssl, FIPS_mode: %d, mode);
mode = FIPS_mode();
if (mode) {
FIPS_mode_set(0);
Debug(ssl, FIPS_mode: %d, mode);
}
#endif
[Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl)
FIPS_mode: 0
-Bryan
On Apr 24, 2015, at 10:56 AM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
When you create the private key given to SSL_CTX, be sure to
instantiate a private key for each thread as well. If you share
the same key across all threads, this can introduce contention.
Here are the type 1 2 locks:
# define CRYPTO_LOCK_ERR 1
# define CRYPTO_LOCK_EX_DATA 2
Have you checked the OpenSSL error log to see what errors are
being generated?
Also, if you disable FIPS, does the thread contention still occur?
On 04/24/2015 01:36 PM, Bryan Call wrote:
We are using a single SSL_CTX across all the threads, so I will
create multiple SSL_CTX per thread. I implemented dynlock
callbacks yesterday, but I didn’t see them being used in the
tests I did. I also added atomic counters to see what type of
locks are having contention (see logs below):
Most of the lock contention seems to be around type 2 and type 1
locks when calling our lock callback. In the FIPS/POST and
SSL_CTX recommendations, in your previous email, what types
Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding?
Excellent, this is exactly the kind of information I was looking for. Thanks very much Viktor for your help Graeme -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, April 29, 2015 1:34 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? On Wed, Apr 29, 2015 at 03:42:40PM +, Perrow, Graeme wrote: Apologies for the top-post; Outlook makes it hard to do anything else. Here is a small C++ reproducible. I am generating a key pair, encrypting a small string using OAEP and decrypting using PKCS1 and expecting the decryption to fail. If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually fail because RSA_private_decrypt doesn't fail. I can run it hundreds of times successfully before it fails. I have also seen it fail on Windows 7. Originally, you said the decryption used RSA_NO_PADDING, the code below decrypts with RSA_PKCS1_PADDING. int output_pad = RSA_PKCS1_PADDING; memset( decrypted, 0, sizeof(decrypted) ); size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted, rsa_key, output_pad ); If you generate enough OAEP samples, some of them will look like PKCS1 padding. Padding is *NOT* integrity protection. Per: https://tools.ietf.org/html/rfc2313#section-8.1 an input block that resembles PKCS1 padding for encryption with a public key looks like: 00 02 pseudo-random-non-zero* 00 data So, all you need is for the first two octets to be 00 02 (a 00 has an ~40% chance to follow somewhere in a sample of ~126 random octets). So this will happen from time to time (somewhat south of once every 64k tries). Encryption and decryption alone do not provide integrity protection. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding?
On Wed, Apr 29, 2015 at 03:42:40PM +, Perrow, Graeme wrote: Apologies for the top-post; Outlook makes it hard to do anything else. Here is a small C++ reproducible. I am generating a key pair, encrypting a small string using OAEP and decrypting using PKCS1 and expecting the decryption to fail. If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually fail because RSA_private_decrypt doesn't fail. I can run it hundreds of times successfully before it fails. I have also seen it fail on Windows 7. Originally, you said the decryption used RSA_NO_PADDING, the code below decrypts with RSA_PKCS1_PADDING. int output_pad = RSA_PKCS1_PADDING; memset( decrypted, 0, sizeof(decrypted) ); size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted, rsa_key, output_pad ); If you generate enough OAEP samples, some of them will look like PKCS1 padding. Padding is *NOT* integrity protection. Per: https://tools.ietf.org/html/rfc2313#section-8.1 an input block that resembles PKCS1 padding for encryption with a public key looks like: 00 02 pseudo-random-non-zero* 00 data So, all you need is for the first two octets to be 00 02 (a 00 has an ~40% chance to follow somewhere in a sample of ~126 random octets). So this will happen from time to time (somewhat south of once every 64k tries). Encryption and decryption alone do not provide integrity protection. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Porting to EVP methods: AES_set_encrypt_key()
On 29/04/15 21:39, jonetsu wrote: Hello, The context is migrating an application to use EVP only methods. AES_set_encrypt_key(...) AES_cfb128_encrypt(...) The AES_cfb128_encrypt() is pretty clear to migrate to EVP_*, what about the AES_set_encrypt_key() ? I haven't found yet any correlation to the EVP methods, let alone an actal description of AES_set_encrypt_key() purpose. How is this translted to EVP ? There isn't a one-for-one correlation. The key is supplied in the call to EVP_EncryptInit_ex(). See the following for some sample code: https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Porting to EVP methods: AES_set_encrypt_key()
Hello, The context is migrating an application to use EVP only methods. AES_set_encrypt_key(...) AES_cfb128_encrypt(...) The AES_cfb128_encrypt() is pretty clear to migrate to EVP_*, what about the AES_set_encrypt_key() ? I haven't found yet any correlation to the EVP methods, let alone an actal description of AES_set_encrypt_key() purpose. How is this translted to EVP ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/Porting-to-EVP-methods-AES-set-encrypt-key-tp57801.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SHA256() to EVP_* ?
Thanks for the comments. If you are implementing HMAC, perhaps for PBKDF2 (which does that prehash-if-too-long), I hope you mean the code does... Yes it does. The man page (the one online from OpenSSL project - SHA256.html) gives a description using SHA1() which computes a message digest. Being generally new to OpenSSL at that level, what is then the difference between using, say, SHA1() vs. using SHA1_Init, SHA1_Update and SHA1_Final ? Is it only that the latter allows for continuously add data until _Final is called ? -- View this message in context: http://openssl.6102.n7.nabble.com/SHA256-to-EVP-tp57774p57791.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS 140-2 on iOS
This is an excellent explanation in plain English. Thank you! On Apr 28, 2015, at 4:31 PM, Steve Marquess marqu...@openssl.com wrote: On 04/28/2015 03:44 PM, Sec_Aficionado wrote: Hi there, Total n00b question here. I recently ran across a question on an iOS forum where someone was building an app with FIPS 140-2 compliant communications. Note there really is no such thing as FIPS 140-2 compliant (though you see that terms bandied around a lot and I'm guilty of doing so myself). The term of interest is FISP 140-2 validated (n.b.: that's validated not certified). Now, from reading here (mailing lists) about FIPS certification, it involves both the bits and the platform. So it would not be possible to create an app that is compliant on a platform that hasn't been certified. Is that a correct assumption? Or can I build a compliant app with just certified libraries? A Level 1 FIPS 140-2 validation (Level 1 being the most common and the easiest) applies to a thing called a cryptographic module in the context of one of more OEs or Operational Environments (loosely speaking, platforms). Note at Level 1 products are not validated, operating systems are not validated, only cryptographic modules are validated. Translated from FIPSspeak, for a software module that means a very specific chunk of executable code running on a specific platform (operating system and OS version and processor architecture). Move that same code to another platform and it is no longer validated; the validation is relative to the OEs or platforms. The only valid reason to use a FIPS 140-2 validated module is that you must in order to sell your cryptography-using product to the USG or DoD. For that market you (typically, if the procurement officer is paying attention) have to use a validated cryptographic module on one of the OEs specifically listed for that module validation. So for a software product there is no such thing as validation of the product independent of the platform (OE) it runs on. A partial exception to that rule is user affirmation per I.G. G.5, but while technically a legitimate means of satisfying FISP 140-2 validation requirements that has limited practical value in the USG/DoD market. Note I'm only discussing Level 1 validations here; Levels 2 and up are different. -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/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding?
Apologies for the top-post; Outlook makes it hard to do anything else.
Here is a small C++ reproducible. I am generating a key pair, encrypting a
small string using OAEP and decrypting using PKCS1 and expecting the decryption
to fail.
If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually
fail because RSA_private_decrypt doesn't fail. I can run it hundreds of times
successfully before it fails. I have also seen it fail on Windows 7.
Graeme
#include string.h
#include openssl/rsa.h
int main( int, char ** )
/**/
{
BIGNUM *exponent = BN_new();
RSA *rsa_key = RSA_new();
BN_set_word( exponent, RSA_F4 );
int rc = RSA_generate_key_ex( rsa_key, 1024, exponent, NULL );
if( rc == 0 ) {
printf( RSA key generation failed\n );
return 1;
}
int input_pad = RSA_PKCS1_OAEP_PADDING;
const char *input = abcd;
size_t input_len = strlen( input );
unsigned char encrypted[1000];
unsigned char decrypted[1000];
size_t enc_len = RSA_public_encrypt( (int)input_len,
(const unsigned char *)input,
encrypted, rsa_key, input_pad );
int output_pad = RSA_PKCS1_PADDING;
memset( decrypted, 0, sizeof(decrypted) );
size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted,
rsa_key, output_pad );
if( dec_len == -1 ) {
return 0; // expected outcome
}
printf( RSA_private_decrypt succeeded, len=%ld bytes\n, dec_len );
return 1;
}
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Viktor Dukhovni
Sent: Saturday, April 25, 2015 1:41 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong
padding?
On Sat, Apr 25, 2015 at 12:49:21AM +, Perrow, Graeme wrote:
Using OpenSSL 1.0.1m on 64-bit Windows and Linux.
I have implemented RSA encryption using the RSA_public_encrypt and
RSA_private_decrypt functions and various padding types. This is working
fine except that in very rare cases, my test fails because decrypting
succeeds when it should fail. I'm basically doing this (pseudocode):
RSA_public_encrypt( abc, encrypted_data, my_public_key,
RSA_PKCS1_OAEP_PADDING );
RSA_private_decrypt( encrypted_data, decrypted_data, my_private_key,
RSA_NO_PADDING );
A real code fragment would be substantially more useful that
pseudo-code here. This should *always* succeed, provided you
pass the correct length to RSA_private_decrypt. From the manpage:
flen must be ... and exactly RSA_size(rsa) for RSA_NO_PADDING.
Note that the padding types are different. The vast majority of the time,
I get an error from the RSA_private_decrypt call but now and again, it
succeeds.
You're doing something wrong, it should always recover the OAEP
padded data, which is basically random, you need to reverse the
OAEP padding to recover the plaintext.
I don't understand the underlying crypto well enough to know - is it
possible for RSA_private_decrypt to be unable to tell that the wrong
padding was used, or is this a bug in OpenSSL?
When not using padding, that's not wrong padding, you're just
doing a raw RSA decrypt, and any input that is smaller than the
modulus (but has the same bit length) should decrypt to something.
--
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
