Do you see the same stack trace when simply using the random number
generator:
./openssl rand 64
What if you simply use SHA1:
./openssl sha1 somefile
On 04/14/2015 12:17 PM, John Unsworth wrote:
Is no-one interested at all about this problem? Or do I need to send
it to another place?
Thanks for the suggestion. I rebuilt with gcc and get just the same problem.
Regards,
John.
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Jeffrey Walton
Sent: 15 April 2015 12:59
To: OpenSSL Users List
Subject: Re: [openssl-users] OpenSSL
core 'core' of 24243: ./openssl rand 64
000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8
00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c
00226c00 ssleay_rand_status (c734,
How about the ./openssl sha1 command? Does that bomb too?
It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the
1.0.1 source into the 1.0.2 source. Then clean, configure, compile and
try again. There were changes to this file between 1.0.1 and 1.0.2.
Perhaps a bug was
That seems to have fixed the crash.
-bash-3.00$ ./openssl rand 64
zÔòMÉÜOvá¯@ét†ÅEÙ^±Q!þ\‰b_¨ëYŸÁµiT-n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$
Not sure about the output though.
However negotiation causes a core:
-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
CONNECTED(0004)
depth=0 CN
Looks like the crash is in SHA-512 this time, not SHA-1. There's a
separate perl script to generate that assembly code. Try the 1.0.1
version of sha512-sparcv9.pl.
The output from your rand command is valid. You can use the -base64
option if you want something more readable.
On 04/15/2015
Greetings,
This message has been automatically generated in response to the
creation of a trouble ticket regarding:
BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken,
a summary of which appears below.
There is no need to reply to this message right now. Your ticket has been
assigned
Still exactly the same crash. And even if these assembly code problems can be
fixed there is still the negotiation error after compiling with no-asm.
4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record
mac:s3_pkt.c:1456:SSL alert number 20
4280581268:error:140790E5:SSL
On 4/15/15 4:59 AM, Jeffrey Walton wrote:
Can you try with a different compiler? Is Clang available to you? (If
not, I can provide you with a script or recipe to build it).
Here's what one person was just saying about Sun's compiler on another
list. He maintains another crypto-toolkit:
...
Bug opened.
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Salz, Rich
Sent: 14 April 2015 17:41
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken
You could mail it to RT and then it will at least be logged and
This appears to be a different problem than the crash in SHA. Since
you're seeing a bad record mac, it appears the TLS handshake has made
it through the ChangeCipherSpec message. Do you know which cipher suite
is being negotiated? If it's AES, it may be worth trying a 3DES cipher
suite. If the
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Carson Gaspar
Sent: Wednesday, April 15, 2015 14:40
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken
On 4/15/15 4:59 AM, Jeffrey Walton wrote:
Here's what
I can’t dictate what cipher suite our customers will use, all have to work. It
seems to me that for the time being I will have to stay with the 1.0.1 builds.
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
John Foley
Sent: 15 April 2015 21:09
To:
I'm wondering if anybody has any experience with the af_alg engine located here:
http://src.carnivore.it/users/common/af_alg/about/
I am able to compile the engine and can run commands such as:
openssl speed md5 -engine af_alg
and I see that openssl has loaded the engine as indicated by this
One point is that if this is a delivery for someone
subject to the FIPS-only procurementrequirement
imposed on various US Government related entities,
then whatever OS theyuse, MUST (by that requirement)
have already passed this for its password handling.
This is *technically* true, in the
15 matches
Mail list logo
