[ pycrypto-Bugs-1154530 ] SHA 256 doesn't match test vectors on AMD64

Bugs item #1154530, was opened at 2005-03-01 20:24
Message generated for change (Comment added) made by zooko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1154530&group_id=20937

Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: SHA 256 doesn't match test vectors on AMD64

Initial Comment:
On my Macintosh PPC G4 laptop:

>>> hex(bytes_to_long(SHA256.new('abc').digest()))
'0xBA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015ADL'

On my Linux Athlon64 workstation:

>>> hex(bytes_to_long(SHA256.new('abc').digest()))
'0x551CE4769446B343295EA7F819BAE21157541986A4DE11AB46B2340EA9831F22L'

The former is correct the FIPS 180-2 test vector for
SHA-256.

I see that the implementation is by Tom St. Denis but
it is very different from the one in his current
libtomcrypt 1.0.

Perhaps we should upgrade to that version?

I tried to run test_hashes.py, but it is apparently
written for an older (?) version of sancho that the
sancho 2.0 that I just downloaded.

----------------------------------------------------------------------

>Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-04-19 15:21

Message:
Logged In: YES 
user_id=52562

misa, what platform are you on?  On 64-bit linux on
Athlon64, an int is 32 bits, but a long is 64 bits.  So the
patch that you describe shouldn't change anything on an
Athlon64.

However, your suggestion caused me to clue into another
issue that probably *is* my problem on my Athlon64: the code
uses "unsigned long" in several places where it almost
certainly intends to have an unsigned 32-bit thing.  So I've
written a patch that replaces all those "unsigned long"s
with U32s.

I also threw in your inttypes.h patch, just for good measure.

https://yumyum.zooko.com:19144/pub/repos/pycrypto-plus-patches


----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2005-04-19 14:53

Message:
Logged In: YES 
user_id=205865

Check out the patch attached to the RIPEMD bug, it makes
SHA256 work for me.

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2005-04-19 14:01

Message:
Logged In: YES 
user_id=205865

Please see:

http://sourceforge.net/tracker/index.php?func=detail&aid=1185980&group_id=20937&atid=120937

a possible solution for problems on 64-bits.

typedef unsigned int U32;^M

This is asking for trouble - on 64-bit systems ints are
32-bit. See the proposed patch in the RIPEMD bug.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2005-03-01 21:14

Message:
Logged In: YES 
user_id=413

this SHA256 also fails on the Alpha.

a (presumably different, i haven't looked at the code)
libtomcrypt sha256 implementation works just fine for me as
seen in this python patch that adds a hashlib module that
uses it:

https://sourceforge.net/tracker/?func=detail&aid=1121611&group_id=5470&atid=305470


----------------------------------------------------------------------

Comment By: Zooko O'Whielacronx (zooko)
Date: 2005-03-01 20:24

Message:
Logged In: YES 
user_id=52562

Bumping priority, just to distinguish this one from the crowd.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1154530&group_id=20937


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728