Hi. I've been experimenting with the libcrypto++ sha256 code, and I
think I've found a couple of problems. Is this list, the sourceforge
"feature requests" tracker, or someplace else, the best place for bug
reports?
I started with the 5.6.0 release code, but folded in the bugfix for
non-SSE2 x86 machine checked into the repository back in July.
Problem #1: A message straddling memory address 0x80000000 (e.g.,
starting at 0x7ffffff0 with length 32) on 32-bit x86 with the asm
support enabled gets hashed incorrectly, because signed comparisons are
done on addresses, so the ending address looks "less than" the starting
address. (On some OSes, you can't get such an address range, or you may
need a special kernel configuration.) It's probably safer to assume
that messages won't straddle address 0.
--- a/c5/sha.cpp
+++ b/c5/sha.cpp
@@ -375,7 +375,7 @@ static void CRYPTOPP_FASTCALL X86_SHA256_HashBlocks(word32
*state, const word32
AS2( movdqa [AS_REG_7+1*16], xmm1)
AS2( movdqa [AS_REG_7+0*16], xmm0)
AS2( cmp WORD_REG(dx), DATA_END)
- ASJ( jl, 0, b)
+ ASJ( jb, 0, b)
#endif
#if CRYPTOPP_BOOL_X86
@@ -399,7 +399,7 @@ static void CRYPTOPP_FASTCALL X86_SHA256_HashBlocks(word32
*state, const word32
AS2( add [AS_REG_7+7*4], ecx)
AS2( mov ecx, AS_REG_7d)
AS2( cmp WORD_REG(dx), DATA_END)
- ASJ( jl, 2, b)
+ ASJ( jb, 2, b)
#if CRYPTOPP_BOOL_SSE2_ASM_AVAILABLE
ASL(5)
#endif
Problem #2: A 65-byte message (00 01 02 03...) seems to get hashed
incorrectly with the 64-bit x86 asm support, with or without my patch
above. In 32-bit mode (asm or non-asm) or in 64-bit non-asm mode, or
with the openssl sha256 code, I get consistent results; the libcrypto++
64-bit x86 asm code in the repository, with g++-4.3.2 on Debian x86_64,
is giving me something different. The 64-byte and shorter leading
substrings are hashed consistently by all versions. And if I drop the
asm code into a C source file, with some wrappers of my own, it seems to
work okay. I haven't tracked it down any further yet, but will keep
poking at it.
I have a test program that shows both of these problems, and the
non-SSE2 bug that was fixed in July, and runs some other length- and
alignment-related tests. My company's releasing it into the public
domain, in case you want to cannibalize it for some tests. It's a bit
large, though; if anyone's interested, let me know how you want it
delivered.
Ken
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
