Re: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0
Hello! On Mon, 4 Jul 2005, Andy Polyakov via RT wrote: Sorry, I've forgotten to mention I use 20050627 snapshot and ./config -g shared zlib works fine. Run ./config -t. Does it suggest any extra flags to ./Configure, such as 386? If it does, then I'd recommend to pass it down to ./Configure when latter is invoked manually. Thank you, it helps. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0
Hello! On Mon, 4 Jul 2005, Andy Polyakov via RT wrote: Sorry, I've forgotten to mention I use 20050627 snapshot and ./config -g shared zlib works fine. Run ./config -t. Does it suggest any extra flags to ./Configure, such as 386? If it does, then I'd recommend to pass it down to ./Configure when latter is invoked manually. Thank you, it helps. -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ 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/ Configure openssl/crypto...
Figured couple of clarification notes are due:-)
Added files: (Branch: OpenSSL_0_9_8-stable)
openssl/ms do_win64a.bat do_win64i.bat
Modified files: (Branch: OpenSSL_0_9_8-stable)
openssl Configure e_os.h
openssl/crypto cryptlib.c mem_dbg.c
openssl/utilmk1mf.pl
openssl/util/pl VC-32.pl
Log:
To secure Win64 API I'm throwing in this minimalistic Win64 support.
What does to secure API mean? This means to explicitly assign Win64
config options affecting binary compatibility, options which will be
supported through 0.9.8 and most likely future releases.
What does minimalistic mean? It means that no assembler modules were
engaged yet and [most importantly] following:
+if ($FLAVOR =~ /WIN64/)
+{
+# Note that we currently don't have /WX on Win64! There is a lot of
+# warnings, but only of two types:
+#
+# C4344: conversion from '__int64' to 'int/long', possible loss of data
+# C4267: conversion from 'size_t' to 'int/long', possible loss of data
+#
+# Amount of latter type is minimized by aliasing strlen to function of
+# own desing and limiting its return value to 2GB-1 (see e_os.h). As
+# per 0.9.8 release remaining warnings were explicitly examines and
+# considered safe to ignore.
+#
+$cflags=' /MD /W3 /Ox /Gs0 /GF /Gy /nologo -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DOPENSSL_SYSNAME_WIN32 -DOPENSSL_SYSNAME_WINNT -DUNICODE -D_UNICODE';
+$lflags=/nologo /subsystem:console /opt:ref;
+}
What does safe to ignore mean? It means that given the context of
every warning, no loss of data is actually taking place. At least it's
believed not to:-) This is based on visual code audit and the fact that
toolkit is known to work on a number of other 64-bit platforms, which
are subject to data loss exactly as much as Win64, but which compilers
are not as picky/fastidious as Microsoft ones. It was even tempting to
disable above mentioned warnings with /wd4355 and /wd4267, but for now
I've chosen to drop /WX instead. The question is what do we do about
these warnings in long run. Well, purify API:-) Does it mean that API
will change? Most likely. However!!! Fortunately such changes won't
necessarily have to break backward binary compatibility. Or in other
words application programs compiled with non-purified headers don't
have to break when linked with purified .DLL at run-time. Naturally
not vice-versa. Current Win64-specific API limitations comprise [but not
necessarily limited to]: null-terminated strings may not be longer than
2G-1 bytes, longer strings are treated as zero-length; dynamically and
*internally* allocated chunks can't be larger than 2G-1 bytes; inability
to encrypt/decrypt chunks of data larger than 2G-1 bytes [it's possibly
to *hash* chunks of arbitrary size through]. Neither of these are
actually big deal and hardly encountered in real-life applications... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Win 64a dynamic link library build was unsuccessful using beta6
So how to build on AMD 64 and Intel EM64T I summarize here: 1. perl Configure VC-WIN32 2. ms\do_ms 3. perl ms/uplink.pl win64a uptable.asm 4. ml64 -c uptable.asm 5. modify the mak files as above 6. nmake -f ms\ntdll.mak I hope it helps others out. As per today the above unsupported instructions have to be declared officially invalid. This is because if built according to above, the resulting .dll will be binary incompatible with one built according to newly introduced supported procedure: - perl Configure VC-WIN64A [or VC-WIN64I for Itanium]; - ms\do_win64a [or ms\do_win64i for Itanium]; - nmake -f ms/ntdll.mak; This applies to upcoming 0.9.8 and most likely future releases. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win 64a dynamic link library build was unsuccessful using beta6
Andy Polyakov writes: As per today the above unsupported instructions have to be declared officially invalid. This is because if built according to above, the resulting .dll will be binary incompatible with one built according to newly introduced supported procedure: - perl Configure VC-WIN64A [or VC-WIN64I for Itanium]; - ms\do_win64a [or ms\do_win64i for Itanium]; - nmake -f ms/ntdll.mak; This applies to upcoming 0.9.8 and most likely future releases. A. Hmm, I think it would be good to create a INSTALL.W64, or perhaps change INSTALL.W32 to INSTALL.Win and add 64-bit instructions in there. Are you willing to do that, or will that become my last task before I release 0.9.8? - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win 64a dynamic link library build was unsuccessful using beta6
As per today the above unsupported instructions have to be declared officially invalid. This is because if built according to above, the resulting .dll will be binary incompatible with one built according to newly introduced supported procedure: - perl Configure VC-WIN64A [or VC-WIN64I for Itanium]; - ms\do_win64a [or ms\do_win64i for Itanium]; - nmake -f ms/ntdll.mak; This applies to upcoming 0.9.8 and most likely future releases. A. Hmm, I think it would be good to create a INSTALL.W64, I'm writing one right now. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win 64a dynamic link library build was unsuccessful using beta6
Hi, newly introduced supported procedure: - perl Configure VC-WIN64A [or VC-WIN64I for Itanium]; - ms\do_win64a [or ms\do_win64i for Itanium]; - nmake -f ms/ntdll.mak; This applies to upcoming 0.9.8 and most likely future releases. A This is great news. Thank you for your great work. It will simplify the build of OpenSSL on Win64 platform. Thanks, -- Matyas Majzik __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Win 64a dynamic link library build was unsuccessful using beta6
Andy Polyakov writes: Hmm, I think it would be good to create a INSTALL.W64, I'm writing one right now. A. Great! Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
critical,CA:FALSE but Any Purpose CA : Yes ?
When creating a certificate using an openssl CA, I specify the x509v3 extension basicConstraints = critical,CA:FALSE. Looking at the generated certificate using % openssl x509 -noout -text -purpose -in nonca.pem ... X509v3 Basic Constraints: critical CA:FALSE ... Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : No CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes == OCSP helper : Yes OCSP helper CA : No How can this be, CA usage is critically forbidden, yet the CA usage for Any Purpose is possible ??? Is this an openssl problem, or a misunderstanding on my side? Irritated, Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PPC bn_div_words routine rewrite
Let's start the week off with less hostility and more productive criticism on this topic. If you want productivity, then provide real evidence in form of stack backtrace at segmentation violation point, disassemble output in the vicinity of segmentation violation point and 'info registers' output at the same point. As for hostility I leave it without comment, as you're apparently can outrank anybody in that area:-) But you're apparently right about a bug being present in PPC assembler. So you are saying there is a bug in the GCC assembler? How confident are you in that? Is the first correct step to examine the assembly code for errors before jumping to any conclusion that the GCC assembler is bad? Did I say GCC assembler? I said PPC assembler, which refers to crypto/bn/asm/ppc.pl. This is a rewrite of the bn_div_words routine for the PowerPC arch, tested on a MPC8xx processor. Well, suggested routine apparently sends ssh-keygen on the PPC-based 32-bit system I have access to to an end-less loop... If you care to read the c function I supplied or if you don't believe it: If you understand ppc 32-bit instructions, as specified in the PowerPC Microprocessor Family: Programming Environments for 32-Bit Microprocessors. My routine would not be able to find a condition that will make it go into an end-less loop,unless you messed up bad somewhere. I didn't say that suggested routine goes into an end-less loop, but that it *apparently* sends ssh-keygen into end-less loop. I made no claims about which routine exactly loops, and I even admit that I don't know for sure if it was in fact end-less loop, because I've chosen to kill the process after couple of minutes. Note that normally it takes just few seconds on the machine I've tested on, so that couple of minutes is essentially unacceptable and by all means *appears* as end-less loop. In summary, what I am trying to provide the community is an alternative to ... the current implementation of which is very questionable. crypto/bn/asm/ppc.pl distributed with OpenSSL was designed for and explicitly tested by IBM under 32- and 64-bit PPC Linux, 32- and 64-bit AIX, as well as 32-bit MacOS X. Special care was taken to make sure that neither of ABIs/calling conventions used by above listed platforms are violated, so that module can be safely invoked by compiler-generated code for above mentioned OSes. Afterwards there were reports that it was successfully used on unspecified [in report] embedded PPC-based platform. Despite this on Friday I could personally confirm on 32-bit MacOS X that there admittedly was a bug in ppc.pl, which manifests as failure to generate sane decimal ASCII presentation of a BIGNUM, which is exactly the kind of operation taking place when you run ssh-keygen -t rsa1 [it should be noted decimal ASCII is unfortunately not covered by 'make test_bn' suite]. But under no circumstances segmentation violation was observed. At the same time I could personally confirm that if pasted into osx32_ppc.s, suggested implementation induces 'make test_bn' failure on 32-bit MacOS X. In particular test/bntest terminates with print test BN_sqr\n -FF554CAEAE * -FF554CAEAE - FEAB0B30019BBA80FE44 Square test failed! 1 while test/exptest: BN_mod_exp_recp() problems 14482:error:03082065:bignum routines:BN_div_recp:bad reciprocal:bn_recp.c:194: For me it's enough reasons to become sceptical to submission and conduct trouble-shooting of my own. Currently available ppc.pl was verified to pass 'make test_bn' on 32-bit MacOS X, 32- and 64-bit AIX [tested by IBM], as well as to generate correct decimal ASCII presentation on the mentioned platforms. If it doesn't work for you, then submit information listed in the beginning of the letter. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: critical,CA:FALSE but Any Purpose CA : Yes ?
On Tue, Jul 05, 2005, Martin Kraemer wrote: When creating a certificate using an openssl CA, I specify the x509v3 extension basicConstraints = critical,CA:FALSE. Looking at the generated certificate using % openssl x509 -noout -text -purpose -in nonca.pem ... X509v3 Basic Constraints: critical CA:FALSE ... Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : No CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes == OCSP helper : Yes OCSP helper CA : No How can this be, CA usage is critically forbidden, yet the CA usage for Any Purpose is possible ??? Is this an openssl problem, or a misunderstanding on my side? The Any Purpose setting is something which lets anything through and performs no checks at all. It was put there originally as a way for people to use broken certificates if they had no other choice and could live with the consequences. This setting has to be explicitly requested in code: meaning it can't be accidentally set. Since then CA checks have been made mandatory in the code even if Any Purpose is set. So if you actually tried to use that certificate as a CA it would be rejected. 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: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0
Sorry, I've forgotten to mention I use 20050627 snapshot and ./config -g shared zlib works fine. Run ./config -t. Does it suggest any extra flags to ./Configure, such as 386? If it does, then I'd recommend to pass it down to ./Configure when latter is invoked manually. Thank you, it helps. Yet I find it a bit too puzzling... After I've replied I came to realize that no-sse2/386 shouldn't actually affect the referred test procedure... Indeed, even though there're SSE2 instructions present in bn_mul_add_words, they operate on mmx registers and therefore don't actually require kernel support. Kernel support required for SSE2 instructions operating on 128-bit xmm registers, but not on 64-bit mmx ones, and therefore if CPUID said SSE2 is available, then bn_mul_add_words should have worked... So if you can have time I'd still appreciate if you could collect and send over disassemble output in the vicinity of segmentation fault, as well as info registers... Once again, this is optional. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl verify returning both error and OK?
When testing a certificate for its allowed purposes, I found:
$ for purpose in sslclient sslserver nssslserver smimesign smimeencrypt crlsign
any ocsphelper
do
echo -n ${purpose}:
openssl-0.9.8 verify -verbose -CAfile ca_chain.txt -purpose $purpose my.pem
done
sslclient:my.pem: OK
sslserver:my.pem: OK
nssslserver:my.pem: OK
smimesign:my.pem: OK
smimeencrypt:my.pem: OK
crlsign:my.pem: /C=GB/O=Defer Test/OU=basic/CN=Martin Kraemer/[EMAIL PROTECTED]
error 26 at 0 depth lookup:unsupported certificate purpose
OK
any:my.pem: OK
ocsphelper:my.pem: OK
For the case of the crlsign purpose, shouldn't openssl die with
a non-OK error, instead of printing an error, but finally OK?
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Fwd: PPC bn_div_words routine rewrite
This is the second confirmed report of the same problem on the ppc8xx.
After reading my email. I must say I was the unfriendly one, I
apologize for that.
More debugging evidence to come.
-- Forwarded message --
From: Murch, Christopher [EMAIL PROTECTED]
Date: Jul 1, 2005 9:46 AM
Subject: RE: PPC bn_div_words routine rewrite
To: David Ho [EMAIL PROTECTED]
David,
I had observed the same issue on ppc 8xx machines after upgrading to the asm
version of the BN routines. Thank you very much for your work for the fix.
My question is, do you have high confidence in the other new asm ppc BN
routines after observing this issue or do you think they might have similiar
problems?
Thanks.
Chris
-Original Message-
From: David Ho [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 6:22 PM
To: openssl-dev@openssl.org; [EMAIL PROTECTED]
Subject: Re: PPC bn_div_words routine rewrite
The reason I had to redo this routine, in case anyone is wondering, is
because ssh-keygen segfaults when this assembly routine returns junk
to the BN_div_word function. On a ppc, if you issue the command
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N
The program craps out when it tries to write the public key in ascii
decimal.
Regards,
David
On 6/30/05, David Ho [EMAIL PROTECTED] wrote:
Hi all,
This is a rewrite of the bn_div_words routine for the PowerPC arch,
tested on a MPC8xx processor.
I initially thought there is maybe a small mistake in the code that
requires a one-liner change but it turns out I have to redo the
routine.
I guess this routine is not called very often as I see that most other
routines are hand-crafted, whereas this routine is compiled from a C
function that apparently has not gone through a whole lot of testing.
I wrote a C function to confirm correctness of the code.
unsigned long div_words (unsigned long h,
unsigned long l,
unsigned long d)
{
unsigned long i_h; /* intermediate dividend */
unsigned long i_q; /* quotient of i_h/d */
unsigned long i_r; /* remainder of i_h/d */
unsigned long i_cntr;
unsigned long i_carry;
unsigned long ret_q; /* return quotient */
/* cannot divide by zero */
if (d == 0) return 0x;
/* do simple 32-bit divide */
if (h == 0) return l/d;
i_q = h/d;
i_r = h - (i_q*d);
ret_q = i_q;
i_cntr = 32;
while (i_cntr--)
{
i_carry = (l 0x8000) ? 1:0;
l = l 1;
i_h = (i_r 1) | i_carry;
i_q = i_h/d;
i_r = i_h - (i_q*d);
ret_q = (ret_q 1) | i_q;
}
return ret_q;
}
Then I handcrafted the routine in PPC assembly.
The result is a 26 line assembly that is easy to understand and
predictable as opposed to a 81liner that I am still trying to
decipher...
If anyone is interested in incorporating this routine to the openssl
code I'll be happy to assist.
At this point I think I will be taking a bit of a break from this 3
day debugging/fixing marathon.
Regards,
David Ho
#
# Handcrafted version of bn_div_words
#
# r3 = h
# r4 = l
# r5 = d
cmplwi 0,r5,0 # compare r5 and 0
bc BO_IF_NOT,CR0_EQ,.Lppcasm_div1 # proceed if d!=0
li r3,-1 # d=0 return -1
bclrBO_ALWAYS,CR0_LT
.Lppcasm_div1:
cmplwi 0,r3,0 # compare r3 and 0
bc BO_IF_NOT,CR0_EQ,.Lppcasm_div2 # proceed if h != 0
divwu r3,r4,r5# ret_q = l/d
bclrBO_ALWAYS,CR0_LT# return result in r3
.Lppcasm_div2:
divwu r9,r3,r5# i_q = h/d
mullw r10,r9,r5 # i_r = h - (i_q*d)
subfr10,r10,r3
mr r3,r9 # req_q = i_q
.Lppcasm_set_ctr:
li r12,32 # ctr = bitsizeof(d)
mtctr r12
.Lppcasm_div_loop:
addcr4,r4,r4# l = l 1 - i_carry
adder11,r10,r10 # i_h = (i_r 1) | i_carry
divwu r9,r11,r5 # i_q = i_h/d
mullw r10,r9,r5 # i_r = i_h - (i_q*d)
subfr10,r10,r11
add r3,r3,r3# ret_q = ret_q 1 | i_q
add r3,r3,r9
bc BO_dCTR_NZERO,CR0_EQ,.Lppcasm_div_loop
.Lppc_div_end:
bclrBO_ALWAYS,CR0_LT# return result in r3
.long 0x
___
Linuxppc-embedded mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: critical,CA:FALSE but Any Purpose CA : Yes ?
Since then CA checks have been made mandatory in the code even if Any Purpose is set. So if you actually tried to use that certificate as a CA it would be rejected. If that is so, then how can the following happen (with a recent openssl-dev): % openssl version -a OpenSSL 0.9.9-dev XX xxx built on: Wed Jun 29 12:31:27 CEST 2005 platform: BSD-x86-elf options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM OPENSSLDIR: /usr/local/ssl % openssl x509 -in [EMAIL PROTECTED] -noout -text -purpose Certificate: Data: Version: 3 (0x2) Serial Number: c0:ed:2a:bc:67:03:2a:69:c3:46:23:49:dd:a8:c3:a0 Signature Algorithm: sha1WithRSAEncryption Issuer: C=XY, O=BTG Development CA (3), OU=Basic CA, CN=David Deer/[EMAIL PROTECTED] Validity Not Before: Jul 5 11:05:50 2005 GMT Not After : Jul 7 11:05:50 2005 GMT Subject: C=XY, O=BTG Development CA (3), OU=Basic CA, CN=Martin Kraemer/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:...:29 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C4:40:46:89:F2:60:86:3A:23:80:CF:46:E2:B5:B4:48:BA:44:94:0F X509v3 Authority Key Identifier: keyid:23:B4:0C:4C:FA:26:E3:76:3B:02:7F:DC:CC:8D:24:D7:48:8C:95:E7 DirName:/C=XY/O=BTG Development CA (3)/CN=David Deer/[EMAIL PROTECTED] serial:C4:A5:4C:5D:BB:C3:89:C7:F8:8B:94:49:D8:C1:E2:0C X509v3 Subject Alternative Name: email:[EMAIL PROTECTED] X509v3 Issuer Alternative Name: email:[EMAIL PROTECTED] X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Key Agreement X509v3 CRL Distribution Points: URI:http://ca.example.com/ca/3/basic_C4A54C5DBBC389C7F88B9449D8C1E20C.crl Netscape CA Revocation Url: http://ca.example.com/ca/3/basic_C4A54C5DBBC389C7F88B9449D8C1E20C.crl Netscape Comment: created by BaDCA 1.3.6.1.4.1.18060.101.1: committer Signature Algorithm: sha1WithRSAEncryption 37:...:9a Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : No CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes OCSP helper : Yes OCSP helper CA : No % openssl ca -config openssl.cnf -cert [EMAIL PROTECTED] -keyfile [EMAIL PROTECTED] -verbose -in [EMAIL PROTECTED] Using configuration from openssl.cnf Enter pass phrase for [EMAIL PROTECTED]: ... 9 entries loaded from the database generating index message digest is md5 policy is policy_match next serial number is 0123456789ABCDEF0123456789ABCDF5 Certificate Request: Data: Version: 0 (0x0) Subject: CN=Martin Kraemer/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:...:29 Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: md5WithRSAEncryption 53:...:60 Check that the request matches the signature Signature ok The subject name appears to be ok, checking data base for clashes Everything appears to be ok, creating and signing the certificate Successfully added extensions from config Certificate Details: Serial Number: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:f5 Validity Not Before: Jul 5 15:33:22 2005 GMT Not After : Jul 5 15:33:22 2006 GMT Subject: commonName= Martin Kraemer emailAddress = [EMAIL PROTECTED] X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: C4:40:46:89:F2:60:86:3A:23:80:CF:46:E2:B5:B4:48:BA:44:94:0F X509v3 Authority Key Identifier: keyid:C4:40:46:89:F2:60:86:3A:23:80:CF:46:E2:B5:B4:48:BA:44:94:0F DirName:/C=XY/O=BTG Development CA (3)/OU=Basic CA/CN=David Deer/[EMAIL PROTECTED]
Re: critical,CA:FALSE but Any Purpose CA : Yes ?
On Tue, Jul 05, 2005 at 05:45:09PM +0200, Martin Kraemer wrote: If that is so, then how can the following happen (with a recent openssl-dev): Oops - it can because here, the critical flag is missing. Sorry. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl verify returning both error and OK?
On Tue, Jul 05, 2005, Martin Kraemer wrote:
When testing a certificate for its allowed purposes, I found:
$ for purpose in sslclient sslserver nssslserver smimesign smimeencrypt
crlsign any ocsphelper
do
echo -n ${purpose}:
openssl-0.9.8 verify -verbose -CAfile ca_chain.txt -purpose $purpose
my.pem
done
sslclient:my.pem: OK
sslserver:my.pem: OK
nssslserver:my.pem: OK
smimesign:my.pem: OK
smimeencrypt:my.pem: OK
crlsign:my.pem: /C=GB/O=Defer Test/OU=basic/CN=Martin Kraemer/[EMAIL
PROTECTED]
error 26 at 0 depth lookup:unsupported certificate purpose
OK
any:my.pem: OK
ocsphelper:my.pem: OK
For the case of the crlsign purpose, shouldn't openssl die with
a non-OK error, instead of printing an error, but finally OK?
The 'verify' utility includes a callback which, after printing out the code
overrides all errors.
This is for debugging purposes so that all the errors a certficate chain would
produce can be printed out rather than halting on the first one.
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: critical,CA:FALSE but Any Purpose CA : Yes ?
On Tue, Jul 05, 2005, Martin Kraemer wrote: Since then CA checks have been made mandatory in the code even if Any Purpose is set. So if you actually tried to use that certificate as a CA it would be rejected. If that is so, then how can the following happen (with a recent openssl-dev): [example of ca utility] The 'ca' utility doesn't currently check the validity of the CA certificate it is signing with. So it will happily sign with an invalid CA but the verification routines will reject it. 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: PPC bn_div_words routine rewrite
First pass debugging results from gdb on ppc8xx. Executing ssh-keygen
with following arguments.
(gdb) show args
Argument list to give program being debugged when it is started is
-t rsa1 -f /etc/ssh/ssh_host_key -N .
Program received signal SIGSEGV, Segmentation fault.
BN_bn2dec (a=0x1002d9f0) at bn_print.c:136
136 *lp=BN_div_word(t,BN_DEC_CONV);
(gdb) i r
r0 0x0 0
r1 0x7fffd580 2147472768
r2 0x30012868 805382248
r3 0x8000 2147483648
r4 0xfef33fc267334652
r5 0x25 37
r6 0xfccdef8265084664
r7 0x7fffd4c0 2147472576
r8 0xfbad2887 4222429319
r9 0x84044022 2214871074
r100x0 0
r110x2 2
r120xfef2054267329620
r130x10030bc8 268635080
r140x0 0
r150x0 0
r160x0 0
r170x0 0
r180x0 0
r190x0 0
r200x0 0
r210x0 0
r220x0 0
r230x64 100
r240x5 5
r250x1002d438 268620856
r260x1002d9f0 268622320
r270x1002c578 268617080
r280x1 1
r290x10031000 268636160
r300xffbf7d0268171216
r310x1002d9f0 268622320
pc 0xfef2058267329624
ps 0xd032 53298
cr 0x24044022 604258338
lr 0xfef2054267329620
ctr0xfccefa0265088928
xer0x2000 536870912
fpscr 0x0 0
vscr 0x0 0
vrsave 0x0 0
(gdb) p/x $pc
$1 = 0xfef2058
0x0fef2058 BN_bn2dec+472: stw r3,0(r29)
(gdb) x 0x10031000
0x10031000: Cannot access memory at address 0x10031000
On 7/5/05, David Ho [EMAIL PROTECTED] wrote:
This is the second confirmed report of the same problem on the ppc8xx.
After reading my email. I must say I was the unfriendly one, I
apologize for that.
More debugging evidence to come.
-- Forwarded message --
From: Murch, Christopher [EMAIL PROTECTED]
Date: Jul 1, 2005 9:46 AM
Subject: RE: PPC bn_div_words routine rewrite
To: David Ho [EMAIL PROTECTED]
David,
I had observed the same issue on ppc 8xx machines after upgrading to the asm
version of the BN routines. Thank you very much for your work for the fix.
My question is, do you have high confidence in the other new asm ppc BN
routines after observing this issue or do you think they might have similiar
problems?
Thanks.
Chris
-Original Message-
From: David Ho [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 6:22 PM
To: openssl-dev@openssl.org; [EMAIL PROTECTED]
Subject: Re: PPC bn_div_words routine rewrite
The reason I had to redo this routine, in case anyone is wondering, is
because ssh-keygen segfaults when this assembly routine returns junk
to the BN_div_word function. On a ppc, if you issue the command
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N
The program craps out when it tries to write the public key in ascii
decimal.
Regards,
David
On 6/30/05, David Ho [EMAIL PROTECTED] wrote:
Hi all,
This is a rewrite of the bn_div_words routine for the PowerPC arch,
tested on a MPC8xx processor.
I initially thought there is maybe a small mistake in the code that
requires a one-liner change but it turns out I have to redo the
routine.
I guess this routine is not called very often as I see that most other
routines are hand-crafted, whereas this routine is compiled from a C
function that apparently has not gone through a whole lot of testing.
I wrote a C function to confirm correctness of the code.
unsigned long div_words (unsigned long h,
unsigned long l,
unsigned long d)
{
unsigned long i_h; /* intermediate dividend */
unsigned long i_q; /* quotient of i_h/d */
unsigned long i_r; /* remainder of i_h/d */
unsigned long i_cntr;
unsigned long i_carry;
unsigned long ret_q; /* return quotient */
/* cannot divide by zero */
if (d == 0) return 0x;
/* do simple 32-bit divide */
if (h == 0) return l/d;
i_q = h/d;
i_r = h - (i_q*d);
ret_q = i_q;
i_cntr = 32;
while (i_cntr--)
{
i_carry = (l 0x8000) ? 1:0;
l = l 1;
i_h = (i_r 1) | i_carry;
i_q = i_h/d;
i_r = i_h - (i_q*d);
ret_q = (ret_q 1) | i_q;
}
return ret_q;
}
Then I handcrafted the routine in PPC assembly.
The result is a 26 line assembly that is easy to understand and
predictable as opposed to a 81liner that I am still trying to
decipher...
If anyone is interested in incorporating this routine to the
Re: PPC bn_div_words routine rewrite
I can tell you with certainty, with reference to the function
BN_bn2dec, that since lp is a pointer, and within the while loop
around bn_print.c:136 lp is being incremented. Because the test
BN_is_zero(t) is always false, you have a pointer that is going off
into the stratosphere, hence the segfault on ppc8xx.
More analysis to come.
On 7/5/05, David Ho [EMAIL PROTECTED] wrote:
First pass debugging results from gdb on ppc8xx. Executing ssh-keygen
with following arguments.
(gdb) show args
Argument list to give program being debugged when it is started is
-t rsa1 -f /etc/ssh/ssh_host_key -N .
Program received signal SIGSEGV, Segmentation fault.
BN_bn2dec (a=0x1002d9f0) at bn_print.c:136
136 *lp=BN_div_word(t,BN_DEC_CONV);
(gdb) i r
r0 0x0 0
r1 0x7fffd580 2147472768
r2 0x30012868 805382248
r3 0x8000 2147483648
r4 0xfef33fc267334652
r5 0x25 37
r6 0xfccdef8265084664
r7 0x7fffd4c0 2147472576
r8 0xfbad2887 4222429319
r9 0x84044022 2214871074
r100x0 0
r110x2 2
r120xfef2054267329620
r130x10030bc8 268635080
r140x0 0
r150x0 0
r160x0 0
r170x0 0
r180x0 0
r190x0 0
r200x0 0
r210x0 0
r220x0 0
r230x64 100
r240x5 5
r250x1002d438 268620856
r260x1002d9f0 268622320
r270x1002c578 268617080
r280x1 1
r290x10031000 268636160
r300xffbf7d0268171216
r310x1002d9f0 268622320
pc 0xfef2058267329624
ps 0xd032 53298
cr 0x24044022 604258338
lr 0xfef2054267329620
ctr0xfccefa0265088928
xer0x2000 536870912
fpscr 0x0 0
vscr 0x0 0
vrsave 0x0 0
(gdb) p/x $pc
$1 = 0xfef2058
0x0fef2058 BN_bn2dec+472: stw r3,0(r29)
(gdb) x 0x10031000
0x10031000: Cannot access memory at address 0x10031000
On 7/5/05, David Ho [EMAIL PROTECTED] wrote:
This is the second confirmed report of the same problem on the ppc8xx.
After reading my email. I must say I was the unfriendly one, I
apologize for that.
More debugging evidence to come.
-- Forwarded message --
From: Murch, Christopher [EMAIL PROTECTED]
Date: Jul 1, 2005 9:46 AM
Subject: RE: PPC bn_div_words routine rewrite
To: David Ho [EMAIL PROTECTED]
David,
I had observed the same issue on ppc 8xx machines after upgrading to the asm
version of the BN routines. Thank you very much for your work for the fix.
My question is, do you have high confidence in the other new asm ppc BN
routines after observing this issue or do you think they might have similiar
problems?
Thanks.
Chris
-Original Message-
From: David Ho [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 6:22 PM
To: openssl-dev@openssl.org; [EMAIL PROTECTED]
Subject: Re: PPC bn_div_words routine rewrite
The reason I had to redo this routine, in case anyone is wondering, is
because ssh-keygen segfaults when this assembly routine returns junk
to the BN_div_word function. On a ppc, if you issue the command
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N
The program craps out when it tries to write the public key in ascii
decimal.
Regards,
David
On 6/30/05, David Ho [EMAIL PROTECTED] wrote:
Hi all,
This is a rewrite of the bn_div_words routine for the PowerPC arch,
tested on a MPC8xx processor.
I initially thought there is maybe a small mistake in the code that
requires a one-liner change but it turns out I have to redo the
routine.
I guess this routine is not called very often as I see that most other
routines are hand-crafted, whereas this routine is compiled from a C
function that apparently has not gone through a whole lot of testing.
I wrote a C function to confirm correctness of the code.
unsigned long div_words (unsigned long h,
unsigned long l,
unsigned long d)
{
unsigned long i_h; /* intermediate dividend */
unsigned long i_q; /* quotient of i_h/d */
unsigned long i_r; /* remainder of i_h/d */
unsigned long i_cntr;
unsigned long i_carry;
unsigned long ret_q; /* return quotient */
/* cannot divide by zero */
if (d == 0) return 0x;
/* do simple 32-bit divide */
if (h == 0) return l/d;
i_q = h/d;
i_r = h - (i_q*d);
0.9.8 beta6 on Mandriva Cooker amd64
Hello.
I get these errors running the tests on Mandriva Linux Cooker, amd64:
$ make test_ec
[...]
testing internal curves: .
EC_GROUP_check() failed with curve secp224r1
.
EC_GROUP_check() failed with curve secp384r1
...
EC_GROUP_check() failed with curve prime256v1
EC_GROUP_check() failed with curve wap-wsg-idm-ecid-wtls12
.. failed
$ make test_ecdsa
test ecdsa
../util/shlib_wrap.sh ./ecdsatest
some tests from X9.62:
testing prime192v1: ok
testing prime239v1: ok
testing c2tnb191v1: ok
testing c2tnb239v1: ok
testing ECDSA_sign() and ECDSA_verify() with some internal curves:
secp160k1: ... ok
secp160r1: ... ok
secp160r2: ... ok
secp192k1: ... ok
secp224k1: ... ok
secp224r1: failed
ECDSA test failed
make: *** [test_ecdsa] Error 1
$ make test_ecdh
test ecdh
../util/shlib_wrap.sh ./ecdhtest
Testing key generation with NIST Prime-Curve P-192 ok
Testing key generation with NIST Prime-Curve P-224make: *** [test_ecdh] Error
1
System info:
Linux kernel 2.6.11
glibc-2.3.4
gcc-3.4.3
All tests passes on i586 and gcc-4.0.1
Additionally I attach one patch by Andreas Hasenack
andreas[at]mandriva[dot]com that is used by the Brazilian government that I
kindly hope you will accept upstream.
--
Regards // Oden Eriksson
Mandriva: http://www.mandriva.com
NUX: http://nux.se
--- crypto/x509v3/v3_alt.c 2005-05-11 05:45:36.0 +0200
+++ crypto/x509v3/v3_alt.c.oden 2005-07-05 15:13:32.285682900 +0200
@@ -102,11 +102,55 @@
{
unsigned char *p;
char oline[256], htmp[5];
+
+ int rc = 0;
+
+ /* see http://www.iti.gov.br/resolucoes/RESOLU__O_13_DE_26_04_2002.PDF
+ * for the OID definitions and more details
+ * All content is ASN.1 OCTET STRING
+ */
+ /* person related */
+ const char oid_id_pf[] = 2.16.76.1.3.1; /* person identification data as follows:
+ * birth date: ddmm (8)
+ * CPF number: (11)
+ * PIS/PASEP number: (11)
+ * RG number: (11)
+ * RG emmitter and state: (6)
+ */
+ const char oid_el_pf[] = 2.16.76.1.3.5; /* Electoral data:
+ * card number: (11)
+ * electoral zone: (3)
+ * electoral section: (4)
+ * city and state: (22)
+ */
+ /* company related */
+ const char oid_pj_id1[] = 2.16.76.1.3.4; /* info about the person responsible for the company's certificate:
+ * birth date: ddmm (8)
+ * CPF number: (11)
+ * PIS/PASEP number: (11)
+ * RG number: (11)
+ * RG emitter and state: (6)
+ */
+ const char oid_pj_name[] = 2.16.76.1.3.2; /* Name of the person responsible for the company's certificate */
+ const char oid_pj_cnpj[] = 2.16.76.1.3.3; /* CNPJ number of the company*/
+
int i;
switch (gen-type)
{
case GEN_OTHERNAME:
- X509V3_add_value(othername,unsupported, ret);
+ rc = OBJ_obj2txt(oline, sizeof(oline), gen-d.otherName-type_id, 1);
+ if (rc)
+ if ((!strncmp(oline, oid_id_pf, sizeof(oid_id_pf))) ||
+ (!strncmp(oline, oid_el_pf, sizeof(oid_el_pf))) ||
+ (!strncmp(oline, oid_pj_id1, sizeof(oid_pj_id1))) ||
+ (!strncmp(oline, oid_pj_name, sizeof(oid_pj_name))) ||
+ (!strncmp(oline, oid_pj_cnpj, sizeof(oid_pj_cnpj
+/* FIXME: is that string always null terminated? */
+X509V3_add_value(othername, gen-d.otherName-value-value.octet_string-data, ret);
+ else
+X509V3_add_value(othername,unsupported, ret);
+ else
+ X509V3_add_value(othername,unsupported, ret);
break;
case GEN_X400:
Here goes...
I'm starting the release of 0.9.8. Hold ye' horses. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[ANNOUNCE] OpenSSL 0.9.8 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8 released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.7x. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES . The most significant changes are: o Major work on the BIGNUM library for higher efficiency and to make operations more streamlined and less contradictory. This is the result of a major audit of the BIGNUM library. o Addition of BIGNUM functions for fields GF(2^m) and NIST curves, to support the Elliptic Crypto functions. o Major work on Elliptic Crypto; ECDH and ECDSA added, including the use through EVP, X509 and ENGINE. o New ASN.1 mini-compiler that's usable through the OpenSSL configuration file. o Added support for ASN.1 indefinite length constructed encoding. o New PKCS#12 'medium level' API to manipulate PKCS#12 files. o Complete rework of shared library construction and linking programs with shared or static libraries, through a separate Makefile.shared. o Rework of the passing of parameters from one Makefile to another. o Changed ENGINE framework to load dynamic engine modules automatically from specifically given directories. o New structure and ASN.1 functions for CertificatePair. o Changed the ZLIB compression method to be stateful. o Changed the key-generation and primality testing progress mechanism to take a structure that contains the ticker function and an argument. o New engine module: GMP (performs private key exponentiation). o New engine module: VIA PadLOck ACE extension in VIA C3 Nehemiah processors. o Added support for IPv6 addresses in certificate extensions. See RFC 1884, section 2.2. o Added support for certificate policy mappings, policy constraints and name constraints. o Added support for multi-valued AVAs in the OpenSSL configuration file. o Added support for multiple certificates with the same subject in the 'openssl ca' index file. o Make it possible to create self-signed certificates using 'openssl ca -selfsign'. o Make it possible to generate a serial number file with 'openssl ca -create_serial'. o New binary search functions with extended functionality. o New BUF functions. o New STORE structure and library to provide an interface to all sorts of data repositories. Supports storage of public and private keys, certificates, CRLs, numbers and arbitrary blobs. This library is unfortunately unfinished and unused withing OpenSSL. o New control functions for the error stack. o Changed the PKCS#7 library to support one-pass S/MIME processing. o Added the possibility to compile without old deprecated functionality with the OPENSSL_NO_DEPRECATED macro or the 'no-deprecated' argument to the config and Configure scripts. o Constification of all ASN.1 conversion functions, and other affected functions. o Improved platform support for PowerPC. o New FIPS 180-2 algorithms (SHA-224, -256, -384 and -512). o New X509_VERIFY_PARAM structure to support parametrisation of X.509 path validation. o Major overhaul of RC4 performance on Intel P4, IA-64 and AMD64. o Changed the Configure script to have some algorithms disabled by default. Those can be explicitely enabled with the new argument form 'enable-xxx'. o Change the default digest in 'openssl' commands from MD5 to SHA-1. o Added support for DTLS. o New BIGNUM blinding. o Added support for the RSA-PSS encryption scheme o Added support for the RSA X.931 padding. o Added support for BSD sockets on NetWare. o Added support for files larger than 2GB. o Added initial support for Win64. o Added alternate pkg-config files. We consider OpenSSL 0.9.8 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8.tar.gz MD5 checksum: 9da21071596a124acde6080552deac16 SHA1 checksum: 7350b0f0d1a6d257cb24b9d4dc5e30b80e49d6ac The checksums were calculated using the following command: openssl md5 openssl-0.9.8.tar.gz openssl sha1 openssl-0.9.8.tar.gz Yours, The OpenSSL
Re: PPC bn_div_words routine rewrite
Let's take first call to BN_div_word for example from BN_bn2dec, the parameter being passed to BN_div_word is (a=35, w=10) (decimal numbers). It then calls the bn_div_words with (h=0, l=35, d=10) if you examine the code in linux_ppc32.s it will exit early on because h is 0. the routine returns a divide by 0, which is undefined according to the manual. In the case of ppc8xx the result is 0x8000. So this is the return value from bn_div_words, as seen in register R3. So what happens next is BN_div_word modifies a (1st parameter) with the result (0x8000) and returns 23 as the remainder of the division. So a is never zero as a result and hence the test for BN_is_zero is always false. The problem fails the very first time it uses bn_div_words. The next thing I did naturally was to fix the case when you have h=0, which you can quite easy do it with the native divwu instruction. Lo and behold I was once again disappointed when h is not equal to 0. More to come... On 7/5/05, David Ho [EMAIL PROTECTED] wrote: I can tell you with certainty, with reference to the function BN_bn2dec, that since lp is a pointer, and within the while loop around bn_print.c:136 lp is being incremented. Because the test BN_is_zero(t) is always false, you have a pointer that is going off into the stratosphere, hence the segfault on ppc8xx. More analysis to come. On 7/5/05, David Ho [EMAIL PROTECTED] wrote: First pass debugging results from gdb on ppc8xx. Executing ssh-keygen with following arguments. (gdb) show args Argument list to give program being debugged when it is started is -t rsa1 -f /etc/ssh/ssh_host_key -N . Program received signal SIGSEGV, Segmentation fault. BN_bn2dec (a=0x1002d9f0) at bn_print.c:136 136 *lp=BN_div_word(t,BN_DEC_CONV); (gdb) i r r0 0x0 0 r1 0x7fffd580 2147472768 r2 0x30012868 805382248 r3 0x8000 2147483648 r4 0xfef33fc267334652 r5 0x25 37 r6 0xfccdef8265084664 r7 0x7fffd4c0 2147472576 r8 0xfbad2887 4222429319 r9 0x84044022 2214871074 r100x0 0 r110x2 2 r120xfef2054267329620 r130x10030bc8 268635080 r140x0 0 r150x0 0 r160x0 0 r170x0 0 r180x0 0 r190x0 0 r200x0 0 r210x0 0 r220x0 0 r230x64 100 r240x5 5 r250x1002d438 268620856 r260x1002d9f0 268622320 r270x1002c578 268617080 r280x1 1 r290x10031000 268636160 r300xffbf7d0268171216 r310x1002d9f0 268622320 pc 0xfef2058267329624 ps 0xd032 53298 cr 0x24044022 604258338 lr 0xfef2054267329620 ctr0xfccefa0265088928 xer0x2000 536870912 fpscr 0x0 0 vscr 0x0 0 vrsave 0x0 0 (gdb) p/x $pc $1 = 0xfef2058 0x0fef2058 BN_bn2dec+472: stw r3,0(r29) (gdb) x 0x10031000 0x10031000: Cannot access memory at address 0x10031000 On 7/5/05, David Ho [EMAIL PROTECTED] wrote: This is the second confirmed report of the same problem on the ppc8xx. After reading my email. I must say I was the unfriendly one, I apologize for that. More debugging evidence to come. -- Forwarded message -- From: Murch, Christopher [EMAIL PROTECTED] Date: Jul 1, 2005 9:46 AM Subject: RE: PPC bn_div_words routine rewrite To: David Ho [EMAIL PROTECTED] David, I had observed the same issue on ppc 8xx machines after upgrading to the asm version of the BN routines. Thank you very much for your work for the fix. My question is, do you have high confidence in the other new asm ppc BN routines after observing this issue or do you think they might have similiar problems? Thanks. Chris -Original Message- From: David Ho [mailto:[EMAIL PROTECTED] Sent: Thursday, June 30, 2005 6:22 PM To: openssl-dev@openssl.org; [EMAIL PROTECTED] Subject: Re: PPC bn_div_words routine rewrite The reason I had to redo this routine, in case anyone is wondering, is because ssh-keygen segfaults when this assembly routine returns junk to the BN_div_word function. On a ppc, if you issue the command ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N The program craps out when it tries to write the public key in ascii decimal. Regards, David On 6/30/05,
Re: PPC bn_div_words routine rewrite
Let's take first call to BN_div_word for example from BN_bn2dec, the parameter being passed to BN_div_word is (a=35, w=10) (decimal numbers). It then calls the bn_div_words with (h=0, l=35, d=10) if you examine the code in linux_ppc32.s it will exit early on because h is 0. the routine returns a divide by 0, which is undefined according to the manual. In the case of ppc8xx the result is 0x8000. And on the PPC machine I have access to it returns 0. This is explanation why I never experienced any SEGV, but a sparse decimal output. And it does explain why BN_is_zero condition never met on your system and you hit sbrk(0) limit and suffer the penalty. However! Note that updated routine, http://cvs.openssl.org/getfile/openssl/crypto/bn/asm/ppc.pl?v=1.4 never issues divide by 0 [it traps instead, but the condition is never met now when called from BN_div_words] and it does return correct answer to me. Can you really confirm that updated subroutine doesn't work for you? And if so, how does problem manifest? Still SEGV? At same point? It should pointed out that bug in ppc.pl is encountered only in 0.9.7 context, as 0.9.8 avoids it by normalizing divisor [and adjusting dividend accordingly]. BTW, I can confirm that 0.9.7 produces correct decimal ASCII with your routine [but no luck with make test_bn], but in 0.9.8 context decimal printout comes out truncated [not sparse with some significant digits there and there, but truncated] if your routine is pasted in. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PPC bn_div_words routine rewrite
Okay, having actually did what Andy suggested, i.e. the one liner fix in the assembly code, bn_div_words returns the correct results. At this point, my conclusion is, up to openssl-0.9.8-beta6, the ppc32 bn_div_words routine generated from crypto/bn/ppc.pl is still busted. Your solution is either to use the one liner fix andy provided in his reply or my routine. My solution is a complete rewrite of the routine, which is tested to work on ppc8xx. I personally do not know why it would not work on other ppc32 systems but if you have time to spare you are welcome to give it a try on your ppc32, because it is by far the most straight-forward algorithm for division. If you have done long division on paper from your primary school days, this function mimics exactly the long division steps in binary (as opposed to decimal). Way easier to fix if you know what the algorithm is trying to do. Comments I have for the old routine are: Why do you signal an overflow condition when it appears functions that call bn_div_words do not check for overflow conditions? That's why in my routine I just let the register overflow. Why the complexity, does it offer performance advantage? Obviously code size is huge compared to mine. David On 7/5/05, David Ho [EMAIL PROTECTED] wrote: Let's take first call to BN_div_word for example from BN_bn2dec, the parameter being passed to BN_div_word is (a=35, w=10) (decimal numbers). It then calls the bn_div_words with (h=0, l=35, d=10) if you examine the code in linux_ppc32.s it will exit early on because h is 0. the routine returns a divide by 0, which is undefined according to the manual. In the case of ppc8xx the result is 0x8000. So this is the return value from bn_div_words, as seen in register R3. So what happens next is BN_div_word modifies a (1st parameter) with the result (0x8000) and returns 23 as the remainder of the division. So a is never zero as a result and hence the test for BN_is_zero is always false. The problem fails the very first time it uses bn_div_words. The next thing I did naturally was to fix the case when you have h=0, which you can quite easy do it with the native divwu instruction. Lo and behold I was once again disappointed when h is not equal to 0. More to come... On 7/5/05, David Ho [EMAIL PROTECTED] wrote: I can tell you with certainty, with reference to the function BN_bn2dec, that since lp is a pointer, and within the while loop around bn_print.c:136 lp is being incremented. Because the test BN_is_zero(t) is always false, you have a pointer that is going off into the stratosphere, hence the segfault on ppc8xx. More analysis to come. On 7/5/05, David Ho [EMAIL PROTECTED] wrote: First pass debugging results from gdb on ppc8xx. Executing ssh-keygen with following arguments. (gdb) show args Argument list to give program being debugged when it is started is -t rsa1 -f /etc/ssh/ssh_host_key -N . Program received signal SIGSEGV, Segmentation fault. BN_bn2dec (a=0x1002d9f0) at bn_print.c:136 136 *lp=BN_div_word(t,BN_DEC_CONV); (gdb) i r r0 0x0 0 r1 0x7fffd580 2147472768 r2 0x30012868 805382248 r3 0x8000 2147483648 r4 0xfef33fc267334652 r5 0x25 37 r6 0xfccdef8265084664 r7 0x7fffd4c0 2147472576 r8 0xfbad2887 4222429319 r9 0x84044022 2214871074 r100x0 0 r110x2 2 r120xfef2054267329620 r130x10030bc8 268635080 r140x0 0 r150x0 0 r160x0 0 r170x0 0 r180x0 0 r190x0 0 r200x0 0 r210x0 0 r220x0 0 r230x64 100 r240x5 5 r250x1002d438 268620856 r260x1002d9f0 268622320 r270x1002c578 268617080 r280x1 1 r290x10031000 268636160 r300xffbf7d0268171216 r310x1002d9f0 268622320 pc 0xfef2058267329624 ps 0xd032 53298 cr 0x24044022 604258338 lr 0xfef2054267329620 ctr0xfccefa0265088928 xer0x2000 536870912 fpscr 0x0 0 vscr 0x0 0 vrsave 0x0 0 (gdb) p/x $pc $1 = 0xfef2058 0x0fef2058 BN_bn2dec+472: stw r3,0(r29) (gdb) x 0x10031000 0x10031000: Cannot access memory at address 0x10031000 On 7/5/05, David Ho [EMAIL PROTECTED] wrote:
Re: PPC bn_div_words routine rewrite
Okay, having actually did what Andy suggested, i.e. the one liner fix in the assembly code, bn_div_words returns the correct results. Note that the final version, one committed to all relevant OpenSSL branches since couple of days ago and one which actually made to just released 0.9.8, is a bit different from originally suggested one-line fix, see for example http://cvs.openssl.org/chngview?cn=14199. At this point, my conclusion is, up to openssl-0.9.8-beta6, the ppc32 bn_div_words routine generated from crypto/bn/ppc.pl is still busted. Yes. Though it should be noted that 0.9.8 was inadvertently avoiding the bug condition. Recall that original problem report was for 0.9.7. Why do you signal an overflow condition when it appears functions that call bn_div_words do not check for overflow conditions? That's question to IBM. By the time they submitted the code, I've explicitly asked what would be appropriate way to generate *fatal* condition at that point, i.e. one which would result in a core dump, and it came out as division by 0 instruction. By that time I had no access to any PPC machine and had to just go with it. Now it actually came as surprise that division by 0 does not raise an exception, but silently returns implementation-specific value... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0
Hi All, I just checked this against my own FreeBSD 4.8 system and got the exact same segfault. This was with SNAP-20050704 I'll try FreeBSD 4.11 next. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dmitry Belyavsky via RT Sent: Monday, July 04, 2005 1:30 AM Cc: openssl-dev@openssl.org Subject: [openssl.org #1146] [BUG] Segfault on FreeBSD 4.8-RELEASE #0 Hello! I've found a SEGFAULT using FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 in bntest. Build is configured with ./Configure -ggdb BSD-x86-elf shared zlib make report: = OpenSSL self-test report: OpenSSL version: 0.9.8-beta7-dev Last change: Correct naming of the 'chil' and '4758cca' ENGINEs. Thi... Options: -ggdb enable-shared enable-zlib no-gmp no-krb5 no-mdc2 no-rc5 no-zlib-dynamic OS (uname): FreeBSD ibex.lan.cryptocom.ru 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 OS (config): i386-pc-freebsd4.8 Target (default): BSD-x86-elf Target: BSD-x86-elf Compiler: Using builtin specs. gcc version 2.95.4 20020320 [FreeBSD] Failure! [...] == Test output is: Starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr Segmentation fault (core dumped) *** Error code 139 == Backtrace is: (gdb) bt #0 0x281330a1 in bn_mul_add_words () from ./libcrypto.so.0.9.8 #1 0x0806038c in ?? () #2 0x28133009 in bn_sqr_normal (r=0x282966c4, a=0x24, n=37, tmp=0x28132c51) at bn_sqr.c:182 #3 0x28132c51 in BN_sqr (r=0x805578c, a=0x28066000, ctx=0x28132abc) at bn_sqr.c:132 #4 0x0804b58f in test_sqr (bp=0x80610c0, ctx=0x8061080) at bntest.c:691 #5 0x08049d14 in main (argc=671421537, argv=0xbfbffb24) at bntest.c:215 Thank you! -- SY, Dmitry Belyavsky (ICQ UIN 6575) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Ticket Resolved
Would You please apply the second DIFF file in sead of the first one ? - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 2:14 AM Subject: [openssl.org #1109] Ticket Resolved 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 #1109] Ticket Resolved
I mean this one: - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 2:14 AM Subject: [openssl.org #1109] Ticket Resolved 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]
[openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
I meant to apply this diff file - it's better solution ;) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
[EMAIL PROTECTED] - Wed Jul 6 01:10:41 2005]: Would You please apply the second DIFF file in sead of the first one ? According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I thought I had applied the second diff. The one you mention below seems to be the first one (the one without additional config file options). Is there a problem with the second diff? Since 0.9.8 has been released now it will have to wait until 0.9.8a if there is a problem. Steve. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
The one with additional config options was the first one. The one without config options is better (according to me) and is the second one. Both are working. Just the second one does not need config options. Do You need a diff file between the latest ca.c - version 1.150 and my second diff file in order not to use config options? If yes - where to send it ? - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Wednesday, July 06, 2005 2:17 AM Subject: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command [EMAIL PROTECTED] - Wed Jul 6 01:10:41 2005]: Would You please apply the second DIFF file in sead of the first one ? According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I thought I had applied the second diff. The one you mention below seems to be the first one (the one without additional config file options). Is there a problem with the second diff? Since 0.9.8 has been released now it will have to wait until 0.9.8a if there is a problem. Steve. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
I just checked. As I see there are actually 3 diff files there (http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1109): 1. File difference report generated by CSDiff by ComponentSoftware on 13.6.2005 Ç. 13:19 - 3.3KB 2. --- openssl-0.9.8-beta5/apps/ca.c.oldFri Apr 15 21:29:34 2005 - 8,7KB 3. --- openssl-0.9.8-beta5\apps\ca.c.old2005-04-15 21:29:33.0 - 8.3k You applied the 2nd one in stead of the 3rd one. I just forgot about the 1st one. What should I do now in order to apply the 3rd one? - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Wednesday, July 06, 2005 2:17 AM Subject: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command [EMAIL PROTECTED] - Wed Jul 6 01:10:41 2005]: Would You please apply the second DIFF file in sead of the first one ? According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. I thought I had applied the second diff. The one you mention below seems to be the first one (the one without additional config file options). Is there a problem with the second diff? Since 0.9.8 has been released now it will have to wait until 0.9.8a if there is a problem. Steve. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
[EMAIL PROTECTED] - Wed Jul 6 01:40:04 2005]: You applied the 2nd one in stead of the 3rd one. I just forgot about the 1st one. What should I do now in order to apply the 3rd one? Personally I prefer the patch that has been applied over the 3rd one. The applied patch allow the string mask to be set independently of whether UTF8 format is used for characters. This is consistent with the way 'req' operates. The 3rd one always sets the UTF8 only mask at the same time as using UTF8 format. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command
If You think so Ok then ;) Let's leave it as it is. Thank You very much and once again sorry for the inconvenience. Best regards Stefan - Original Message - From: Stephen Henson via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Sent: Wednesday, July 06, 2005 3:26 AM Subject: [openssl.org #1109] Please urgently impelment -utf8 parameter in openssl ca command [EMAIL PROTECTED] - Wed Jul 6 01:40:04 2005]: You applied the 2nd one in stead of the 3rd one. I just forgot about the 1st one. What should I do now in order to apply the 3rd one? Personally I prefer the patch that has been applied over the 3rd one. The applied patch allow the string mask to be set independently of whether UTF8 format is used for characters. This is consistent with the way 'req' operates. The 3rd one always sets the UTF8 only mask at the same time as using UTF8 format. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1147]
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
