Hoe checksumwaarden werken

Wat een checksum is

Een checksum (of controlecijfer) is opzettelijke redundantie. Wanneer een nummer wordt uitgegeven, worden één of meerdere van zijn cijfers niet willekeurig gekozen: ze worden uit de rest berekend volgens een vaste formule. Iedereen die de formule kent, kan later die cijfers opnieuw berekenen en vergelijken. Als ze overeenkomen, is het nummer intern consistent. Zo niet, dan is er een typefout gemaakt, is het verkeerd gelezen of is het beschadigd.

Dat is alles wat een checksum belooft. Het zegt niets over het bestaan van het account, wie de eigenaar is of wat erin zit – een punt dat elke validator op deze site benadrukt, omdat de twee gemakkelijk met elkaar worden verward.

Voorbeeld 1 – Luhn, het algoritme voor kaartnummers

Visa, Mastercard en de meeste andere betaalkaarten gebruiken Luhn. Neem het klassieke voorbeeld 7992 7398 713. Begin bij het rechterste cijfer en verdubbel elk tweede cijfer; als het verdubbelen een twee-cijferig getal oplevert, tel de cijfers van dat getal bij elkaar op. Som dan alles bij elkaar.

De kolom rechts opgeteld geeft 3 + 2 + 7 + 7 + 9 + 6 + 7 + 4 + 9 + 9 + 7 = 70. Zeventig is deelbaar door tien, dus het nummer is geldig. Verander één enkel cijfer en het totaal is niet langer een veelvoud van tien. Probeer het uit op de Creditcard validator – deze voert precies deze berekening uit op jouw apparaat.

Voorbeeld 2 – een gewogen som (ISBN-10)

Veel nationale identificatienummers gebruiken een gewogen som: vermenigvuldig elk cijfer met een vaste gewicht, tel ze bij elkaar op en controleer de rest. ISBN-10 is het duidelijkste voorbeeld. Voor 0-306-40615-2 lopen de gewichten van 10 tot 1:

0×10 + 3×9 + 0×8 + 6×7 + 4×6 + 0×5 + 6×4 + 1×3 + 5×2 + 2×1 = 132

132 is precies 11 × 12, dus de rest bij deling door 11 is nul en het ISBN is geldig. Het Braziliaanse CPF, het Poolse PESEL en tientallen andere identificatoren volgen hetzelfde patroon met hun eigen gewichten en modulus – daarom kan één ID-batchvalidator duizenden van zulke nummers in één seconde controleren.

Voorbeeld 3 – IBAN en mod 97

Internationale bankrekeningnummers gebruiken ISO 7064 mod 97-10, een robuuster systeem met twee controlecijfers. Neem het standaardvoorbeeld GB82 WEST 1234 5698 7654 32:

1. Controleer de lengte voor het land: een Brits IBAN bestaat uit 22 tekens. ✓
2. Verplaats de eerste vier tekens naar het einde: WEST12345698765432GB82.
3. Vervang elke letter door twee cijfers (A = 10 … Z = 35): W→32, E→14, S→28, T→29, G→16, B→11, waardoor je 3214282912345698765432161182 krijgt.
4. Dividéer dat getal door 97. De rest moet precies 1 zijn – en dat is ook zo.

Omdat 97 een priemgetal is en groter dan elke wisseling van twee cijfers, vangt mod 97 elke fout van één teken en elke verplaatsing op; slechts ongeveer één willekeurige reeks op de 97 zal toevallig door de controle komen. De IBAN-validator laat zien of elke van deze stappen slaagt of faalt.

Crypto-adressen: controlegetallen die zijn opgebouwd uit hashes

Bitcoin- en Ethereum-adressen stellen hoge eisen, want een typefout stuurt geld permanent naar niemand. Oudere Bitcoin-adressen (1…, 3…) maken gebruik van Base58Check: de adresgegevens worden tweemaal door SHA-256 gehaald en de eerste vier bytes van het resultaat worden als controlegetal toegevoegd. Één verkeerd teken verandert de hash volledig, waardoor de kans dat een typefout door de mazen heen glipt ongeveer één op vier miljard is. Nieuwere bc1…-adressen gebruiken Bech32 van Bech32m, een foutcorrigerende code die garandeert dat elke fout die tot vier tekens beïnvloedt wordt gedetecteerd. Bij Ethereum wordt het controlegetal via EIP-55 verborgen in het patroon van hoofd- en kleine letters.

De Bitcoin-adresvalidator en Ethereum-adresvalidator passen deze algoritmen in de browser toe en vergelijken zichzelf bij elke paginalading met de officiële testvectoren.

Overzicht van schema's