Re: [openssl.org #1712] OpenSSL 0.9.8h: Test BN_sqr dumps core reliably on FreeBSD 4.x i386
I've tried installing OpenSSL 0.9.8h from source on several FreeBSD 4.x systems, but they all fail the same test while running 'make test' after a successful compile (this is on FreeBSD 4.4 on an i386): $ ./config -d --prefix=/usr --openssldir=/etc/ssl shared $ gmake [...] $ gmake test [...] starting big number library test, could take a while... test BN_sqr Segmentation fault - core dumped gmake[1]: *** [test_bn] Error 139 See PROBLEMS file in OpenSSL distribution. This very case (shared build, error 139 in BN_sqr) is discussed there. It's not OpenSSL bug. I'm dismissing the case. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1699] Compile failure for 0.9.8h
Problem is resolved by http://cvs.openssl.org/chngview? cn=17335. I apologize for inconvenience. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1694] OpenSSL 0.9.8h bug: Configure has illegal -X 64, should be -X64
in Configure, line 415, we see AR option -X 64. There should not be space, so correct one is -X64. It was there for years [and was working for me at numerous occasions]. How come it doesn't for you? What's your AIX version? As for illegality. AIX manual page appears to be permitting for space. Is it IBM ar that gets invoked? I mean is there chance that you run GNU ar? But perhaps many users use OBJECT_MODE=64 commandline argument they do not see anything wrong. Build system is designed to override OBJECT_MODE, i.e. you can have OBJECT_MODE set to 32, run ./Configure aix64-cc and it should build 64-bit library. And vice versa. Which is why aix-cc contains explicit -X 32, with space... How come nobody complained about this one so far either? Could you please correct this, thanks. How do we know it doesn't break things for others? I mean as already mentioned it was working for years and given that your problem appears as deviation. Note that I'm not saying that it won't be changed, all I'm saying is that presented evidence does not suffice for suggested change. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1681] 0.9.8h bug report
You should not touch the file sha1-586.pl sha1-586.pl was back-ported from in-development HEAD branch and extra argument is a left-over and *should not* be there. because the problem is located in the file x86ms.pl that is dedicated to MASM. In this file, the line 273 containing $extra should be removed to be able to compile the generated assembly files. $extra is used in another modules. They, other modules, *might* work without it now, but it used to be required. Given *might*/*should not* relationship, it's extra argument of 16 in sha1-586.pl that should go, not $extra in x86ms.pl. Changes are committed and case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1708]
I found the solution to this bug. The Mac Intel should be little endian, not big endian. As was mentioned on openssl-dev, it's known problem, but unfortunately modifying FIPS 1.1.2 code is not an option. The problem was addressed earlier in regular branches. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1708] Resolved: OpenSSL FIPS 1.1.2 build bug for Intel Mac
Andy, I resolved the problem by changing the endian flag for Intel Macs in the configure file. See my note below. Perhaps, this change to the configure file can be included in future releases. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For the Intel Mac, change the Configure file. The value for darwin-i386-cc should be L_ENDIAN, not B_ENDIAN. Otherwise you'll get a fips_canister fingerprint mismatch. darwin-i386-cc,cc:-O3 -fomit-frame-pointer -fno-common -DL_ENDIAN:: -D_REENTRANT:MACOSX::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR::: darwin-shared:-fPIC::.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib, - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thanks, Mike Wilder Cimcor, Inc. -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 7:02 AM To: [EMAIL PROTECTED] Subject: [openssl.org #1708] Resolved: OpenSSL FIPS 1.1.2 build bug for Intel Mac According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1706] FIPS-compliant OpenSSL for x86_64 platform
We're implementing our own web-server intended to run on Win32 platform and using OpenSSL for TLS/SSL support. We're obliged to be FIPS-certified and we're using OpenSSL 0.9.7 with FIPS module for these purposes. Recently, we were requested to support amd64 platform. I've tried to build OpenSSL 0.9.8, but it failed to build successfully neither with cross-compiler, nor with native x86_64 gcc compiler. Anyway, I had to modify makefiles in both approaches. Is there any method to build 64-bit version of FIPS-compliant OpenSSL? Not for the moment. As mentioned on openssl-dev (see http://marc.info/?t=12145137868r=1w=2), validated 0.9.7-based code does not support Win64 and never will. 0.9.8-based code does support Win64, but it's not yet validated. I'm dismissing this case. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1706] FIPS-compliant OpenSSL for x86_64 platform
It's awfully hard to investigate a problem or find workarounds for a problem when the only description you have is it failed to build successfully. Perhaps I could find a way to avoid the modifications you needed, except you don't tell me what they are. Don't expect RT submitters to be subscribed to openssl-dev. Reply to [EMAIL PROTECTED] if you want them to hear you. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: build openssl-0.9.8f shared library for win64
I tried to build first build openssl-0.9.8e for win 64 using perl Configure VC-WIN64A and it failed saying that pthread.h is not found so I decided to try 0.9.8f which is building fine. Now I decided to build the shared library version but when I typed “perl Configure VC-WIN64A shared” using openssl-0.9.8f I got a message saying that the “shared” option is not supported yet on that platform and to contact you. So my question is to know how I can build the shared library version for win 64. By following instructions in INSTALL.W64. Switch between shared and non-shared builds is done by choosing ms\ntdll.mak or ms\nt.mak, not by passing shared argument to Configre. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1708]
Andy, I resolved the problem by changing the endian flag for Intel Macs in the configure file. See my note below. Perhaps this change to the configure file can be included in future releases. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For the Intel Mac, change the Configure file. The value for darwin-i386-cc should be L_ENDIAN, not B_ENDIAN. Otherwise you'll get a fips_canister fingerprint mismatch. darwin-i386-cc,cc:-O3 -fomit-frame-pointer -fno-common -DL_ENDIAN:: -D_REENTRANT:MACOSX::BN_LLONG RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTR::: darwin-shared:-fPIC::.\$(SHLIB_MAJOR).\$(SHLIB_MINOR).dylib, - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thanks, Mike Wilder Cimcor, Inc. -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 7:02 AM To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1708] I found the solution to this bug. The Mac Intel should be little endian, not big endian. As was mentioned on openssl-dev, it's known problem, but unfortunately modifying FIPS 1.1.2 code is not an option. The problem was addressed earlier in regular branches. Case is being dismissed. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64
Here's a patch against today's snapshot of head. I think that you has to compile with -DWIN32_LEAN_AND_MEAN in Configure before to do some undefs in openssl headers. I'm not really convinced, but for the time being, I've added that compile option to get rid of that more or less cosmetic issue. Apart from adding a line to configure, I needed a slight modification to apps/speed.c and engines/e_aep.c because mingw-w64 comes with definitions for pid_t and alarm How do we know that these are not or should not be treated as mingw64 bugs? I mean it worked for mingw for years (I wonder how by the way), now ancestor is *being developed* and how come it's not its fault:-) Well, I can accept that pid_t could be treated better in OpenSSL (#ifdef there is nothing but strange), but I don't buy masking of alarm. It's impossible to implement Unix-ish alarm on Windows and it simply shouldn't be there (nor SIGALRM definition). Quick check reveals that alarm is nothing but return 0. What's more appropriate: to be honest or not to tell truth? I mean absence of alarm would be honest, while implementing it as return 0 would be not telling truth... and in crypto/mem_cmp.c, http://cvs.openssl.org/chngview?cn=17337. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [RFC][RESEND] New hash type needed for RSA_sign()
Hi Stephen, Dr. Stephen Henson [EMAIL PROTECTED] writes: Well RSA_private_encrypt() despite its name is a signing operation. There is a PKCS#11 equivalent (C_Sign and the CKM_RSA_PKCS mechanism) though some tokens don't support it fully but emulate it in such a way that it only works for a fixed range of digests. Removing the length check in libp11 code that interfaces with OpenSSL corrects the issue, which seems to indicate that the hardware has no problem with the type of hash (i.e. does not verify it). I tested again with blobs of 4, 33 and 88 bytes with both tokens: no pb. If a token supports it but the PKCS#11 ENGINE has no equivalent that's an ENGINE implementation issue. I just took some minutes to look at the code and RSA_sign() implementation in libp11 (PKCS11_sign() in p11_ops.c) basically makes a direct PKCS#11 call (C_Sign and CKM_RSA_PKCS) after the hash length check and OID additions when OpenSSL call RSA_private_encrypt(). In libp11, the implementation of RSA_private_encrypt() is an empty shell that simply returns Not supported. In the end, if I follow your first comment (C_Sign and the CKM_RSA_PKCS mechanism are the PKCS#11 equivalent of RSA_private_encrypt()), I don't see why the PKCS#11 call is not in the implementation of RSA_private_encrypt() in libp11, which would be called by RSA_sign(). I will check that with the libp11 developers and stop the noise on openssl-dev. I'll made a post here at the end of the story. If the actual token doesn't fully support an RSA_private_encrypt() equivalent then you are SOL. there is some hope, I think ;-) Using RSA_sign() with NID_md5_sha1 had the problem that the length is incorrect which is why you need to disable the length check. This has some security implications: for example the well publicised exponent 3 issue. That's what I thought. Thanks for your time and your comments, Cheers, a+ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
CRYPTO_THREADID_* code in 0.9.9: come gone again? [quick question]
Hi, Sorry to bother, but just a quick question: those new threadid handling routines that got into 0.9.9 a while ago disappeared from the latest CVS (today) again. I assume this is intentional? Just a Yes/No 's all I crave. Thanks for answering and keep it up! -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_THREADID_* code in 0.9.9: come gone again? [quick question]
On Wednesday 16 July 2008 16:58:11 Ger Hobbelt wrote: Hi, Sorry to bother, but just a quick question: those new threadid handling routines that got into 0.9.9 a while ago disappeared from the latest CVS (today) again. I assume this is intentional? Just a Yes/No 's all I crave. Thanks for answering and keep it up! Yep, I'll also be reverting Bodo's original idptr_callback commit too. It turns out easier to fix threadid relative to what was pre-0.9.9 than to hack it on top of existing stuff. So the first CRYPTO_THREADID attempt is gone, but I won't revert Bodo's existing changes until I'm ready to commit the second CRYPTO_THREADID attempt. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Contribution to OpenSSL
Hi, I have sent this mail once before, tell me if it's offtopic or where should I ask about contributing to OpenSSL. I have developed library based on OpenSSL 0.9.8 that implemented ETSI standard for long term signatures. It allows electronic signatures to be valid for long period of time (many years) by adding timestamps as an unsigned attributes. I was thinking about adding my library to official OpenSSL library, OpenSSL version 0.9.9 will support CMS standard and it can be useful to create long-life signatures. Are you interested in my contribution? Tomas Vrabel __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Contribution to OpenSSL
On July 17, 2008 03:19:54 pm Tomas Vrabel wrote: Hi, I have sent this mail once before, tell me if it's offtopic or where should I ask about contributing to OpenSSL. I have developed library based on OpenSSL 0.9.8 that implemented ETSI standard for long term signatures. It allows electronic signatures to be valid for long period of time (many years) by adding timestamps as an unsigned attributes. I was thinking about adding my library to official OpenSSL library, OpenSSL version 0.9.9 will support CMS standard and it can be useful to create long-life signatures. Are you interested in my contribution? This question would probably be better answered if you post a link to your code, documentation on the code, and the license under which your code is written. You may also want to include what you mean when you say library based on OpenSSL - because there are LOTS of libraries based on OpenSSL (I've even written a couple :), and most of them don't necessarily make sense to include in OpenSSL itself (Pathfinder and WvStreams definitely do NOT make sense to include in OpenSSL, despite the first depending rather heavily on the native routines provided by OpenSSL) . Do you mean an extension to the OpenSSL libraries, so that 'openssl verify' can correctly validate long life signatures? If so, then probably the right thing to do is to create a patch to OpenSSL itself, and submit that via the RT system. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1695] RSA_padding_check_SSLv23 broken
[EMAIL PROTECTED] - Mi. 04. Jun. 2008, 08:08:00]:
We have addressed the following issue in Mac OS X:
RSA_padding_check_SSLv23 has a bug in the loop that verifies the
presence of eight consecutive 0x03 padding bytes just before the null
marker signifying the end of the padding. The problem is that at the
start of the for loop (for (k= -8; k0; k++)), p points at the byte
*after* the NULL terminator. The eight 0x03 bytes are actually from
p[-9] to p[-2] inclusive. The byte at p[-1] is the NULL. As a result,
if an SSLv2-only client is extraordinarily unlucky, an OpenSSL server
with SSLv2 enabled may erroneously detect a rollback attack. Well,
this could have happened anyway with a probability of 1 in 2^64, but
with this bug the probability was increased to 1 in 2^56.
Thank you very much for your report! I have just checked in the fix
into the OpenSSL CVS (i.e., it will be in the next snapshots, both for
the main development branch and the 0.9.8 stable branch).
Note that your proposed patch isn't quite right, though. The loop is
correct, but the error should still be raised in the case that k == -1,
meaning that p[-9] through p[-2] each had the value 0x03.
Bodo
diff -Naur /var/tmp/OpenSSL.roots/OpenSSL/openssl/crypto/rsa/
rsa_ssl.c ./crypto/rsa/rsa_ssl.c
--- /var/tmp/OpenSSL.roots/OpenSSL/openssl/crypto/rsa/rsa_ssl.c
2000-11-06 14:34:16.0 -0800
+++ ./crypto/rsa/rsa_ssl.c2006-10-11 16:40:48.0 -0700
@@ -130,11 +130,11 @@
RSAerr(RSA_F_RSA_PADDING_CHECK_SSLV23,RSA_R_NULL_BEFORE_BLOCK_MISSING);
return(-1);
}
- for (k= -8; k0; k++)
+ for (k= -9; k-1; k++)
{
if (p[k] != 0x03) break;
}
- if (k == -1)
+ if (k != -1)
{
RSAerr(RSA_F_RSA_PADDING_CHECK_SSLV23,RSA_R_SSLV3_ROLLBACK_ATTACK);
return(-1);
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
