>>>>> "mdw" == Marcus Watts <[EMAIL PROTECTED]> writes:
mdw> "Mayers, Philip J" <[EMAIL PROTECTED]> writes: >> poly = 0xEDB88320L Hm. I thought this seemed wrong, but it turns out to be bit-reversal... The ISO-3309 32-bit FCS polynomial is 0x4c11db7, assuming that the MSB corresponds to the highest order term of the polynomial, and dropping the x^32 term. It appears that what you have is the bit-reversal of 0x4c11db7, which is 0xedb88320L. >> Help! What am I doing wrong? As far as I can tell, I pass the MIT test data. >> I'm stumped... Which test data are you passing successfully? Where did you get it from? mdw> In this particular case, this algorithm looks like the "Autodin-II" CRC. ...which I believe uses the same polynomial as used in the 32-bit HDLC FCS. mdw> http://home.ecn.ab.ca/~jsavard/crypto/co041101.htm mdw> General description of class of algorithms. mdw> http://www.openvms.compaq.com:8000/72final/4515/4515pro_026.html#4515ch9_158 mdw> Describes a VAX instruction that does the guts in one fell swoop. mdw> Ah, the wonders of a properly designed CISC. mdw> http://www.cs.dartmouth.edu/~jonh/md5/CRC32.java mdw> contains source to a Java CRC-32 implementation. mdw> It uses an unsigned shift operation mdw> which may be important. Also, look at http://www.repairfaq.org/filipg/LINK/F_crc_v31.html Which provides quite a comprehensive description of CRC algorithms and implementations, as well as of the numerous variants that exist. mdw> The guts of the crc32 algorithm should be the same as MIT. Note mdw> that this algorithm complements its initial & final value (this mdw> was apparently part of the original autodin-II standard). MIT mdw> does not (why?) You'll want to pass in 0xffffffff and compute mdw> the 1's complement of the result. It's unclear why our implementation fails to do the pre-complement and post-complement. I suspect there was a failure to read the specification closely. Given that I know essentially nothing about the python language, the python implementation quoted looks correct, with the possible exception of not using signed types. Note that, in C, right-shifting a negative signed integer value is implementation-defined. This may or may not be the case in python, but if it fills with the sign bit rather than fills with zero, you may run into problems. Hm. I just ran your test data (with the CRC field nulled out) through the model CRC program and got the same result that you got. I also trapped into the debugger while running kinit and fed krb5_old_decrypt the your data and still got the same checksum that you did. ---Tom
