Crypto Checksum Verifier

Crypto Checksum Verification

Cryptographic checksums verify data integrity using hash functions or MAC algorithms. Unlike simple checksums (like IP/TCP checksums), cryptographic checksums are designed to be collision-resistant, meaning it is computationally infeasible to find two different inputs producing the same checksum output. In smart card protocols, checksums serve two roles: data integrity (detecting transmission errors in APDU data) and data authenticity (verifying that the data was produced by someone who knows the secret key).

CRC: Error Detection, Not Security

CRC (Cyclic Redundancy Check) is an error-detecting code, not a cryptographic hash. It detects accidental bit flips from noise or interference — a CRC-16 catches 100% of single-bit errors and 99.99% of multi-bit errors. But CRCs are linear: an attacker can modify data and adjust the CRC to match with simple algebra. Never use CRC for security — use it only for transmission integrity over noisy channels. In smart cards, CRC-16 is used in T=1 protocol block integrity, EMV data integrity (TLV encoding), and SIM file structures.

CRC Variants and Their Differences

CRC-16 comes in many variants that differ in polynomial, initial value, and bit reflection. CRC-16/XMODEM uses polynomial 0x1021 with init=0x0000 — the simplest variant, commonly used in file transfer protocols. CRC-16/CCITT-FALSE uses the same polynomial but init=0xFFFF — widely used in telecommunications and smart card T=1 blocks. CRC-16/ARC uses polynomial 0x8005 with init=0x0000 — common in legacy PC software and Modbus. CRC-32 uses polynomial 0xEDB88320 (reflected) with init=0xFFFFFFFF and final XOR — used in ZIP, Ethernet, and PNG files. Always verify which CRC variant your system expects, as the same data produces different checksums under different parameters.

LRC: The Simplest Checksum

LRC (Longitudinal Redundancy Check) is a single-byte XOR of all bytes in the data. It is used in ISO 1155 T=1 block protocol for APDU transmission between card and reader. LRC catches all single-bit errors and most multi-bit errors, but provides no security. A malicious party can trivially forge a valid LRC. LRC is also used in financial transaction protocols (ISO 8583) as a quick integrity check.

Retail-MAC: ISO 9797-1 Algorithm 3

Retail-MAC is the standard MAC algorithm in GlobalPlatform SCP02. It uses 3DES in CBC mode with a 16-byte (double-length) key. The algorithm encrypts each 8-byte block of padded data with 3DES-CBC, chaining the results. The final block's ciphertext (truncated to 8 bytes) is the MAC. This tool implements ISO 9797-1 Algorithm 3, which uses two DES keys (K1, K2) from the 16-byte key. Retail-MAC is deprecated in favor of AES-CMAC in SCP03, but remains widely used in legacy card systems.

AES-CMAC: The Modern Standard

AES-CMAC (RFC 4493, NIST SP 800-38B) is the MAC algorithm used in SCP03 and modern smart card systems. It produces a 16-byte MAC from arbitrary-length data using an AES key. AES-CMAC works by generating two subkeys (K1, K2) from the AES key, padding the input, and chaining AES-CBC encryptions with XOR. The subkey generation uses a GF(2^128) multiplication (left-shift with conditional XOR of the constant 0x87). AES-CMAC is provably secure as a PRF (pseudorandom function) under the assumption that AES is a good block cipher. For full KDF (key derivation function) usage in SCP03, AES-CMAC is called in counter mode as specified by NIST SP 800-108.

Choosing the Right Checksum

For error detection (noise, interference): use CRC-16 or CRC-32. For authentication (preventing tampering): use Retail-MAC (SCP02/3DES) or AES-CMAC (SCP03/AES). For file integrity verification: use SHA-256 or SM3 hashes (see our Hash Digest Calculator). For keyed authentication where the verifier and prover share a secret key: use HMAC (see our HMAC Generator). Always use the algorithm mandated by your protocol specification — mixing algorithms between SCP02 and SCP03 will break secure messaging.