Re: [openssl.org #3151] Bug report: openssl-1.0.1e-28.fc19.i686 on Fedora 19: OPENSSL_ia32_cpuid() misdetects RDRAND instruction on old Cyrix M II i686 CPU
New openssl builds including the Cyrix patch have been built for Fedora 18, 19, and 20 and fix my problem on F19. I'm still not clear on why this patch wasn't included in the Fedora builds before, since it dates from March, but I think if this patch actually has been included upstream, then you can close this ticket. Thanks. signature.asc Description: PGP signature
Re: [PATCH 0/4] ppc64 port to little-endian
Hi, This series of patches creates a new target for ppc64le and updates the current assembly code for ppc64 in order to use the correct byte-order when need. Different approaches where tested to byte swap bytes, including the use of instructions such as lwbrw, but the current version performed 5% faster than the others. Thanks. Feedback is provided in separate messages. As for workflow. Configure will be patched last after we resolve all the issues, so bear with me. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH 2/4] ppc64: adapt SHA1 assembly code to little-endian
SHA1 algorithm is defined using 32-bit variables in big-endian. This patch updates sha1-ppc.pl to generate code that byte swaps the input data when needed. Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com --- crypto/sha/asm/sha1-ppc.pl | 32 1 file changed, 28 insertions(+), 4 deletions(-) ... +$code.=___ if $LITTLE_ENDIAN; +rotlwi $temp_reg,$dst,8 +rlwimi $temp_reg,$dst,24,0,7 +rlwimi $temp_reg,$dst,24,16,23 +clrldi $dst,$temp_reg,32 +___ +} http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=3f9562a669b116a4cdd62922563b8d45a1cbf60d eliminates redundant clrldi. Please verify and confirm that it's working. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH 3/4] ppc64: adapt SHA2 assembly code to little-endian
SHA2 algorithm is defined using 32-bit and 64-bit variables in
big-endian. This patch updates sha512-ppc.pl to generate code that byte
swaps the input data when needed.
Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com
---
crypto/sha/asm/sha512-ppc.pl | 196 +--
1 file changed, 133 insertions(+), 63 deletions(-)
...
+$code.=___ if ($SZ==8 $LITTLE_ENDIAN);
+ ; load 64 bit value
+ lwz $t0,`$i*$SZ+4`($inp)
+ lwz @X[$i],`$i*$SZ`($inp)
+ insrdi @X[$i],$t0,32,0
+ ; swap bytes
+ rldicl $t0,@X[$i],32,32
+ rotlwi $a0,$t0,8
+ rlwimi $a0,$t0,24,0,7
+ rlwimi $a0,$t0,24,16,23
+ rotlwi $t0,@X[$i],8
+ rlwimi $t0,@X[$i],24,0,7
+ rlwimi $t0,@X[$i],24,16,23
+ rldicr $t0,$t0,32,31
+ or @X[$i],$t0,$a0
+___
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=8ff8a829b053274124c3f2231570af3ae96806c0
eliminates 3 redundant instructions and interleaves remaining ones to
favour in-order P6. Please verify and confirm if it's working.
+sub long64 {
+ foreach $n (@_) {
+ my $lo = (0x $n);
+ my $hi = ($n 32);
this would break if build on system
with 32-bit perl. I've chosen to resolve it through ppc-xlate.pl and
.quad directive.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH 4/4] ppc64: adapt AES assembly code to little-endian
This patch updates aes-ppc.pl to generate code that byte swaps the input data when needed, Signed-off-by: Marcelo Cerri mhce...@linux.vnet.ibm.com --- crypto/aes/asm/aes-ppc.pl | 43 +++ 1 file changed, 43 insertions(+) ... .align 4 Lppc_AES_encrypt_compact: +___ + fix_byte_order($s0,$acc00); + fix_byte_order($s1,$acc00); + fix_byte_order($s2,$acc00); + fix_byte_order($s3,$acc00); +$code.=___; If input block crosses page boundary, then at this point data is in correct byte order. Please verify http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=c944f8170358ecce419045b919be604844369e36 and confirm if it works. Once again, at the moment I'm not applying patch to Configure as I'd like to get feedback and resolve eventual problems before we do that. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
Not to stand in the way of progress at all, but just to note we cross-compile OpenSSL libraries for an embedded linux target that is still using libc_r, not libpthread. That will not change anytime soon for us, at least on legacy systems. Besides that, it seems much of this discussion is about native builds and config-time detection of threading support. What about cross-compiling? Kevin On Wed, Oct 30, 2013 at 7:38 PM, Nico Williams n...@cryptonector.comwrote: It's getting closer, see: https://github.com/nicowilliams/openssl/compare/thread_safety I spoke to a Linux expert and was told that the correct thing to do in the shared build of OpenSSL is to always link with -lpthread. I assert that this is also the correct thing to do on Solaris. It's been so for a long time now. I.e., OpenSSL should default to using native threads on all POSIX-like and Win32/64 systems (others will have to contribute similar support for other environments). My patches nonetheless will allow apps to provide alternate threading callbacks, just as today, except that the callbacks now may not be changed once set, and they are set to native implementations where possible if they are needed before they are set. Nico -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Self-initialization of locking/threadid callbacks and auto-detection of features
On Oct 31, 2013 8:19 AM, Kevin Fowler kevpfow...@gmail.com wrote: Not to stand in the way of progress at all, but just to note we cross-compile OpenSSL libraries for an embedded linux target that is still using libc_r, not libpthread. That will not change anytime soon for us, at least on legacy systems. Besides that, it seems much of this discussion is about native builds and config-time detection of threading support. What about cross-compiling? I will be introducing new targets. For cross-compilation you must tell ./Configure the target name and there's no auto-detection. If you want auto-detection you run ./config on the target host. (At least that's my understanding of how OpenSSL build configuration works.)
[openssl.org #3155] Bug report: S/MIME base64 decoding fails on files that have 76 base64 characters per line
Hi, This is probably the same bug as mentioned at http://comments.gmane.org/gmane.comp.encryption.openssl.user/40609 Given the scripts openssl version openssl smime -decrypt -in no-headers.base64-wrapped-good.eml -out decrypted.signed.mime -inkey x509.private-key.pem echo finished with good openssl smime -decrypt -in no-headers.base64-wrapped-bad.eml -out decrypted.signed.mime -inkey x509.private-key.pem echo finished with bad and set RANDFILE=%LOCALAPPDATA%\.rnd set OPENSSL_CONF=..\OpenSslScripts\openssl.cfg ..\OpenSslScripts\openssl.exe version ..\OpenSslScripts\openssl.exe smime -decrypt -in no-headers.base64-wrapped-good.eml -out decrypted.signed.mime -inkey x509.private-key.pem ..\OpenSslScripts\openssl.exe smime -decrypt -in no-headers.base64-wrapped-bad.eml -out decrypted.signed.mime -inkey x509.private-key.pem I get these messages on Mac OS/X, and similar messages on Windows. OpenSSL 0.9.8y 5 Feb 2013 finished with good Error reading S/MIME message 34178:error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data:/SourceCache/OpenSSL098/OpenSSL098-47.2/src/crypto/asn1/a_d2i_fp.c:251: 34178:error:0D0D006E:asn1 encoding routines:B64_READ_ASN1:decode error:/SourceCache/OpenSSL098/OpenSSL098-47.2/src/crypto/asn1/asn_mime.c:144: 34178:error:0D0D20C6:asn1 encoding routines:SMIME_read_ASN1:asn1 parse error:/SourceCache/OpenSSL098/OpenSSL098-47.2/src/crypto/asn1/asn_mime.c:456: finished with bad and OpenSSL 1.0.1e 11 Feb 2013 finished good Error reading S/MIME message 3152:error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data:.\crypto\asn1\a_d2i_fp.c:251: 3152:error:0D0D106E:asn1 encoding routines:B64_READ_ASN1:decode error:.\crypto\asn1\asn_mime.c:193: 3152:error:0D0D40CB:asn1 encoding routines:SMIME_read_ASN1:asn1 parse error:.\crypto\asn1\asn_mime.c:528: finished bad The .eml files are available as public Gists: https://gist.github.com/anonymous/7233329 = no-headers.base64-wrapped-bad.eml (which has 76 base64 characters per line) https://gist.github.com/anonymous/7233372 = no-headers.base64-wrapped-good.eml (which has 64 base64 characters per line) I checked http://www.ietf.org/rfc/rfc2045.txt which clearly indicates 76 base64 characters (excluding CRLF) is allowed for base64 encoded portions of MIME (and therefore of S/MIME). Since the files are not plain base64 encoded files generated beyond our control, it is a bit tough to rearrange the base64 encoded portion of them. How can I help to get this fixed? Groet, -- Jeroen W. Pluimers - specialist in .NET, Win32, SQL, Visual Studio Delphi tel: +31 20 610 8322 fax: +31 20 610 8323 GSM: +31 654 385 135 mailto:jer...@pluimers.com BeSharp.net is a trademark of Pluimers Software Ontwikkeling BV, Amsterdam, Trade-register 34152606 http://wiert.me ; http://jwpluimers.myplaxo.com/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3156] [PATCH] fix documentation for SSL_CTX_set_tmp_dh_callback and friends
The synopsis had the wrong parameter types and an extra (unused) function pointer declaration. The demo dhparam filenames should all end in .pem. --- doc/ssl/SSL_CTX_set_tmp_dh_callback.pod | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod b/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod index 29d1f8a..650d27a 100644 --- a/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod +++ b/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod @@ -12,11 +12,9 @@ SSL_CTX_set_tmp_dh_callback, SSL_CTX_set_tmp_dh, SSL_set_tmp_dh_callback, SSL_se DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength)); long SSL_CTX_set_tmp_dh(SSL_CTX *ctx, DH *dh); - void SSL_set_tmp_dh_callback(SSL_CTX *ctx, + void SSL_set_tmp_dh_callback(SSL *ssl, DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength)); - long SSL_set_tmp_dh(SSL *ssl, DH *dh) - - DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength)); + long SSL_set_tmp_dh(SSL *ssl, DH *dh); =head1 DESCRIPTION @@ -81,7 +79,7 @@ instead (see Ldhparam(1)|dhparam(1)), but in this case SSL_OP_SINGLE_DH_USE is mandatory. Application authors may compile in DH parameters. Files dh512.pem, -dh1024.pem, dh2048.pem, and dh4096 in the 'apps' directory of current +dh1024.pem, dh2048.pem, and dh4096.pem in the 'apps' directory of current version of the OpenSSL distribution contain the 'SKIP' DH parameters, which use safe primes and were generated verifiably pseudo-randomly. These files can be converted into C code using the B-C option of the -- 1.8.4.rc3 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3157] PATCH Win32/64 openssl 1.0.1e fixes
Hello,
Please accept my patches for openssl 1.0.1e to enable building on Windows 7
Win32 and Win64 architectures. The problems are that running mk1mf.pl on
Windows gets confused by the carriage return for each EOL, and that there is a
missing directory separator on the uplink-x86_64.pl that causes the scripts to
fail. Perhaps these have already been incorporated into the repository head,
but the bug with the carriage returns dates back over many versions of openssl,
so perhaps the fix has not yet been incorporated?
diff mk1mf.pl openssl-1.0.1e/util/mk1mf.pl
330a331
s/\r$//; #remove carriage return too!
diff uplink-x86_64.pl openssl-1.0.1e/ms/uplink-x86_64.pl
5c5
open OUT,| \$^X\ ${dir}../crypto/perlasm/x86_64-xlate.pl $output;
---
open OUT,| \$^X\ ${dir}/../crypto/perlasm/x86_64-xlate.pl $output;
Many thanks
Leigh
--
Leigh M. Smith
iZotope, Inc.
lsm...@izotope.com
+1 (646) 250-1134
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3158] [bug] bad output for 'openssl ciphers -ssl2' built with 'no-ssl2'
Hello,
If OpenSSL is compiled without SSLv2 support, the line
openssl ciphers -ssl2 HIGH
incorrectly prints all ciphers for any protocol classified as HIGH.
Without 'HIGH', this is the output ('openssl ciphers -ssl2'):
Error in cipher list
3076146824:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher
match:ssl_lib.c:1314:
If we add 'HIGH', the result is:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:SRP-AES-256-CBC-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:AECDH-DES-CBC3-SHA:SRP-3DES-EDE-CBC-SHA:ADH-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE
-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:SRP-AES-128-CBC-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA
This is the same list as what we get when we give the command 'openssl ciphers
HIGH', without the '-ssl2' parameter.
For comparison, when SSLv2 is supported, the output of 'openssl ciphers -ssl2
HIGH' is the following:
DES-CBC3-MD5
For completeness, when building OpenSSL without SSLv2 support, this is the
command line given to 'config':
./config zlib enable-rc5 no-ssl2 --prefix=/opt/openssl-1.0.1e
Affected OpenSSL version: 1.0.1e
System info: Linux svdb-laptop 3.5.0-42-generic #65~precise1-Ubuntu SMP Wed Oct
2 20:57:24 UTC 2013 i686 i686 i386 GNU/Linux
Regards,
Serge van den Boom
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH 0/4] ppc64 port to little-endian
Hi Andy, Thanks for your changes, they are working fine. I'm setting up a little-endian and a big-endian system that I'll use to test and compare performance results. As soon as I finish I'll post them here. The only thing that I had to change was a typo in SHA-512: diff --git a/crypto/sha/asm/sha512-ppc.pl b/crypto/sha/asm/sha512-ppc.pl index 0648655..d6a86c7 100755 --- a/crypto/sha/asm/sha512-ppc.pl +++ b/crypto/sha/asm/sha512-ppc.pl @@ -383,7 +383,7 @@ $code.=___ if ($SZ==8 $LITTLE_ENDIAN); rlwimi $t0,$a0,24,0,7 rlwimi @X[$i],$a1,24,0,7 rlwimi $t0,$a0,24,16,23 -rlwimi @X[$i],$a1,25,16,23 +rlwimi @X[$i],$a1,24,16,23 insrdi @X[$i],$t0,32,0 ___ ROUND_00_15($i,@V); Best regards, Marcelo On Thu, Oct 31, 2013 at 11:12:50AM +0100, Andy Polyakov wrote: Hi, This series of patches creates a new target for ppc64le and updates the current assembly code for ppc64 in order to use the correct byte-order when need. Different approaches where tested to byte swap bytes, including the use of instructions such as lwbrw, but the current version performed 5% faster than the others. Thanks. Feedback is provided in separate messages. As for workflow. Configure will be patched last after we resolve all the issues, so bear with me. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH 0/4] ppc64 port to little-endian
The only thing that I had to change was a typo in SHA-512: diff --git a/crypto/sha/asm/sha512-ppc.pl b/crypto/sha/asm/sha512-ppc.pl index 0648655..d6a86c7 100755 --- a/crypto/sha/asm/sha512-ppc.pl +++ b/crypto/sha/asm/sha512-ppc.pl @@ -383,7 +383,7 @@ $code.=___ if ($SZ==8 $LITTLE_ENDIAN); rlwimi $t0,$a0,24,0,7 rlwimi @X[$i],$a1,24,0,7 rlwimi $t0,$a0,24,16,23 -rlwimi @X[$i],$a1,25,16,23 +rlwimi @X[$i],$a1,24,16,23 insrdi @X[$i],$t0,32,0 ___ ROUND_00_15($i,@V); Applied, thanks. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3155] Bug report: S/MIME base64 decoding fails on files that have 76 base64 characters per line
From: owner-openssl-dev On Behalf Of Jeroen Pluimers via RT Sent: Thursday, October 31, 2013 14:32 This is probably the same bug as mentioned at http://comments.gmane.org/gmane.comp.encryption.openssl.user/40609 It's not exactly the same problem. Your lines are not 76. snip: one smime file fails to parse body with not enough data The .eml files are available as public Gists: https://gist.github.com/anonymous/7233329 = no-headers.base64- wrapped-bad.eml (which has 76 base64 characters per line) https://gist.github.com/anonymous/7233372 = no-headers.base64- wrapped-good.eml (which has 64 base64 characters per line) In addition your bad file has a line with (only) dot after the end of the base64. If I remove that, it parses okay. (I can't decrypt of course.) If I strip the smime headers and just run the body, with or without dot, through 'openssl base64 -d' it exhibits the same problem. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
