CRC Calculator

CRC Algorithms Reference

Cyclic Redundancy Check (CRC) is an error-detecting code used in data transmission and storage. Unlike cryptographic hashes, CRC is fast and lightweight, making it suitable for hardware-level error detection in communication protocols.

Supported CRC Types

CRC-16/CCITT (polynomial 0x1021): Used in X.25, Bluetooth, and ISO 14443 contactless communication. CRC-16/Modbus (polynomial 0xA001): Used in Modbus RTU for industrial control. CRC-16/XMODEM: Used in file transfer protocols. CRC-32 (polynomial 0xEDB88320): Used in Ethernet, ZIP, and PNG. CRC-16/KERMIT: Used in old modem protocols. Each CRC type uses a different polynomial, initial value, and input/output reflection settings.

In Smart Cards

In the smart card world, CRC-16/CCITT is used in ISO 14443-3 for contactless communication error detection (both Type A and Type B). T=1 protocol block frames use an LRC (Longitudinal Redundancy Check) or CRC depending on implementation. Modbus CRC is used in some industrial smart card readers. For cryptographic integrity (not just error detection), use SHA-256 or SM3 from our Hash Digest tool instead.

CRC Parameters Explained: Polynomial, Init, XorOut, Reflection

Every CRC variant is defined by five parameters. The polynomial is the core mathematical value — a bit pattern representing the coefficients of a binary polynomial used in modulo-2 division. Init is the starting value of the CRC register before processing data. XorOut is a value XORed with the final CRC before output — it prevents a message of all zeros from always producing a CRC of zero, which would be ambiguous. RefIn (reflect input) processes each input byte LSB-first instead of MSB-first. RefOut (reflect output) reverses the final CRC bits. These reflection parameters exist because different hardware implementations process bits in different orders — UARTs transmit LSB-first, while SPI is typically MSB-first. The combination of these five parameters for each CRC variant is catalogued in the CRC Catalog (reveng) maintained by the programming community.

CRC vs Cryptographic Hash: When to Use Which

CRC is an error-detection code, not a security mechanism. It detects random bit flips caused by noise, crosstalk, or storage degradation — but it is trivially forgeable. An attacker can modify data and recompute the CRC to match in milliseconds. A cryptographic hash (SHA-256, SM3) is designed to be one-way and collision-resistant: given a hash output, finding the input is computationally infeasible. Use CRC when you need fast, cheap integrity checking against accidental corruption (network frames, firmware images, file storage). Use a cryptographic hash when you need protection against intentional tampering (software signatures, payment data integrity, certificate fingerprints). The Crypto Checksum Verifier provides MAC/CMAC/Retail-MAC for cryptographic integrity in payment systems.

Table-Driven CRC Implementation

The naive CRC implementation processes one bit at a time, which is slow. The standard optimization is a 256-entry lookup table: precompute the CRC of every possible single byte (0x00-0xFF) at initialization, then during processing, look up each byte in the table and XOR it into the running CRC. This reduces the inner loop from 8 operations per bit to one table lookup and XOR per byte — roughly an 8x speedup. The table is only 256 entries for CRC-8/16/32 (512 bytes for CRC-64), so it fits in L1 cache. Our tool builds and caches the table on first use per variant. For embedded systems with extreme memory constraints, a 16-entry table (nibbles) can be used at a 2x speed cost.