Can I have an example that show the vulnerability of CRC?

xeon123 · 04-10-2013, 08:38 AM

I was looking to the definition of checksum, and the wikipedia says the following about checksum:

" It is important to not use a checksum in a security related application, as a checksum does not have the properties required to protect data from intentional tampering."

So, I did a test. A did the ckecksum ofthe 2 samples:
This is a test => gives the checksum 4273069754

Tihs is a tset => gives the checksum 1653537507

This checksum are different, forcing me to make the assumption that the order of the bytes matter.

So, can I have an example that show the vulnerability of the checksum?

Noway2 · 04-10-2013, 08:57 AM

How are you defining checksum, and more importantly, what are you using to compute your checksum?

Generally speaking, checksums are mathematical algorithms designed to detect errors. Examples of Checksums including things like CRC, and Fletcher's Checksum, both of which have been well analyzed and have limits with regards to their ability to detect errors. For example, a 16 bit CRC computation will not reliably detect errors larger than 16 consecutive bits. One may argue that the probability of failing to detect is minute, but I have seen actual field failures in cases where the communications rate is high. Randomness has a way of making the unexpected happen. More modern forms of checksums would be considered things like md5 and sha1, which are one way transformations where given a particular input you will always get the same output. These functions are designed so that a small change in input produces a wide variation in output. They are also many to one transforms, meaning multiple inputs can correlate to the same output value, though the probabilities of finding them becomes very small.

xeon123 · 04-10-2013, 09:08 AM

I used the unix command cksum.

cksum - Print CRC checksum and byte counts of each FILE.

I'm talking about CRC.

linosaurusroot · 04-10-2013, 09:18 AM

CRC has these properties:
- If you control the last N bits of the data (e.g. 16 for a 16-bit CRC) then choosing the final CRC is trivial. CRC was never designed to provide security against tampering but is good against accidental communication errors that affect small ranges of consecutive bits.
- Two messages xor-ed together produce a CRC that is the xor of the two CRCs of the original messages.

xeon123 · 04-10-2013, 09:55 AM

1 - I'm sorry but I'm not understand in point 1, how choosing the CRC is trivial. Can you give an example?

2 - I trying to simulate point 2, and I couldn't do it. I have 3 files, a.txt, b.txt and c.txt. I tried to reproduce what you said, but I couldn't do it properly. What's wrong with my example:

Code:

:~$ cat a.txt 
hello

:~$ cat b.txt 
world

Code:

~$ cksum a.txt b.txt 
3015617425 6 a.txt
1576634217 6 b.txt

Code:

:~$ cat c.txt 
hello
world

Code:

:~$ cksum c.txt 
3795442390 12 c.txt

Code:

:~$ echo $((3015617425 ^ 1576634217))
3997641976