Editing Cyclic redundancy check (section)

== Data integrity ==
CRCs are specifically designed to protect against common types of errors on communication channels, where they can provide quick and reasonable assurance of the [[data integrity|integrity]] of messages delivered. However, they are not suitable for protecting against intentional alteration of data.

Firstly, as there is no authentication, an attacker can edit a message and recompute the CRC without the substitution being detected. When stored alongside the data, CRCs and cryptographic hash functions by themselves do not protect against ''intentional'' modification of data. Any application that requires protection against such attacks must use cryptographic authentication mechanisms, such as [[message authentication code]]s or [[digital signatures]] (which are commonly based on [[cryptographic hash]] functions).

Secondly, unlike cryptographic hash functions, CRC is an easily reversible function, which makes it unsuitable for use in digital signatures.<ref name="stigge-reversecrc">{{Cite web|last1=Stigge|first1=Martin|last2=Plötz|first2=Henryk|last3=Müller|first3=Wolf|last4=Redlich|first4=Jens-Peter|title=Reversing CRC – Theory and Practice|date=May 2006|page=17 |id=SAR-PR-2006-05 |publisher=Humboldt University Berlin|url=http://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2006-05/SAR-PR-2006-05_.pdf|access-date=4 February 2011|quote=The presented methods offer a very easy and efficient way to modify your data so that it will compute to a CRC you want or at least know in advance.|url-status=dead|archive-url=https://web.archive.org/web/20110719042902/http://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2006-05/SAR-PR-2006-05_.pdf|archive-date=19 July 2011}}</ref>

Thirdly, CRC satisfies a relation similar to that of a [[linear function]] (or more accurately, an [[affine function]]):<ref>{{cite web |title=algorithm design – Why is CRC said to be linear? |url=https://crypto.stackexchange.com/a/34013 |website=Cryptography Stack Exchange |access-date=5 May 2019}}</ref>

:<math>\operatorname{CRC}(x \oplus y) = \operatorname{CRC}(x) \oplus \operatorname{CRC}(y) \oplus c</math>

where <math>c</math> depends on the length of <math>x</math> and <math>y</math>. This can be also stated as follows, where <math>x</math>, <math>y</math> and <math>z</math> have the same length

:<math>\operatorname{CRC}(x \oplus y \oplus z) = \operatorname{CRC}(x) \oplus \operatorname{CRC}(y) \oplus \operatorname{CRC}(z);</math>

as a result, even if the CRC is encrypted with a [[stream cipher]] that uses [[Exclusive or|XOR]] as its combining operation (or [[Block cipher modes of operation|mode]] of [[block cipher]] which effectively turns it into a stream cipher, such as OFB or CFB), both the message and the associated CRC can be manipulated without knowledge of the encryption key; this was one of the well-known design flaws of the [[Wired Equivalent Privacy]] (WEP) protocol.<ref name="wep">{{Cite journal | last1=Cam-Winget | first1=Nancy | last2=Housley | first2=Russ | last3=Wagner | first3=David | last4=Walker | first4=Jesse | title=Security Flaws in 802.11 Data Link Protocols | journal=Communications of the ACM | volume=46 | issue=5 | pages=35–39 | date=May 2003 | doi=10.1145/769800.769823 | url=http://www.cs.berkeley.edu/~daw/papers/wireless-cacm.pdf | citeseerx=10.1.1.14.8775 | s2cid=3132937 | access-date=1 November 2017 | archive-date=26 May 2013 | archive-url=https://web.archive.org/web/20130526173938/http://www.cs.berkeley.edu/~daw/papers/wireless-cacm.pdf | url-status=live }}</ref>