EVP_get_digestbyname and 'standard' signature algorithm names
I'm trying to develop an application with OpenSSL that needs to verify a variety of digital signatures from different places. Currently I use EVP_get_digestbyname to get an EVP_MD handle identifying the algorithm used, and this works well for things that originally came from OpenSSL, but less well with things that come from elsewhere. For example, Oracle sends me signatures identified as SHA512withRSA, which I need to translate into sha512WithRSAEncryption in order for EVP_get_digestbyname to accept and give me something that works (note the case differences as well as the extra -Encryption suffix). Is there any sort of standard for what these strings should be? Is there a way to get OpenSSL to be more 'permissive' when looking up algorithms by name like this? Currently I'm just manually building up a set of aliases to translate to their OpenSSL equivalents as I run into them, but it seems it should be possible to do something more general. Chris Dodd d...@csl.sri.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: weak key check?
On 02/19/2012 07:36 PM, anthony berglas wrote: Exactly. So you need about 112 bits of entropy / Pass Phrase to generate a good 2048 bit key. Remember that the vast majority of 2048 bit numbers are not valid key pairs. My question is, has this been done, or would it be easy to do given the existing structure. No, this is NOT true. While it is the case that a good 2048 bit RSA key gives you only about 112 bits of security, its not at all clear that you can generate such a good key from less than 2048 bits of entropy. Indeed, from the recently published Lenstra/Hughes attack, its clear that using 112 bits of entropy to generate an RSA key (of any length) cannot possibly give you more that 56 bits of security, and probably far less. Chris Dodd d...@csl.sri.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: What is the maximum data size for encrypting with rsautl command?
Roughly keysize - paddingsize is the limit. keysize in your case is 512 bytes and padding size for OAEP padding (the common standard) is ~41, so the limit is about 471 bytes. Usually when encrypting a file, you use a symmetric cipher with a randomly chosen key, and then encrypt the key with RSA and prepend that to the encrypted file. -chris On 06/27/2011 09:00 AM, ml.vladimbe...@gmail.com wrote: Hello. I tried to encrypt a file(1Mb), with RSA private key of 4096-bit length with command: openssl rsautl -encrypt -pubin -inkey rsapublickey.pem -in 2.txt -out 2.srsa I get next error: Loading 'screen' into random state - done RSA operation error 5616:error:0406D06E:rsa routines:RSA_padding_add_PKCS1_type_2:data too large for key size:.\crypto\rsa\rsa_pk1.c:151: __ 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: Question regarding to memory leak
On Fri, Jun 24, 2011, Yan, Bob wrote: Hi, I have used IBM purify to check my test program which invokes openssl library. There are some memory leaks reported by Purify, please see below. Could somebody point to me from which function those leaks were generated, and how to avoid those leaks? Thanks, Bob MLK: 1104 bytes leaked in 46 blocks This memory was allocated from: malloc [rtlib.o] CRYPTO_malloc [libcrypto.so.1.0.0] ASN1_STRING_type_new [libcrypto.so.1.0.0] ASN1_primitive_new [libcrypto.so.1.0.0] asn1_item_ex_combine_new [libcrypto.so.1.0.0] asn1_item_ex_combine_new [libcrypto.so.1.0.0] ASN1_item_ex_d2i [libcrypto.so.1.0.0] asn1_template_noexp_d2i [libcrypto.so.1.0.0] Block of 24 bytes (46 times); last block at 0x2c0f7218 I've used valgrind with OpenSSL based programs to find memory leaks, and with it, you can use a --num-callers=N option to get deeper stack traces in the leak reports. You need a depth of 15-20 to get far enough to see where your code is calling into the OpenSSL code in most cases. There's probably a similar option for IBM purify. -chris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL and multithreaded programs
Is the OpenSSL library supposed to be at all reentrant? I've had odd problems (intermittent errors) when trying to use OpenSSL in a multithreaded program (multiple threads each dealing with independent SSL connections), and have apparently solved them by creating a single global mutex and wrapping a mutex acquire around every call into the library. Is this kind of locking expected to be needed? Chris Dodd cd...@csl.sri.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
