"Mayers, Philip J" <[EMAIL PROTECTED]> writes: > Message-ID: <[EMAIL PROTECTED]> > From: "Mayers, Philip J" <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: DES-CBC-CRC > Date: Tue, 11 Dec 2001 19:31:53 -0000 > > Ok, I'm stupid... DES-CBC-CRC - here's the data before encryption, after > checksumming (octal escapes used throughout): > > N\211\225f\322r\004=\322\316e\302This is a test.\000\000\000\000\000 > > So, the checksum of this data: > > N\211\225f\322r\004=\000\000\000\000This is a test.\000\000\000\000\000 > > Should be \322\316e\302 - *I* get this CRC: t\240\021\213 > > My CRC32 code looks like this (although I've tried other versions, based on > the MIT and Heimdal code): > > class CRC32: > poly = 0xEDB88320L > table = [0L,]*256 > for i in range(256): > crc = long(i) > for j in range(8,0,-1): > if crc & 1: > crc = (crc >> 1) ^ poly > else: > crc = crc >> 1 > table[i] = crc > digestsize = 4 > > def __init__(self, data=''): > self.data = data > > def digest(self): > crc = 0l > for c in self.data: > idx = crc ^ ord(c) > idx = int(idx & 0xff) > crc = self.table[idx] ^ (crc>>8) > return > chr(crc&0xff)+chr((crc>>8)&0xff)+chr((crc>>16)&0xff)+chr((crc>>24)&0xff) > > Help! What am I doing wrong? As far as I can tell, I pass the MIT test data. > I'm stumped...
If you want to check your results against C, a good way to do this is to put *lots* of printfs in your test code, and the C original, and print out every intermediate value. Then do a "diff" to see where the values start to drift. If you have enough printfs, you'll be able to identify the exact expression where things went wrong, what went in, and what came out. In general, this is a useful technique with any cryptographic function. You should also look at at the table; index 0 should be 0, index 128 should be 0xEDB88320L, and the remaining values should match the values that other versions of the function get. Another approach is of course ye old web search. In this particular case, this algorithm looks like the "Autodin-II" CRC. http://home.ecn.ab.ca/~jsavard/crypto/co041101.htm General description of class of algorithms. http://www.openvms.compaq.com:8000/72final/4515/4515pro_026.html#4515ch9_158 Describes a VAX instruction that does the guts in one fell swoop. Ah, the wonders of a properly designed CISC. http://www.cs.dartmouth.edu/~jonh/md5/CRC32.java contains source to a Java CRC-32 implementation. It uses an unsigned shift operation which may be important. The later versions of python (since 1.5, current release is 2.2) include crc32 and zlib. value=-1-zlib.crc32("string",-1) ?? The guts of the crc32 algorithm should be the same as MIT. Note that this algorithm complements its initial & final value (this was apparently part of the original autodin-II standard). MIT does not (why?) You'll want to pass in 0xffffffff and compute the 1's complement of the result. I think it's possible unsigned right shifts (in both the initialization and data loops) will fix your problem. If not, then you'll have to start looking at all your intermediate values more closely. It's just good old fashioned debugging, good for your soul. -Marcus Watts UM ITCS Umich Systems Group
