SNAP-20070521: -DUSE_SSL needed for imit_gost_vizir
I have just started to compile SNAPs on linux-ppc (and soon linux-ppc64). Please let me know if it's not right to comment on SNAPs (...too easily overtaken by CVS..), if so, this will be my last report on SNAP. Anyway here goes: SNAP-20070521 on linux-ppc using ./config settings. [Problem 1] USE_SSL is never defined - this leads to imit_gost_vizir undeclared problem. gcc -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -c -o gost_pmeth.o gost_pmeth.c gost_pmeth.c: In function `pkey_gost_mac_ctrl': gost_pmeth.c:594: error: `imit_gost_vizir' undeclared (first use in this function) gost_pmeth.c:594: error: (Each undeclared identifier is reported only once gost_pmeth.c:594: error: for each function it appears in.) make[2]: *** [gost_pmeth.o] Error 1 Workaround: Manually declare -DUSE_SSL in Makefile CFLAG= works. [Problem 2] PPC assembler problem. Using less aggressive optimization (-O2 -g instead of -O3) get /usr/bin/perl asm/sha1-ppc.pl sha1-ppc_linux32.s gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -DTERMIO -O2 -g -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -c -o sha1-ppc_linux32.o sha1-ppc_linux32.s sha1-ppc_linux32.s: Assembler messages: sha1-ppc_linux32.s:1101: Error: unaligned opcodes detected in executable segment make[2]: *** [sha1-ppc_linux32.o] Error 1 Workaround: declare .rodata above .byte directive? stw 19,12(3) mr 10,19 stw 20,16(3) mr 11,20 addi4,4,64 bc 17,0,.Lsha1_block_private blr .rodata .byte 83,72,65,49,32,98,108,111,99,107,32,116,114,97,110,115,102,111,114,109,32,102,111,114,32,80, 80,67,44,32,67,82,89,80,84,79,71,65,77,83,32,98,121,32,60,97,112,112,114,111,64,102,121,46,99,104,97 ,108,109,101,114,115,46,115,101,62,0 gcc is 3.4.6 (on RHEL4 ppc64). Thanks Richard __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ECDSA verify fails when digest is all zeros in 0.9.8e
On Thu, May 17, 2007 at 08:43:47AM -0700, [EMAIL PROTECTED] wrote:
This is not a problem with the algorithm or the protocol. It is a
bug in the implementation. Digest values that are zero are allowed
by the ANSI X9.62 (and there is no special case for them) and they
work fine in other implementations.
[...]
compute_wNAF is at ec_mult.c:188.and is called with scalar pointing
to a zero BIGNUM. But compute_wNAF, either by design or by
accident, can't deal with a scalar that is zero.
Let's say that by accident compute_wNAF was designed such that it
cannot deal with a scalar that is zero: At least it will cleanly
signal an internal error in this special case rather than going
completely mad.
This clearly is a bug in crypto/ec/ec_mult.c; and here is a patch that
should fix it. (This will be in the next daily snapshots.)
--- crypto/ec/ec_mult.c 14 Mar 2006 22:48:31 - 1.32.2.1
+++ crypto/ec/ec_mult.c 22 May 2007 09:03:47 -
@@ -194,6 +194,19 @@
int bit, next_bit, mask;
size_t len = 0, j;
+ if (BN_is_zero(scalar))
+ {
+ r = OPENSSL_malloc(1);
+ if (!r)
+ {
+ ECerr(EC_F_COMPUTE_WNAF, ERR_R_MALLOC_FAILURE);
+ goto err;
+ }
+ r[0] = 0;
+ *ret_len = 1;
+ return r;
+ }
+
if (w = 0 || w 7) /* 'signed char' can represent integers with
absolute values less than 2^7 */
{
ECerr(EC_F_COMPUTE_WNAF, ERR_R_INTERNAL_ERROR);
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1521] bug report
- Original Message - From: Andy Polyakov via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Sunday, May 20, 2007 4:42 PM Subject: Re: [openssl.org #1521] bug report Title: Failed to link static openssl libraries (or non-PIC x86_64cpuid.s) OS: FC4 HARDWARE: AMD x86 64bit OPENSSL VERSION: 0.9.8e OPTIONS: CFLAGS=-fPIC -O2 ./config no-dso no-shared no-threads no-zlib -fPIC -O2 --prefix=/home/dmitri/php/install Details: It worked just fine with all 0.9.7*. Since 0.9.8 an attempt to link against static openssl like below gcc -shared dbg.lo dbg_bp.lo dbg_cmd.lo dbg_net.lo dbg_ser.lo dbg_prof.lo dbg_sec.lo bg_logo.lo -L/home/dmitri/php/install/lib -lssl -lcrypto -Wl,-rpath -Wl,/home/dmitri/php/install/lib -Wl,-soname -Wl,dbg.so -o .libs/dbg.so returns with error: /usr/bin/ld: /home/dmitri/php/install/lib/libcrypto.a(x86_64cpuid.o): relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' can not be used when making a shared object; recompile with -fPIC Use -Bsymbolic to link your shared object, add -Wl,-Bsymbolic to your gcc command line. In the nutshell this means that OpenSSL calls your library makes can't be overridden by another copy of OpenSSL mapped into application address space. Ideally you should also abstain from exporting any OpenSSL symbols from your shared object. One can argue whether or not this is a bug, as OPENSSL_cpuid_setup is an internal interface and another shared object should not be able to override it. Well, there is another way to resolve it, but not in the context of this ticket. I'm dismissing this. A. Hello Andy, Thanks for the feedback on the issue. And no, my library does not export anything that might raise any kind of conflicts with OPENSSL. Moreover, it works great under all other platforms, including FreeBSD 4.1/x86, Win32, Linux 2.4/x86, Mac OSX 10.4/powerpc. Seems that the problem happens under Linux2.6 (FC4)/64bit AMD or with gcc shipped with FC4. Also, I have some doubts. It all worked fine with openssl 0.9.7 under the same platform/ditro. Do you have an idea why it did not conflict and why it started conflicting with 0.9.8? I'll try to link my library with -Bsymbolic option soon. Thanks, Dmitri. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] OpenSSL vs GCC 4.2.0
Hi there, Having just downloaded GCC 4.2.0 and discovered that it can't build OpenSSL (not even in the snapshots AFAICT), I'd like to offer a possible solution. The earlier thread on openssl-dev explains that OpenSSL chooses to cast the function pointers, not the parameters, to achieve type-safety; i.e. to ensure that errors occur if the wrong types are passed to the XYZ_of() functions. So how about using expressions of the form (void*)(1 ? x : ((T*)NULL)) instead? That way, if x isn't of the right type, GCC will warn because the ?: gets different types in the two branches. Meanwhile the function itself is getting called with the correct types, and while OpenSSL is still deceiving the type system, it's doing so only via function pointers (so there's no way that the compiler, examining any one translation unit, can tell that deception is being attempted). And the compiler should easily spot that the condition (1) is always true, and so generate no extra code compared to the direct, non-typesafe call. Attached is a patch against SNAP-20070516 which lets all the tests pass under GCC 4.2.0 (on ia32 and amd64). Peter --- crypto/asn1/asn1.h~ 2007-04-14 19:00:19.0 +0100 +++ crypto/asn1/asn1.h 2007-05-16 14:48:27.0 +0100 @@ -329,6 +329,17 @@ typedef struct ASN1_VALUE_st ASN1_VALUE; #define I2D_OF(type) int (*)(type *,unsigned char **) #define I2D_OF_const(type) int (*)(const type *,unsigned char **) +#define CHECKED_D2I_OF(type, d2i) \ +((d2i_of_void*) (1 ? d2i : ((D2I_OF(type))0))) +#define CHECKED_I2D_OF(type, i2d) \ +((i2d_of_void*) (1 ? i2d : ((I2D_OF(type))0))) +#define CHECKED_NEW_OF(type, xnew) \ +((void *(*)(void)) (1 ? xnew : ((type *(*)(void))0))) +#define CHECKED_PTR_OF(type, p) \ +((void*) (1 ? p : (type*)0)) +#define CHECKED_PPTR_OF(type, p) \ +((void**) (1 ? p : (type**)0)) + #define TYPEDEF_D2I_OF(type) typedef type *d2i_of_##type(type **,const unsigned char **,long) #define TYPEDEF_I2D_OF(type) typedef int i2d_of_##type(type *,unsigned char **) #define TYPEDEF_D2I2D_OF(type) TYPEDEF_D2I_OF(type); TYPEDEF_I2D_OF(type) @@ -914,23 +925,41 @@ int ASN1_object_size(int constructed, in /* Used to implement other functions */ void *ASN1_dup(i2d_of_void *i2d, d2i_of_void *d2i, char *x); + #define ASN1_dup_of(type,i2d,d2i,x) \ - ((type *(*)(I2D_OF(type),D2I_OF(type),type *))openssl_fcast(ASN1_dup))(i2d,d2i,x) +((type*)ASN1_dup(CHECKED_I2D_OF(type, i2d), \ + CHECKED_D2I_OF(type, d2i), \ + CHECKED_PTR_OF(type, x))) + #define ASN1_dup_of_const(type,i2d,d2i,x) \ - ((type *(*)(I2D_OF_const(type),D2I_OF(type),type *))openssl_fcast(ASN1_dup))(i2d,d2i,x) +((type*)ASN1_dup(CHECKED_I2D_OF(const type, i2d), \ + CHECKED_D2I_OF(type, d2i), \ + CHECKED_PTR_OF(const type, x))) void *ASN1_item_dup(const ASN1_ITEM *it, void *x); #ifndef OPENSSL_NO_FP_API void *ASN1_d2i_fp(void *(*xnew)(void), d2i_of_void *d2i, FILE *in, void **x); + #define ASN1_d2i_fp_of(type,xnew,d2i,in,x) \ - ((type *(*)(type *(*)(void),D2I_OF(type),FILE *,type **))openssl_fcast(ASN1_d2i_fp))(xnew,d2i,in,x) +((type*)ASN1_d2i_fp(CHECKED_NEW_OF(type, xnew), \ + CHECKED_D2I_OF(type, d2i), \ + in, \ + CHECKED_PPTR_OF(type, x))) + void *ASN1_item_d2i_fp(const ASN1_ITEM *it, FILE *in, void *x); int ASN1_i2d_fp(i2d_of_void *i2d,FILE *out,void *x); + #define ASN1_i2d_fp_of(type,i2d,out,x) \ - ((int (*)(I2D_OF(type),FILE *,type *))openssl_fcast(ASN1_i2d_fp))(i2d,out,x) +(ASN1_i2d_fp(CHECKED_I2D_OF(type, i2d), \ + out, \ + CHECKED_PTR_OF(type, x))) + #define ASN1_i2d_fp_of_const(type,i2d,out,x) \ - ((int (*)(I2D_OF_const(type),FILE *,type *))openssl_fcast(ASN1_i2d_fp))(i2d,out,x) +(ASN1_i2d_fp(CHECKED_I2D_OF(const type, i2d), \ + out, \ + CHECKED_PTR_OF(const type, x))) + int ASN1_item_i2d_fp(const ASN1_ITEM *it, FILE *out, void *x); int ASN1_STRING_print_ex_fp(FILE *fp, ASN1_STRING *str, unsigned long flags); #endif @@ -939,14 +968,26 @@ int ASN1_STRING_to_UTF8(unsigned char ** #ifndef OPENSSL_NO_BIO void *ASN1_d2i_bio(void *(*xnew)(void), d2i_of_void *d2i, BIO *in, void **x); + #define ASN1_d2i_bio_of(type,xnew,d2i,in,x) \ - ((type *(*)(type *(*)(void),D2I_OF(type),BIO *,type **))openssl_fcast(ASN1_d2i_bio))(xnew,d2i,in,x) +((type*)ASN1_d2i_bio( CHECKED_NEW_OF(type, xnew), \ + CHECKED_D2I_OF(type, d2i), \ + in, \ + CHECKED_PPTR_OF(type, x))) + void *ASN1_item_d2i_bio(const ASN1_ITEM *it, BIO *in, void *x); int ASN1_i2d_bio(i2d_of_void *i2d,BIO *out, unsigned char *x); + #define ASN1_i2d_bio_of(type,i2d,out,x) \ - ((int (*)(I2D_OF(type),BIO *,type *))openssl_fcast(ASN1_i2d_bio))(i2d,out,x) +(ASN1_i2d_bio(CHECKED_I2D_OF(type, i2d), \ + out, \ + CHECKED_PTR_OF(type, x))) + #define ASN1_i2d_bio_of_const(type,i2d,out,x) \ - ((int (*)(I2D_OF_const(type),BIO *,const type *))openssl_fcast(ASN1_i2d_bio))(i2d,out,x) +(ASN1_i2d_bio(CHECKED_I2D_OF(const type, i2d), \ + out, \ +
Segfault inside RSA_eay_private_decrypt = BN_bn2bin
I have been having segfaults inside SSL when using the dovecot imap server, specifically within the imap-login process. It happens from within both 0.9.7a and 0.9.8e, but only with the Mac Mail client. The trace, when compiled with debug/efence, is: #0 BN_bn2bin at bn_lib.c:651 651 *(to++)=(unsigned char)(l(8*(i% BN_BYTES)))0xff; #1 RSA_eay_private_decrypt #2 RSA_private_decrypt #3 ssl3_get_client_key_exchange #4 ssl3_accept The relevant line inside RSA_eay_private_decrypt is: j=BN_bn2bin(ret,p); /* j is only used with no-padding mode */ The problem is that inside RSA_eay_private_decrypt BN_num_bytes(ret); has the value 254 whereas the buffer length: BN_num_bytes(rsa-n) has the value 128 (as does flen). I'm no expert on RSA but I assume that ret is read from the client and I suspect that Mail.app is sending invalid data. Should there not be a test for this condition and an intelligent response? If the buffer size is changed to the larger value will later routines be able to tell if the resulting data is valid? I obviously have the fear that other daemons are simply masking the problem in the classic buffer over-run way. I'm running 64-bit Scientific Linux 4.[34] (a RedHat Enterprise clone). I'm assuming that the fact that integers are 32 bits but pointers 64 is not the problem, despite the presence in bn_ctx.c of the statement: fprintf(stderr,(%08x): , (unsigned int)ctx); (!) Thanks for your help John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Format of X509 Certificate Validity
Hi, Hope someone can help me understand the validity date and time format of x509. For example, when connecting to https://401k.fidelity.com/, my IE shows it's cert validity is Valid from: August 30, 2006 5:00:00 PM Valid to:August 31, 2007 4:59:59 PM Ethereal shows the same fields of the x509 cert as: decoded notBefore: 0 6 0 8 3 1 0 0 0 0 0 0 Z (hex: 30 36 30 38 33 31 30 30 30 30 30 30 5A) decoded notAfter:0 7 0 8 3 1 2 3 5 9 5 9 Z (hex: 30 37 30 38 33 31 32 33 35 39 35 39 5A) It's staightfoward that 0 6 0 8 3 match 2006 08 3*, 0 7 0 8 3 match 2007 08 3*; 0 0 0 0 Z match 00:00, 5 9 5 9 Z match 59:59, but I found it's a bit confusing to decode the middle digits of notBefore and notAfter. Any hints? Rick _ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_2G_0507 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Format of X509 Certificate Validity
--On May 22, 2007 16:01:41 -0700 Richard Kao [EMAIL PROTECTED] wrote: Hope someone can help me understand the validity date and time format of x509. For example, when connecting to https://401k.fidelity.com/, my IE shows it's cert validity is Valid from: August 30, 2006 5:00:00 PM Valid to:August 31, 2007 4:59:59 PM Ethereal shows the same fields of the x509 cert as: decoded notBefore: 0 6 0 8 3 1 0 0 0 0 0 0 Z (hex: 30 36 30 38 33 31 30 30 30 30 30 30 5A) decoded notAfter:0 7 0 8 3 1 2 3 5 9 5 9 Z (hex: 30 37 30 38 33 31 32 33 35 39 35 39 5A) It's staightfoward that 0 6 0 8 3 match 2006 08 3*, 0 7 0 8 3 match 2007 08 3*; 0 0 0 0 Z match 00:00, 5 9 5 9 Z match 59:59, but I found it's a bit confusing to decode the middle digits of notBefore and notAfter. The format of universalTime (time format for certificate times before 2050) is YYMMDDHHMMSS followed by the time zone (Z means Zulu time (GMT)) IE translates that into the your local time. Bye Goetz -- DMCA: The greed of the few outweights the freedom of the many pgpan7AcUSGnr.pgp Description: PGP signature
Re: [PATCH] OpenSSL vs GCC 4.2.0
On Tue, May 22, 2007, Peter Hartley wrote: Hi there, Having just downloaded GCC 4.2.0 and discovered that it can't build OpenSSL (not even in the snapshots AFAICT), I'd like to offer a possible solution. The earlier thread on openssl-dev explains that OpenSSL chooses to cast the function pointers, not the parameters, to achieve type-safety; i.e. to ensure that errors occur if the wrong types are passed to the XYZ_of() functions. So how about using expressions of the form (void*)(1 ? x : ((T*)NULL)) instead? That way, if x isn't of the right type, GCC will warn because the ?: gets different types in the two branches. Meanwhile the function itself is getting called with the correct types, and while OpenSSL is still deceiving the type system, it's doing so only via function pointers (so there's no way that the compiler, examining any one translation unit, can tell that deception is being attempted). And the compiler should easily spot that the condition (1) is always true, and so generate no extra code compared to the direct, non-typesafe call. Attached is a patch against SNAP-20070516 which lets all the tests pass under GCC 4.2.0 (on ia32 and amd64). Well I'd started using inline functions which add a minimal extra overhead. That works in a lot of places but can get seriously messy in others. Would the compiler (or possibly other compilers) give out a warning that a test was always true? Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Format of X509 Certificate Validity
The Z suffix indicates GMT/UTC timezone. You are seeing them displayed in your timezone. -- STSM Senior Security Architect DataPower SOA Appliances __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
