[openssl.org #1669] Two more CMS bugs
Hi. Thanks for the quick fix to RT #1664. I've run into two more bugs in the CMS code. I can provide isolated test cases if necessary, but the code that's currently producing these is buried deep in the guts of a Python extension module, so I'll start by just describing the problems in the hope that this will all be obvious to Steve. 1) CMS_final() and CMS_verify() both appear to be ignoring an EVP_R_COMMAND_NOT_SUPPORTED error. That is: both functions are giving me what I think are meant to be successful returns (non-zero return value for CMS_final(), return value greater than zero for CMS_verify()), but ERR_get_error() finds an unhandled error EVP_R_COMMAND_NOT_SUPPORTED that wasn't there before these calls. As far as I can tell, this error is harmless, other than confusing subsequent code. At least, I haven't seen any obvious bad side effects of ignoring the error, but of course I might have missed something. 2) CMS_add0_crl() dumps core. Due to the environment in which this is occuring I don't have a stack trace available, let me know if you need me to generate a test case that produces one. I don't see any code that exercises this particular function, so I don't know if it's ever been tested. If, in the process of fixing this, someone were to add CMS_add1_crl(), I wouldn't complain. :) Please let me know if you need more details or have trouble reproducing these problems. I'll be at the RIPE 56 meeting next week but will try to answer as promptly as circumstances allow. Thanks for all the good work on this. --Rob __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL certificate formats
Dear OpenSSL development team, I have some questions on the formats accept by OpenSSL programming interface in C/C++. The functions int SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx, const char *file, int type); int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type); accept two possible options for the type of the file, #define SSL_FILETYPE_ASN1 X509_FILETYPE_ASN1 #define SSL_FILETYPE_PEM X509_FILETYPE_PEM I would like to know: 1) Is there a C/C++ interface to directly read certificates in PKCS12 format? I understand that one can use OpenSSL command line to take PKCS12 and convert it, say, to PEM so that we could use the original function, but I need to know if it is possible to read PKCS12 directly, without creating a converted copy? 2) Are the above two the only certificate formats directly accepted by C/C++ interface? 3) We normally use PEM, I am not sure about ASN1, is it kind of obsolete or for backward compatibility? Thank you very much, Vladimir Shklover, SPSS
Problem with HMAC calculation
Hi, I facing on problem with openssl-0.9.8e. In my case HMAC is not calculated correctly with MD5 protocol. It is working fine with SH1 protocol What should I do about this. Regards, Sandeepa Sharma __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: OpenSSL_0_9_8-stable: openssl/ CHANGES Configure openss...
Log: Unobtrusive backport of 32-bit x86 Montgomery improvements from 0.9.9-dev: you need to use enable-montasm to see a difference. (Huge speed advantage, but BN_MONT_CTX is not binary compatible, so this can't be enabled by default in the 0.9.8 branch.) Index: openssl/CHANGES $ cvs diff -u -r1.1238.2.94 -r1.1238.2.95 CHANGES --- openssl/CHANGES 30 Apr 2008 16:11:31 - 1.1238.2.94 +++ openssl/CHANGES 1 May 2008 23:11:30 - 1.1238.2.95 @@ -4,6 +4,28 @@ Changes between 0.9.8g and 0.9.8h [xx XXX ] + *) Partial backport from 0.9.9-dev: + + New candidate for BIGNUM assembler implementation, bn_mul_mont, + dedicated Montgomery multiplication procedure, is introduced. + While 0.9.9-dev has assembler for various architectures, here + in the 0.9.8 branch, only x86_64 is available by default. + + With Configure option enable-montasm (which exists only for + this backport), the 32-bit x86 assembler implementation can be + activated at compile-time. In 0.9.9-dev, BN_MONT_CTX is modified + to allow bn_mul_mont to reach for higher 64-bit performance on + certain 32-bit targets. With enable-montasm, this BN_MONT_CTX + change is activated in the 0.9.8 branch. + + Warning: Using enable-montasm thus means losing binary + compatibility between patchlevels! (I.e., applications will + have to be recompiled to match the particular library.) + So you may want to avoid this setting for shared libraries. + Use at your own risk. The keyword is certain. While some platforms do require binary incompatible changes, others do *not*. x86 does *not*, so there is no reason to modify bn.h in this case. As for *now* the only platform that depends on bn.h update is 32-bit UltraSPARC build (though for 64-bit build one would have to adapt sparcv9a-mont.pl), but PowerPC and Itanium are to join. +#if defined(MONT_WORD) defined(OPENSSL_BN_ASM_MONT) (BN_BITS2=32) + if (!BN_from_montgomery_word(r,tmp,mont)) goto err; +#else if (!BN_from_montgomery(r,tmp,mont,ctx)) goto err; +#endif For reference, BN_from_montgomery_word was introduced for performance (it eliminates redundant malloc, which gives measurable improvement), there is no reason to make it BN_BITS2=32... I mean it should be there on not be there at all. The reason it was not back-ported with x86_64 module was that the minor releases are not widely tested by community (at least we don't explicitly encourage it prior minor releases) and we formally don't know if code breaks on some platform team members don't use on regular basis. x86-mont.pl was not back-ported for approximately same reason. Trouble is that while on x86_64 we have to cope with limited number of assemblers (fairly recent GNU and Solaris ones, both were explicitly tested by me), it's not the case on x86 platforms, where we find GNU, nasm and few vendor assemblers of all ages. One can argue that I'm being conservative, but isn't it what -stable branch should be about? Bottom line. x86-mont.pl can be added to 0.9.8 with only Configure and Makefile modifications and I think that's how it should be done. Whether or not it should be conditional. One can argue that sse2-capable GNU assembler qualifies as fairly recent and therefore fairly tested configuration and therefore exclude it from no-sse2 builds. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1669] Two more CMS bugs
[EMAIL PROTECTED] - Fri May 02 08:13:24 2008]: 1) CMS_final() and CMS_verify() both appear to be ignoring an EVP_R_COMMAND_NOT_SUPPORTED error. That is: both functions are giving me what I think are meant to be successful returns (non-zero return value for CMS_final(), return value greater than zero for CMS_verify()), but ERR_get_error() finds an unhandled error EVP_R_COMMAND_NOT_SUPPORTED that wasn't there before these calls. As far as I can tell, this error is harmless, other than confusing subsequent code. At least, I haven't seen any obvious bad side effects of ignoring the error, but of course I might have missed something. Should be fixed now. 2) CMS_add0_crl() dumps core. Due to the environment in which this is occuring I don't have a stack trace available, let me know if you need me to generate a test case that produces one. I don't see any code that exercises this particular function, so I don't know if it's ever been tested. If, in the process of fixing this, someone were to add CMS_add1_crl(), I wouldn't complain. :) I threw together a quick test program and couldn't reproduce this. Can you provide a test case? Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL: OpenSSL_0_9_8-stable: openssl/ CHANGES Configure
[EMAIL PROTECTED] (Andy Polyakov) to openssl-dev: Log: Unobtrusive backport of 32-bit x86 Montgomery improvements from 0.9.9-dev: you need to use enable-montasm to see a difference. (Huge speed advantage, but BN_MONT_CTX is not binary compatible, so this can't be enabled by default in the 0.9.8 branch.) Index: openssl/CHANGES $ cvs diff -u -r1.1238.2.94 -r1.1238.2.95 CHANGES --- openssl/CHANGES 30 Apr 2008 16:11:31 - 1.1238.2.94 +++ openssl/CHANGES 1 May 2008 23:11:30 - 1.1238.2.95 @@ -4,6 +4,28 @@ Changes between 0.9.8g and 0.9.8h [xx XXX ] + *) Partial backport from 0.9.9-dev: + + New candidate for BIGNUM assembler implementation, bn_mul_mont, + dedicated Montgomery multiplication procedure, is introduced. + While 0.9.9-dev has assembler for various architectures, here + in the 0.9.8 branch, only x86_64 is available by default. + + With Configure option enable-montasm (which exists only for + this backport), the 32-bit x86 assembler implementation can be + activated at compile-time. In 0.9.9-dev, BN_MONT_CTX is modified + to allow bn_mul_mont to reach for higher 64-bit performance on + certain 32-bit targets. With enable-montasm, this BN_MONT_CTX + change is activated in the 0.9.8 branch. + + Warning: Using enable-montasm thus means losing binary + compatibility between patchlevels! (I.e., applications will + have to be recompiled to match the particular library.) + So you may want to avoid this setting for shared libraries. + Use at your own risk. The keyword is certain. While some platforms do require binary incompatible changes, others do *not*. x86 does *not*, so there is no reason to modify bn.h in this case. As for *now* the only platform that depends on bn.h update is 32-bit UltraSPARC build (though for 64-bit build one would have to adapt sparcv9a-mont.pl), but PowerPC and Itanium are to join. Yeah, I guess in the end it should be easier to just take out this part of the modification, because then we make life easier for most by avoiding the BN_MONT_CTX incompatibility. It seems that for x86, you are computing but not actually using n0[1]. Including the BN_BITS=32 special case makes life easier for those who want to plug in some of the other assembler variants that actually use n0[1] (that assembler code is obviously not part of this CVS change, but a lot easier to use with it as a starting point). But the BN_MONT_CTX incompatibility is pretty annoying, so I'll get rid of it. +#if defined(MONT_WORD) defined(OPENSSL_BN_ASM_MONT) (BN_BITS2=32) +if (!BN_from_montgomery_word(r,tmp,mont)) goto err; +#else if (!BN_from_montgomery(r,tmp,mont,ctx)) goto err; +#endif For reference, BN_from_montgomery_word was introduced for performance (it eliminates redundant malloc, which gives measurable improvement), there is no reason to make it BN_BITS2=32... I mean it should be there on not be there at all. The reason it was not back-ported with x86_64 module was that the minor releases are not widely tested by community (at least we don't explicitly encourage it prior minor releases) and we formally don't know if code breaks on some platform team members don't use on regular basis. x86-mont.pl was not back-ported for approximately same reason. Trouble is that while on x86_64 we have to cope with limited number of assemblers (fairly recent GNU and Solaris ones, both were explicitly tested by me), it's not the case on x86 platforms, where we find GNU, nasm and few vendor assemblers of all ages. One can argue that I'm being conservative, but isn't it what -stable branch should be about? I know that BN_from_montgomery_word() is entirely optional. The reason for this specific #if condition is that this makes sure that it is excluded for all of the default builds (including x86_64) for exactly the code stability reasons that you describe. This rationale certainly deserves a source code comment for the #if, though! In an intermediate patch, I wasn't using BN_from_montgomery_word() at all. However, given that the x86 bn_mul_mont code is only activated for more adventurous types who actively specify enable-montasm at compile time for the sake of better performance, my reasoning was (and is) that there's nothing wrong with making available some related non-stable code for these as well to further improve performance -- while making sure to change nothing at all for all of the default builds, as it should be in a stable branch. Bodo __ OpenSSL Project http://www.openssl.org Development
Re: [openssl.org #1669] Two more CMS bugs
1) CMS_final() and CMS_verify() both appear to be ignoring an EVP_R_COMMAND_NOT_SUPPORTED error. Should be fixed now. Confirmed, patch pulled from CVS appears to fix this. Thanks! 2) CMS_add0_crl() dumps core. I threw together a quick test program and couldn't reproduce this. Can you provide a test case? Apologies. Upon fifth reading, this turned out to be a 03:00 pilot error: my code was passing the wrong CMS_ContentInfo* variable, so this is just what happens when an idiot like me passes a null pointer as first argument to CMS_add0_crl(). Code ran fine once I fixed that. Sorry for the noise. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Problem with HMAC calculation
Sandeepa SHARMA wrote: I facing on problem with openssl-0.9.8e. In my case HMAC is not calculated correctly with MD5 protocol. It is working fine with SH1 protocol What should I do about this. The courteous path would be to post a test program that demonstrates the failure, and say what compiler and operating system you used. You might try running the test case on other platforms first, in case the problem lies in your compiler or runtimes. PG __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
