Re: Possible Bug in CRC32

[Shawn Masters]

	I was talking about the hexencoder.  I'm not sure how to do it while in 
the HashFilter, but you can defintly do it with methods such a 
HexEncoder::GetWord32().  I guess it might be nice to have an Endianess 
option throughout HexEncoder, but like you said it is a pretty simple 
thing to get around.

        73,
                Shawn
Wei Dai wrote:

I think Shawn was mistaken. There is no way to change the byte order of
the CRC32 output (other than to do it yourself, which only takes one line
of code using std::reverse). The byte order used by Crypto++ is the same
as the CRC32 byte order of the gzip format, and I think it is considered
standard.
On Fri, Jul 18, 2003 at 04:49:35PM -0400, [EMAIL PROTECTED] wrote:

Thanks for clearing that up, but I could use a little help altering the
code.  I've been looking through the online reference, and I'm failing to
see where any of the methods I'm implementing allow you to change
this...could somebody please point me in the right direction? Thanks.
----- Original Message ----- 
From: "Shawn Masters" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 18, 2003 10:08 AM
Subject: Re: Possible Bug in CRC32

This is a simple Endian problem.  Just tell the HexEncoder which
Endianness you want to encode as.  It assumes Big Endian, and you will
have to rework your code a little.
73,
Shawn
Matt "Cyber Dog" LaPlante wrote:


crc32 module of CryptoPP 5.1 on VisualStudio.net 2003:

Using the following command line to calculate the CRC32:
const char* chars;
StringSource(chars, true, new HashFilter(crc32, new HexEncoder(new
StringSink(test))));
---or----
FileSource(chars, true, new HashFilter(crc32, new HexEncoder(new
StringSink(test))));
...where chars is either a text string, or a file path.

The problem is the bytes come out in reversed order.  For example, take
the

string "hello":
actual crc32: 3610a686
cryptopp crc32: 86a61036
As you can see, the bytes come out in reverse order.  I've tested this
side-by-side with the Adler32 checksum, and Adler32 produces the correct
result using the exact same code, which leads me to believe the source of
the problem is in Crypto and not the code I'm using to access it.