And can also give guaranteed distance properties-- so you can e.g. guarantee all corruption of hamming distance <D within a message size of <W will be detected, -- which is a massive improvement in performance when that's what you need to catch.
CRC's are many times faster when implemented in hardware, e.g. in a network interface card that checks the CRC of Ethernet data packets.
When computing a CRC in software, in a CPU that has instructions for both CRC and for SHA-1/SHA-256, e.g. a modern Intel/AMD CPU or a 64-bit ARM CPU, there remains a speed difference, but in most cases reading the data from the memory or from a SSD/HDD takes so much time that the difference in speed is negligible.
Moreover, until very recently most utilities that compute CRC's over files, e.g. UNIX cksum, did not use the special instructions for polynomial multiplication, but they used generic algorithms with precomputed tables.
The consequence was that for example most versions of cksum are much slower than the corresponding versions of sha1sum.
nullc|4 years ago
CorrectHorseBat|4 years ago
adrian_b|4 years ago
When computing a CRC in software, in a CPU that has instructions for both CRC and for SHA-1/SHA-256, e.g. a modern Intel/AMD CPU or a 64-bit ARM CPU, there remains a speed difference, but in most cases reading the data from the memory or from a SSD/HDD takes so much time that the difference in speed is negligible.
Moreover, until very recently most utilities that compute CRC's over files, e.g. UNIX cksum, did not use the special instructions for polynomial multiplication, but they used generic algorithms with precomputed tables.
The consequence was that for example most versions of cksum are much slower than the corresponding versions of sha1sum.