[openssl-users] What is release date for openssl 1.0.2
Hi All: I wonder when openssl 1.0.2 will officially release? Is there any exact schedule? Thanks! -- Rejoice,I Desire! ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] What is release date for openssl 1.0.2
On 11/12/14 09:04, Jerry OELoo wrote: Hi All: I wonder when openssl 1.0.2 will officially release? Is there any exact schedule? Thanks! There is no official date that I can give you. We had hoped to have already released it, however we have had some issues that have delayed it. I currently expect it to be very early in the New Year. Matt ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] Error: A call to SSPI failed ...
Dear team, Can someone tell me why the error is happening as SSPI failed ? Am seeing this new today and when I searched the internet - it says whenever there is a BAD formed request or when there is no client certificate - we may get this error. Can someone shed more light here ? 12/11/2014 12:50:06.161 ByteCount: 69 SSL Authentication failed A call to SSPI failed, see inner exception. 12/11/2014 12:50:06.161 ByteCount: 25 SSL Authentication failed Thanks Regards Karthikeyan Thirumal ADD-Web-NXP-India, Application Development Delivery iNautix Technologies India Pvt. Ltd., A BNY Mellon Company. Extn (Internal): 612-10650 Direct Line: (+1) 615-381-0650 Email: kthiru...@inautix.co.inmailto:kthiru...@inautix.co.in Information Classification: Internal Use Only ** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. **___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] CVE-2011-1473 fixed version
Hi All, Please let me know in which version CVE-2011-1473 got fixed. Is openssl-1.x is vulnerable to this issue? Thanks, Gayathri ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2011-1473 fixed version
On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Hi All, Please let me know in which version CVE-2011-1473 got fixed. Is openssl-1.x is vulnerable to this issue? https://www.openssl.org/news/vulnerabilities.html ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Any way to create a large encrypted finish message?
One can't change the encrypted finished size unless one is using variable padding. encrypted finished size depends on 3 parameters: protocol version, cipher type, MAC type, Protocol version decides if explicit IV is included in the record and unencrypted finished message size. For SSL3 and TLS1.0, there wouldn't be any explicit IV. For SSL3, unencrypted finished size would be of 40 bytes (4 (handshake header) + 16(MD5 hash)+20(SHA hash) ) and for other protocols it will be 16 bytes(4(handshake header) + 12 bytes(xor of MD5 and SHA1 hashes)) Cipher Type decides, if the data needs to be padded or not. If it is block cipher, there would be 1 block of must padding of block length(16 for AES, 8 for DES). It also decides explicit IV length. MAC(hash) type decides the length of the MAC tag that will be appended to the unencrypted data before padding. For TLS1.2, AES256-SHA/AES128-SHA, encrypted finished message consists of 16 byte explicit IV + 16 byte finished message + 20 byte hash + 16 byte must padding. so, it will be of 68 bytes. For DES-CBC3-SHA, it will be 8 byte explicit IV + 16 byte finished message + 20 byte hash + 8 byte must padding. i.e it will be 52 bytes. Thanks, Thulasi. On 11 December 2014 at 04:15, Vyas Pentakota npent...@brocade.com wrote: Hi I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate “encrypted handshake message” (client finish message) record larger than 64 bytes only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA. Your suggestion is greatly appreciated. Thank you Vyas ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2011-1473 fixed version
Hi Jeffrey, In this its not mentioned. Thanks, Gayathri On Thu, Dec 11, 2014 at 4:46 PM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Hi All, Please let me know in which version CVE-2011-1473 got fixed. Is openssl-1.x is vulnerable to this issue? https://www.openssl.org/news/vulnerabilities.html ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2011-1473 fixed version
On Thu, Dec 11, 2014 at 6:35 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Hi Jeffrey, In this its not mentioned. Then its not applicable or has not been fixed. On Thu, Dec 11, 2014 at 4:46 PM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Hi All, Please let me know in which version CVE-2011-1473 got fixed. Is openssl-1.x is vulnerable to this issue? https://www.openssl.org/news/vulnerabilities.html ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2011-1473 fixed version
On 11/12/14 11:35, Gayathri Manoj wrote: Hi Jeffrey, In this its not mentioned. Thanks, Gayathri On Thu, Dec 11, 2014 at 4:46 PM, Jeffrey Walton noloa...@gmail.com mailto:noloa...@gmail.com wrote: On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj gayathri.an...@gmail.com mailto:gayathri.an...@gmail.com wrote: Hi All, Please let me know in which version CVE-2011-1473 got fixed. Is openssl-1.x is vulnerable to this issue? I wasn't involved at the time, but reading about it now CVE-2011-1473 essentially says (as I understand it) that if you fire lots of SSL handshakes at a server it could cause a DoS because it is much cheaper on the client side than it is on the server side. This isn't a flaw in OpenSSL per se, this is a problem at a protocol level. There are some possible mitigations, and there is an interesting discussion on the issue here: http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html#rate_limiting_ssl_handshakes In answer to your question CVE-2011-1473 has not been fixed in OpenSSL and there are no plans to do so. The answer to this is going to be more about what DoS mitigations you are using within your infrastructure, what ciphersuites you choose to use, etc. Matt ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Any way to create a large encrypted finish message?
A correction regarding padding. On 11 December 2014 at 16:53, Thulasi Goriparthi thulasi.goripar...@gmail.com wrote: One can't change the encrypted finished size unless one is using variable padding. encrypted finished size depends on 3 parameters: protocol version, cipher type, MAC type, Protocol version decides if explicit IV is included in the record and unencrypted finished message size. For SSL3 and TLS1.0, there wouldn't be any explicit IV. For SSL3, unencrypted finished size would be of 40 bytes (4 (handshake header) + 16(MD5 hash)+20(SHA hash) ) and for other protocols it will be 16 bytes(4(handshake header) + 12 bytes(xor of MD5 and SHA1 hashes)) Cipher Type decides, if the data needs to be padded or not. If it is block cipher, there would be 1 block of must padding of block length(16 for AES, 8 for DES). It also decides explicit IV length. MAC(hash) type decides the length of the MAC tag that will be appended to the unencrypted data before padding. For TLS1.2, AES256-SHA/AES128-SHA, encrypted finished message consists of 16 byte explicit IV + 16 byte finished message + 20 byte hash + 16 byte must padding. so, it will be of 68 bytes. In this case, there would only be 12 bytes of padding as record is already 36 bytes, making it 64 bytes. For DES-CBC3-SHA, it will be 8 byte explicit IV + 16 byte finished message + 20 byte hash + 8 byte must padding. i.e it will be 52 bytes. Same here,there would only be 12 bytes of padding as record is already 36 bytes, making it 64 bytes. Thanks, Thulasi. On 11 December 2014 at 04:15, Vyas Pentakota npent...@brocade.com wrote: Hi I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate “encrypted handshake message” (client finish message) record larger than 64 bytes only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA. Your suggestion is greatly appreciated. Thank you Vyas ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Error: A call to SSPI failed ...
On 11 December 2014 at 10:20, Thirumal, Karthikeyan kthiru...@inautix.co.in wrote: Dear team, Can someone tell me why the error is happening as SSPI failed ? Am seeing this new today and when I searched the internet - it says whenever there is a BAD formed request or when there is no client certificate - we may get this error. Can someone shed more light here ? 12/11/2014 12:50:06.161 ByteCount: 69 SSL Authentication failed A call to SSPI failed, see inner exception. Since this is an error from .net you're asking the wrong place. This list is for users of openssl. Regards Rich. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] Hashing public keys in EVP_PKEY's
Hello,
If I would want to use the hash of a EVP_PKEY to uniquely identify
the key (regardless of whether it contains the private key or not), what
would be the best way to do this? (I.e. how do I deterministically hash
the public key of a EVP_PKEY?).
Performance is not a major concern.
The system has buffers which contain keys which are base64 encoded
versions of what i2d_{RSA,DSA,EC}_PUBKEY() outputs. Internally in the
applications these are made into EVP_PKEY's again by
d2i_{RSA,DSA,EC_KEY}_PUBKEY() + EVP_PKEY_assign_{RSA,DSA,EC_KEY}().
How bit-by-bit identical are buffers produced by:
out = NULL;
switch(EVP_PKEY_type(pkey-type)) {
case EVP_PKEY_RSA:
len = i2d_RSA_PUBKEY(pkey-pkey.rsa, out);
break;
case EVP_PKEY_DSA:
len = i2d_DSA_PUBKEY(pkey-pkey.dsa, out);
break;
case EVP_PKEY_EC:
len = i2d_EC_PUBKEY(pkey-pkey.ec, out);
break;
default:
return SOHERR_BAD_PARAM;
}
.. ?
I'm assuming it'll be pretty safe to hash the rsa buffer (..?) but I
feel like the DSA and EC buffers are a little more sketchy (because of
potential parameter issues).
I browsed around in the source tree and found this:
-
int X509_pubkey_digest(const X509 *data, const EVP_MD *type, unsigned
char *md, unsigned int *len)
{
ASN1_BIT_STRING *key;
key = X509_get0_pubkey_bitstr(data);
if(!key) return 0;
return EVP_Digest(key-data, key-length, md, len, type, NULL);
}
-
Apart from that it uses an X509, it looks like exactly what I need,
and it made me realize that the deterministic properly I'm looking for
is internally called bitstream.
I tried to follow the clues from x509_get0_pubkey_bitstr(), but I
quickly got confused in the ASN1 code. :)
Is it safe to hash the output from i2d_*_PUBKEY? Is it
super-deterministic as long as one doesn't change parameters around for
DSA and EC?
--
Kind Regards,
Jan
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Hashing public keys in EVP_PKEY's
On Thu, Dec 11, 2014 at 04:02:10PM +0100, Jan Danielsson wrote:
If I would want to use the hash of a EVP_PKEY to uniquely identify
the key (regardless of whether it contains the private key or not), what
would be the best way to do this? (I.e. how do I deterministically hash
the public key of a EVP_PKEY?).
Be careful to produce a hash of a full SPKI structure (algorithm
oid, parameters, key bits) and not just the key bits. Without the
algorithm and parameter context, there is I think a likelihood of
attacks depending on how the hashes are to be used.
-
int X509_pubkey_digest(const X509 *data, const EVP_MD *type, unsigned
char *md, unsigned int *len)
{
ASN1_BIT_STRING *key;
key = X509_get0_pubkey_bitstr(data);
if(!key) return 0;
return EVP_Digest(key-data, key-length, md, len, type, NULL);
}
-
This is used to compute the SHA-1 keybits hash for authority key
identifier computations, but is NOT the appropriate hash to use
in general. It is exactly the key-bits only digest I am suggesting
you avoid.
Instead, use i2d_PUBKEY() and compute the appropriate digest of
that.
--
Viktor.
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] Using s_client under z/OS installation
I am trying to use the s_client feature to retrieve certificates from other SMPT servers. The s_client connection works to other z/OS systems, but fails to any ASCII based mail server. Tracing the connections show that the EHLO goes out in EBCDIC and the responding server claims unknown command. This make sense on the surface. Is there a way to force the outbound to ASCII data stream (supported by z/OS on other connections), or is there a way to install OPENSSL using ASCII under the z/OS OMVS umbrella? Thanks for your help, Victor Savino| z/OS Network Engineer Lead | GTI ECS Enterprise Software Engineering (ESE) Network J.P. Morgan Chase Co. | 575 Wahignton Blvd, Jersey City NJ 07310, US | Office: 201-595-5044 (victor.sav...@jpmchase.com) This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Using s_client under z/OS installation
A quick look at apps/s_client.c in the 1.0.1j sources suggests that it does EBCDIC-ASCII translation if it was compiled with CHARSET_EBCDIC. What version are you using? Was it built with CHARSET_EBCDIC defined? Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Savino, Victor Sent: Thursday, December 11, 2014 10:53 To: 'openssl-users@openssl.org' Subject: [openssl-users] Using s_client under z/OS installation I am trying to use the s_client feature to retrieve certificates from other SMPT servers. The s_client connection works to other z/OS systems, but fails to any ASCII based mail server. Tracing the connections show that the EHLO goes out in EBCDIC and the responding server claims unknown command. This make sense on the surface. Is there a way to force the outbound to ASCII data stream (supported by z/OS on other connections), or is there a way to install OPENSSL using ASCII under the z/OS OMVS umbrella? This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Using s_client under z/OS installation
Thanks for the quick response. I compiled it with the EBCDIC option. I think that is my problem. The EHLO goes out in EBCDIC to an ASCII server. So then I receive an invalid command response, makes sense. When I point to another z/OS system to retrieve the certs it goes out EBCDIC and responds properly with the cert chain. But in this dual EBCDIC example both sides are talking the same language. When I trace inbound to z/OS from an ASCII machine, z/OS recognizes the ASCII and does its magic. What I need to happen is the z/OS version to be sent in ASCII so the other side can read it. I hope I am making sense. Thanks for your help on this. Victor Savino| z/OS Network Engineer Lead | GTI ECS Enterprise Software Engineering (ESE) Network J.P. Morgan Chase Co. | 575 Wahignton Blvd, Jersey City NJ 07310, US | Office: 201-595-5044 (victor.sav...@jpmchase.com) From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Wojcik Sent: Thursday, December 11, 2014 12:08 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Using s_client under z/OS installation A quick look at apps/s_client.c in the 1.0.1j sources suggests that it does EBCDIC-ASCII translation if it was compiled with CHARSET_EBCDIC. What version are you using? Was it built with CHARSET_EBCDIC defined? Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Savino, Victor Sent: Thursday, December 11, 2014 10:53 To: 'openssl-users@openssl.org' Subject: [openssl-users] Using s_client under z/OS installation I am trying to use the s_client feature to retrieve certificates from other SMPT servers. The s_client connection works to other z/OS systems, but fails to any ASCII based mail server. Tracing the connections show that the EHLO goes out in EBCDIC and the responding server claims unknown command. This make sense on the surface. Is there a way to force the outbound to ASCII data stream (supported by z/OS on other connections), or is there a way to install OPENSSL using ASCII under the z/OS OMVS umbrella? This message has been scanned for malware by Websense. www.websense.comhttp://www.websense.com/ This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2011-1473 fixed version
I wasn't involved at the time, but reading about it now CVE-2011-1473 essentially says (as I understand it) that if you fire lots of SSL handshakes at a server it could cause a DoS because it is much cheaper on the client side than it is on the server side. That's pretty disingenuous. You can open lots of connections to a server and eventually the server will exhaust resources. Sigh I've got an improvement on the attack: use a botnet to have compromised hosts open one or two connections each to evade firewalls ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Any way to create a large encrypted finish message?
Thanks Thulasi, for the clarification. Does this apply to all TLS implementations or just openssl? Vyas From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Thulasi Goriparthi Sent: Thursday, December 11, 2014 3:40 AM To: openssl-users@openssl org Subject: Re: [openssl-users] Any way to create a large encrypted finish message? A correction regarding padding. On 11 December 2014 at 16:53, Thulasi Goriparthi thulasi.goripar...@gmail.commailto:thulasi.goripar...@gmail.com wrote: One can't change the encrypted finished size unless one is using variable padding. encrypted finished size depends on 3 parameters: protocol version, cipher type, MAC type, Protocol version decides if explicit IV is included in the record and unencrypted finished message size. For SSL3 and TLS1.0, there wouldn't be any explicit IV. For SSL3, unencrypted finished size would be of 40 bytes (4 (handshake header) + 16(MD5 hash)+20(SHA hash) ) and for other protocols it will be 16 bytes(4(handshake header) + 12 bytes(xor of MD5 and SHA1 hashes)) Cipher Type decides, if the data needs to be padded or not. If it is block cipher, there would be 1 block of must padding of block length(16 for AES, 8 for DES). It also decides explicit IV length. MAC(hash) type decides the length of the MAC tag that will be appended to the unencrypted data before padding. For TLS1.2, AES256-SHA/AES128-SHA, encrypted finished message consists of 16 byte explicit IV + 16 byte finished message + 20 byte hash + 16 byte must padding. so, it will be of 68 bytes. In this case, there would only be 12 bytes of padding as record is already 36 bytes, making it 64 bytes. For DES-CBC3-SHA, it will be 8 byte explicit IV + 16 byte finished message + 20 byte hash + 8 byte must padding. i.e it will be 52 bytes. Same here,there would only be 12 bytes of padding as record is already 36 bytes, making it 64 bytes. Thanks, Thulasi. On 11 December 2014 at 04:15, Vyas Pentakota npent...@brocade.commailto:npent...@brocade.com wrote: Hi I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate “encrypted handshake message” (client finish message) record larger than 64 bytes only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA. Your suggestion is greatly appreciated. Thank you Vyas ___ openssl-users mailing list openssl-users@openssl.orgmailto:openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] Any way to create a large encrypted finish message?
Thanks Thulasi, for the clarification. Does this apply to all TLS implementations or just openssl? It's protocol definitions, not implementations. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
[openssl-users] eng_cryptodev question
I have implemented a H/W encryption driver and have integrated it with cryptodev. In eng_cryptodev.c there is an array digests[]. In that array it defines CRYPTO_MD5 to have a keylen of 16. In cryptodev, the xform.c file definedes MD5 to have a keylen of 0.Why is the keylen not zero for the MD5 entry in this table? Cryptodev also defines the keylen in a structure. The keylen is zero there. A comparison happens on session creation. This difference causes a check in the session creation to fail and cryptodev always selects the s/w crypto engine. If I change the eng_cryptodev digests[] entry for CRYPTO_MD5 to have a keylen of zero the MD5 hashing works, however Key generation output changes. If you run the openssl test case for key generation it will fail. It seems that the files generated are smaller. I don't see how this change has this side affect with key generation. Chris. ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
