[openssl.org #698] documentation bug fix for openssl-0.9.7b
INSTALL.W32 228c228 $ copy /b inc32\* c:\openssl\include\openssl --- $ copy /b inc32\openssl\* c:\openssl\include\openssl __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: patent risk in encryption algotithm ?
DSA is unencumbered... I'm not sure about CAST On Thu, 2003-09-25 at 23:43, Boehme, Alfred wrote: Hello, I've been asked, if there is any known patent risk in the encryption algorithm of OpenSSL ? Especially DSA, CAST-128, and CAST-256 was asked for. Can someone help me here ? Thanks in advance Alfred __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: patent risk in encryption algotithm ?
DSA is public domain, CAST is an Entrust algorithm but I'm not sure if their patent is still active. Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Boehme, Alfred Sent: Friday, September 26, 2003 1:44 AM To: '[EMAIL PROTECTED]' Subject: patent risk in encryption algotithm ? Hello, I've been asked, if there is any known patent risk in the encryption algorithm of OpenSSL ? Especially DSA, CAST-128, and CAST-256 was asked for. Can someone help me here ? Thanks in advance Alfred __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
PKCS7 Des key parity
I have an application using the OpenSSL S/MIME interface. When I generate an encryptred message using DES, the DES key generated does not have odd parity. The key is generated in pk7_doit.c:PKCS7_dataInit by callingRAND_bytes(). In testing interoperability with the NIST S/MIME test center, the message is rejected. I know that odd parity is not a DES requirement, but DES keys should have odd parity. What is the best way to fix this problem? Can some code be added to the next OpenSSL release to do this?
Adding additional S/MIME signed attributes
I would like to be able to add some of my own S/MIME signed attributes based on characteristics of the message. Could a callback procedure be added to pk7_smime.c:PKCS7_sign() to support such a feature?
Re: PKCS7 Des key parity
On Fri, Sep 26, 2003, Robin Ehrlich wrote: I have an application using the OpenSSL S/MIME interface. When I generate an encryptred message using DES, the DES key generated does not have odd parity. The key is generated in pk7_doit.c:PKCS7_dataInit by calling RAND_bytes(). In testing interoperability with the NIST S/MIME test center, the message is rejected. I know that odd parity is not a DES requirement, but DES keys should have odd parity. What is the best way to fix this problem? Can some code be added to the next OpenSSL release to do this? Probably the best way is to add a flag to EVP_CIPHER which indicates that the key needs odd parity and then check the flag when a random key is generated and fix it up appropriately. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding additional S/MIME signed attributes
On Fri, Sep 26, 2003, Robin Ehrlich wrote: I would like to be able to add some of my own S/MIME signed attributes based on characteristics of the message. Could a callback procedure be added to pk7_smime.c:PKCS7_sign() to support such a feature? PKCS7_sign() is meant to be a simple PKCS#7 signer which just (hopefully) does all the right things. Things like adding custom signed attributes can be done using the low level API which the source to PKCS7_sign() uses. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: patent risk in encryption algotithm ?
Regarding CAST, see http://www.ietf.org/ietf/IPR//CAST-128-entrust. BTW, section 8 of RFC 3280 points to http://www.ietf.org/ipr.html. Frank Chris Brook [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: cc: owner-openssl-dev@Subject: RE: patent risk in encryption algotithm ? openssl.org 09/26/2003 09:41 AM Please respond to openssl-dev DSA is public domain, CAST is an Entrust algorithm but I'm not sure if their patent is still active. Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Boehme, Alfred Sent: Friday, September 26, 2003 1:44 AM To: '[EMAIL PROTECTED]' Subject: patent risk in encryption algotithm ? Hello, I've been asked, if there is any known patent risk in the encryption algorithm of OpenSSL ? Especially DSA, CAST-128, and CAST-256 was asked for. Can someone help me here ? Thanks in advance Alfred __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: patent risk in encryption algotithm ?
And additionally http://www.ietf.org/ietf/IPR/CAST-256-entrust says the same for CAST-256. -Nathan Frank Balluffi wrote: Regarding CAST, see http://www.ietf.org/ietf/IPR//CAST-128-entrust. BTW, section 8 of RFC 3280 points to http://www.ietf.org/ipr.html. Frank Chris Brook [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: cc: owner-openssl-dev@Subject: RE: patent risk in encryption algotithm ? openssl.org 09/26/2003 09:41 AM Please respond to openssl-dev DSA is public domain, CAST is an Entrust algorithm but I'm not sure if their patent is still active. Chris Brook -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Boehme, Alfred Sent: Friday, September 26, 2003 1:44 AM To: '[EMAIL PROTECTED]' Subject: patent risk in encryption algotithm ? Hello, I've been asked, if there is any known patent risk in the encryption algorithm of OpenSSL ? Especially DSA, CAST-128, and CAST-256 was asked for. Can someone help me here ? Thanks in advance Alfred __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL with KRB5 support, memory leak kssl_ctx_new()
Running an app that uses OpenSSL here through valgrind: ==10427== 6400 bytes in 200 blocks are definitely lost in loss record 4 of 4 ==10427==at 0x40029888: calloc (vg_replace_malloc.c:273) ==10427==by 0x403C61C7: kssl_ctx_new (in /lib/libssl.so.0.9.7a) ==10427==by 0x403B8AE7: SSL_new (in /lib/libssl.so.0.9.7a) ssl_lib.c line 244 of 2315 function SSL_new() #ifndef OPENSSL_NO_KRB5 s-kssl_ctx = kssl_ctx_new(); #endif /* OPENSSL_NO_KRB5 */ ssl_lib.c function SSL_free() does not appear to free this memory. As a note, the system libraries here are openssl 0.9.7a, but I'm looking through the 0.9.7b source and the handling doesn't appear any different there. In fact, kssl_ctx_free() isn't called from anywhere in ssl/*.c (it's commented out from one location). Seems like a simple fix: diff -up ssl_lib.c ../ssl-modified/ssl_lib.c --- ssl_lib.c 2003-01-30 06:00:37.0 -0500 +++ ../ssl-modified/ssl_lib.c 2003-09-26 15:36:14.0 -0400 @@ -473,6 +473,10 @@ void SSL_free(SSL *s) if (s-method != NULL) s-method-ssl_free(s); +#ifndefOPENSSL_NO_KRB5 + if (s-kssl_ctx != NULL) kssl_ctx_free(s-kssl_ctx); +#endif /* OPENSSL_NO_KRB5 */ + OPENSSL_free(s); } Andrew __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Defect? regarding Session ID's
I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Defect? regarding Session ID's
On Fri, Sep 26, 2003, Verdon Walker wrote: I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. This is actually there to protect against a case where a malicious client could resume a session in an inappropriate context. This only affects sessions that enable client authentication so it is only checked in those cases. This was addressed way back in March 1999. For more details see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Defect? regarding Session ID's
Thanks for the information. Verdon Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell, Inc., the leading provider of information solutions http://www.novell.com [EMAIL PROTECTED] 09/26/03 7:08 PM On Fri, Sep 26, 2003, Verdon Walker wrote: I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. This is actually there to protect against a case where a malicious client could resume a session in an inappropriate context. This only affects sessions that enable client authentication so it is only checked in those cases. This was addressed way back in March 1999. For more details see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Openssl 0.9.7b for AIX 5.2 to use /dev/random (request #558)
In message [EMAIL PROTECTED] on Wed, 24 Sep 2003 14:35:14 +0200, CHOVANEC Vladimr [EMAIL PROTECTED] said: Vladimir.CHOVANEC I would like to ask if any action has been taken Vladimir.CHOVANEC as a result of request #558. We have mentioned Vladimir.CHOVANEC AIX patch already installed Vladimir.CHOVANEC (http://www.ibm.com/support/docview.wss?uid=isg1IY43851) Vladimir.CHOVANEC but 'openssl rand 10' in vanilla openssl 0.9.7b Vladimir.CHOVANEC still fails while hacked one with first argument Vladimir.CHOVANEC 1 to select() in rand_unix.c works like a charm. Vladimir.CHOVANEC Vladimir.CHOVANEC We are ready to test any fixes :-) I've been away for a while for different reasons, but I'll start looking into our bugs database starting tomorrow. -- Richard Levitte \ Tunnlandsvgen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
