Comment by AlotOfReading
4 days ago
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
It's trivially easy to create a malicious file with the same CRC as another file.
So "verifying" using CRC is very stupid if you're trying to prevent malicious execution. You need to use cryptographic signatures.
The entire point of my post was that it's trivial, exactly as difficult as computing the CRC in the first place. Not sure why that was controversial.
Nevertheless, they're still useful protection against noise, and you usually want to detect it right as you're pulling protocol messages off the wire. Placing checksums in the last field of each message (as Ethernet does) simplifies the hardware implementation.
It's fairly trivial, but still significantly harder than computing a single CRC.
From stackoverflow:
Because a 32-bit CRC yields only 2³² (approx. 4.29 billion) possible outputs, the Birthday Paradox dictates a 50% chance of an accidental collision after processing just ~77,000 unique inputs.
I've done it for shits and giggles and from memory it took my desktop PC maybe 10 minutes to generate a collision.
You're missing the point though.
Noise is not the only thing they should be protecting against.
The point is that AMD is executing code based on checking using an algorithm that has barely any protection from malicious inputs, which is stupid, and not fixing it just compounds that stupidity.
A cryptographic signature protects against both noise and malicious inputs.
1 reply →