It is strange that the author stops short of making a recommendation for a CRC algorithm. He mentions he likes the one used in PKZIP and PNG, but out of the doz

It is strange that the author stops short of making a recommendation for a CRC algorithm. He mentions he likes the one used in PKZIP and PNG, but out of the dozens of options in http://en.wikipedia.org/wiki/Cyclic_redundancy_check http://en.wikipedia.org/wiki/Cyclic_redundancy_check that is not the one I would recommend. Instead CRC-32C, named after its designer Castagnoli, is probably the best choice: CRC-32C is the algorithm that Intel implemented in its processors ("CRC32" SSE4.2 instruction). CRC-32C is also used by both ext4 and btrfs for bit rot detection. The first and most prominent user of CRC-32C was iSCSI. Its mathematical definition (at least one of the most "official" definitions) is found in http://tools.ietf.org/html/rfc3720#section-12.1 http://tools.ietf.org/html/rfc3720#section-12.1 as a generator given in hex. The RFC gives 2 other references: an analysis where it was first published and discussed (http://ieeexplore.ieee.org/ielx1/26/5993/00231911.pdf?tp=&arnumber=231911&isnumber=5993 http://ieeexplore.ieee.org/ielx1/26/5993/00231911.pdf?tp=&ar...) and another RFC (http://tools.ietf.org/html/rfc3385 http://tools.ietf.org/html/rfc3385) that contains test vectors and implementations. However they are hardware implementations, not software. The number of documents you have to reference for a complete spec (definition + code + test vectors) is annoying... I share the author's frustration in regard to this. If you need more than 32 bits for an integrity check, a CRC is probably not what you need (want to prevent intentional malicious data tampering? use a crypto hash function).