When is it appropriate to use CRC for error detection versus more modern hashing functions such as MD5 or SHA1? Is the former easier to implement on embedded hardware?
+1
A:
CRC32 is way faster and sometimes has hardware support (i.e. on Nehalem processors). Really, the only time you'd use it is if you're interfacing with hardware, or if you're really tight on performance
Paul Betts
2009-06-15 15:47:07
+11
A:
CRC works fine for detecting random errors in data that might occur, for example, from network interference, line noise, distortion, etc.
CRC is computationally much more efficient than MD5 or SHA1. Using a hash function like MD5 is probably overkill for random error detection. However, using CRC for any kind of security check would be much less secure than a more complex hashing function such as MD5.
And yes, CRC is much easier to implement on embedded hardware, you can even get different packaged solutions for this on IC.
Dustin Fineout
2009-06-15 15:51:21
I there a way of getting a 32-bit MD5 or SHA1 hash? As you said, 128 bits for error detection sounds a bit overkill. Why don't low-level communication protocols use MD5 or SHA1? Is it because the hash size is too big relative to the packet size?
Gili
2009-06-15 16:57:13
You cannot reduce MD5 or SHA1 to a 32-bit hash. Low-level protocols (I'm assuming link-layer and physical) are not concerned with security but only error detection and to a lesser extent correction. It comes back to efficiency as well - the cryptographic hash functions are just too much work to be doing for every frame when in the given context the focus is error detection, not security.
Dustin Fineout
2009-06-15 17:12:43
@gili: you can always just xor the dwords together to get a single resulting dword.
Blindy
2009-06-17 09:09:08
@Dustin: You are completely correct in your answer, but perhaps consider changing "CRC is computationally much more efficient" to "CRC is computationally much easier"? MD5/SHA-1 algorithms are complex, but not really 'inefficient' IMO.
Coxy
2009-12-03 08:49:55
@coxymla you are correct, the word I should have used is "complex" not "inefficient". Thanks!
Dustin Fineout
2010-01-02 23:53:17
To reduce any long hash to 32 bits, just take the first 32 bits.
orip
2010-05-24 20:44:22
+3
A:
CRC32 is faster and the hash is only 32bits long.
Use it when you just want a quick and light checksum. CRC is used in ethernet.
If you need more reliability it's preferable to use a modern hashing function.
François
2009-06-15 15:51:23
+7
A:
CRC is designed against unintentional changes in the data. That is, it's good for detecting unintentional errors, but will be useless as a way of making sure a data was not maliciously handled with.
Also see this.
Liran Orevi
2009-06-15 15:58:00
+1
A:
Only use CRC if computation resources are very tight (i.e. some embed environments) or you need to store/transport many output values and space/bandwidth is tight (as CRCs are usually 32-bit where an MD5 output is 128-bit, SHA1 160 bit, and other SHA variants up to 512 bit).
Never use CRC for security checks as a CRC is very easy to "fake".
Even for accidental error detection (rather than malicious change detection) hashes are better than a simple CRC. Partly because of the simple way a CRC is calculated (and partly because CRC values are usual shorter than common hash outputs so have a much smaller range of possible values) it is much more likely that, in a situation where there are two or more errors, one error will mask another so you end up with the same CRC despite two errors.
In short: unless you have reason not to use a decent hash algorithm, avoid simple CRCs.
David Spillett
2009-06-15 16:48:22
CRC will catch all accidental data changes if you are using a proper polynomial. 1/2^32 changes are missed if exactly the right multiple bits are changed.
Gerhard
2009-06-17 09:03:59
And with a proper polynomial it will also catch all errors of certain common classes, e.g. burst errors.
erikkallen
2009-06-17 09:35:00
I'd agree with your answer except the question is about embedded systems. Performance of a cryptographic algorithm can be problematic on smaller embedded systems.
Craig McQueen
2009-06-29 11:55:28
+1
A:
You do not say what it is that you are trying to protect.
A CRC is often used in embedded systems as a check against accidental data corruption as opposed to preventing malicious system modification. Examples of the places where a CRC can be useful is to validate an EPROM image during system initialisation to guard against firmware corruption. The system bootloader will calculate the CRC for the application code and compare with the stored value before allowing the code to run. This protects against the possibility of accidental program corruption or a failed download.
A CRC can also be used in a similar manner to protect configuration data stored in FLASH or EEPROM. If the CRC is incorrect then the data can be flagged as invalid and a default or backup data set used. The CRC may be invalid due to device failure or if the user removed power during an update of the configuration data store.
There have been comments that a hash provides greater probability of detecting corruption than a CRC with multiple bit errors. This is true, and the decision on whether or not to use a 16 or 32 bit CRC will hinge upon the safety consequences of a corrupted data block being used and whether you can justify the 1 in 2^16 or 2^32 chance of a data block being incorrectly declared valid.
Many devices have a built in CRC generator for standard algorithms. The MSP430F5X series from Texas have a hardware implementation of the CRC-CCITT Standard.
Ian
2009-06-16 12:16:39
+2
A:
For CRC information on implementation, speed and reliability see A painless guide to CRC error detection algorithms. It has everything on CRCs.
Unless somebody is going to try and modify your data maliciously and hide the change CRC is sufficient. Just use a "Good" (standard) polinomial.
Gerhard
2009-06-17 09:01:47