Hash vs HMAC vs digitale handtekening: berichtintegriteit uitgelegd

Berichtintegriteit betekent dat ontvangen gegevens aantoonbaar gelijk zijn aan wat oorspronkelijk werd verzonden of opgeslagen. In de beginjaren van netwerkcommunicatie waren ruis, slechte kabels en beschadigde opslagmedia vaak de oorzaak van foutieve gegevensoverdracht, waardoor integriteitscontroles eerst ontstonden als praktische foutdetectie voor bits die onderweg of op een drager per ongeluk waren gewijzigd.

Laatst bijgewerkt: 2026. Deze herwerking corrigeert enkele verouderde of onnauwkeurige punten uit de oorspronkelijke tekst, waaronder de status van MD6 en de verhouding tussen SHA-2 en SHA-3.

Van pariteitsbit tot cryptografische hash

De vroegste technieken voor berichtintegriteit waren eenvoudig. Een pariteitsbit kon aangeven of een reeks bits waarschijnlijk een fout bevatte, en controlecijfers in catalogusnummers of betaalkaartnummers hielpen typefouten of transcriptiefouten opsporen. Later werden Cyclic Redundancy Checks, meestal CRC genoemd, breed gebruikt om fouten in bestanden, netwerkframes en opslagmedia te detecteren.

CRC is nuttig wanneer het risico vooral bestaat uit toevallige fouten. Het mechanisme is snel, goedkoop en goed in het vinden van typische transmissiefouten. Het is echter niet ontworpen om een aanvaller tegen te houden. Wie de inhoud bewust wijzigt, kan in veel situaties ook een nieuwe CRC berekenen die bij de gewijzigde inhoud past.

Cryptografische hashfuncties gaan een stap verder. Een hashfunctie verwerkt een bericht van willekeurige lengte en produceert een vaste uitvoer, de digest of vingerafdruk. Bij een goede cryptografische hash zorgt een kleine wijziging in de invoer voor een onvoorspelbaar andere uitvoer; gemiddeld verandert ongeveer de helft van de bits in de hashwaarde.

Een praktische manier om dit te bekijken is als een eenrichtingscontrole. De ontvanger berekent dezelfde hash over het ontvangen bericht en vergelijkt die met de verwachte hash. Komt de waarde overeen, dan is er sterke aanwijzing dat het bericht niet per ongeluk of ongemerkt is gewijzigd sinds de hash werd vastgesteld.

Welke eigenschappen maken een hash veilig?

Niet elke hashfunctie is geschikt voor beveiliging. Een cryptografische hash moet weerstand bieden tegen drie soorten aanvallen. Collision resistance betekent dat het praktisch onhaalbaar moet zijn om twee verschillende berichten met dezelfde hash te vinden. Preimage resistance betekent dat een aanvaller uit een hashwaarde niet haalbaar het oorspronkelijke bericht kan afleiden. Second-preimage resistance betekent dat een aanvaller, gegeven één specifiek bericht, niet haalbaar een ander bericht met dezelfde hash kan maken.

Deze eigenschappen verklaren waarom oudere algoritmen zoals MD4, MD5 en SHA-1 niet meer geschikt zijn voor nieuwe beveiligingstoepassingen. Ze kunnen nog in oude systemen voorkomen, maar mogen niet worden gekozen voor nieuwe ontwerpen. SHA-2, waaronder SHA-256 en SHA-512, blijft breed aanbevolen en is beschreven in NIST FIPS 180-4. SHA-3 is beschreven in NIST FIPS 202 en is gebaseerd op Keccak; het is een afzonderlijke standaard en geen gewone upgrade van SHA-2.

MD6 verdient een aparte verduidelijking. Het werd voorgesteld tijdens de zoektocht naar een volgende hashstandaard, maar werd niet gestandaardiseerd als SHA-3. In hedendaagse systemen zal een team daarom meestal uitkomen bij SHA-256, SHA-512 of SHA-3, afhankelijk van platformondersteuning, compliance-eisen en interoperabiliteit.

Waarom een gewone hash geen bescherming biedt tegen een aanvaller

Een veelgemaakte fout is een bericht samen met een losse hash over hetzelfde kanaal versturen en ervan uitgaan dat dit voldoende is voor beveiliging. Dat werkt tegen toevallige corruptie, maar niet tegen een actieve man-in-the-middle. Een aanvaller die het bericht kan wijzigen, kan meestal ook de bijgevoegde hash vervangen door een hash van het gewijzigde bericht.

Er is nog een subtielere valkuil bij bepaalde hashconstructies: length-extension attacks. Bij algoritmen zoals SHA-256 kan een onjuist gebruikspatroon, bijvoorbeeld hash(secret || message), kwetsbaar zijn wanneer een aanvaller genoeg informatie heeft om extra gegevens aan het bericht toe te voegen en een geldige nieuwe hash af te leiden. Dit is precies het soort probleem waarvoor HMAC is ontworpen.

HMAC, gespecificeerd in RFC 2104, combineert een cryptografische hash met een geheime sleutel op een manier die deze bekende valkuilen vermijdt. De ontvanger kan de HMAC alleen correct verifiëren als dezelfde gedeelde sleutel beschikbaar is. Daardoor bewijst een geldige HMAC niet alleen dat de inhoud niet is gewijzigd, maar ook dat de controlewaarde is gemaakt door iemand die de gedeelde sleutel bezit.

Het verschil tussen een gewone hash en HMAC kan zonder visueel schema duidelijk worden samengevat. Bij een gewone hash is de invoer alleen het bericht; iedereen kan dezelfde waarde opnieuw berekenen. Bij HMAC bestaat de invoer uit het bericht én een geheime sleutel; een buitenstaander kan het bericht lezen of wijzigen, maar kan zonder sleutel geen geldige nieuwe authenticatiecode maken.

Voorbeeld met SHA-256 en HMAC-SHA256

Onderstaand Python-voorbeeld toont het verschil tussen een gewone SHA-256-hash en een HMAC-SHA256. Het voorbeeld is bedoeld voor verificatiegedrag in kleine scripts, testomgevingen of lesmateriaal; in productie hoort de sleutel uit een secrets manager of vergelijkbare veilige bron te komen, niet hardcoded in broncode.

Voorbeeld — bericht verifiëren met SHA-256 en HMAC-SHA256

import hashlib
import hmac

message = b"factuur=2026-041;bedrag=1250;valuta=EUR"
shared_key = b"demo-key-voor-lokale-test"

sha256_digest = hashlib.sha256(message).hexdigest()
hmac_digest = hmac.new(shared_key, message, hashlib.sha256).hexdigest()

received_message = b"factuur=2026-041;bedrag=1250;valuta=EUR"
received_hmac = hmac.new(shared_key, received_message, hashlib.sha256).hexdigest()

print("SHA-256:", sha256_digest)
print("HMAC-SHA256:", hmac_digest)
print("HMAC geldig:", hmac.compare_digest(hmac_digest, received_hmac))

De gewone SHA-256-waarde is een vingerafdruk van de inhoud. De HMAC-waarde is sterker in een vijandige omgeving omdat de geheime sleutel nodig is om een geldige waarde te maken. De functie hmac.compare_digest wordt gebruikt omdat zij veilig vergelijkt zonder timinginformatie prijs te geven die bij gevoelige vergelijkingen relevant kan zijn.

Wanneer een digitale handtekening nodig is

HMAC is geschikt wanneer zender en ontvanger dezelfde geheime sleutel kunnen delen en beheren. Dat past bijvoorbeeld bij twee interne diensten, een API-integratie tussen vertrouwde partijen of een webhook waarbij de ontvanger moet controleren of het bericht echt door de verzendende dienst komt. De keerzijde is dat beide partijen dezelfde sleutel kennen. Daardoor kan een derde partij achteraf niet onafhankelijk bewijzen wie het bericht precies heeft gemaakt.

Digitale handtekeningen lossen een ander probleem op. De verzender ondertekent met een private sleutel, terwijl ontvangers met de publieke sleutel kunnen verifiëren dat de inhoud niet is gewijzigd en dat de handtekening bij de private sleutel hoort. Dit is nuttig wanneer meerdere partijen moeten kunnen verifiëren zonder allemaal dezelfde geheime sleutel te delen.

Daarom worden digitale handtekeningen gebruikt bij softwarepakketten, certificaten, documentondertekening en distributieprocessen waar herleidbaarheid en onafhankelijke verificatie belangrijk zijn. Voor softwaredownloads is een checksum alleen onvoldoende als die via hetzelfde kanaal als het pakket wordt verspreid. Een ondertekend pakket of een afzonderlijk verifieerbare handtekening biedt betere bescherming tegen manipulatie van distributiekanalen.

CRC, hash, HMAC of digitale handtekening kiezen

De juiste keuze hangt af van het dreigingsmodel. Een opslag- of netwerkfout vraagt een andere controle dan een API-aanroep die door een aanvaller kan worden onderschept. Teams die dit onderscheid overslaan, krijgen vaak schijnzekerheid: de controle werkt in een test, maar beschermt niet tegen de echte aanval die het systeem moet weerstaan.

In praktijk komt de keuze vaak neer op de vraag wie vertrouwd wordt en wie moet kunnen verifiëren. Als alleen fouten moeten worden gevonden, volstaat CRC vaak. Als een bestand met een bekende referentiewaarde wordt gecontroleerd, kan een cryptografische hash passen. Als twee systemen elkaar vertrouwen via een gedeeld geheim, is HMAC meestal de juiste stap. Als derden moeten kunnen controleren zonder een gedeeld geheim te kennen, ligt een digitale handtekening meer voor de hand.

Implementatiefouten die integriteit ondermijnen

Zelfs een sterk algoritme kan verkeerd worden toegepast. Een klassieke fout is dat het systeem niet exact dezelfde bytes verifieert als de bytes die werden bedoeld. Verschillen in karakterencoding, JSON-volgorde, witruimte, normalisatie van Unicode of hoofdlettergebruik in HTTP-headers kunnen ertoe leiden dat een geldig bericht wordt afgewezen of, erger, dat een ander bericht wordt geaccepteerd dan de ontwikkelaar verwachtte.

Daarom is canonicalisatie belangrijk. Voor er wordt gehasht, ge-HMAC’t of ondertekend, moet duidelijk zijn welke velden meetellen, in welke volgorde, met welke encoding en met welke representatie. Metadata verdient dezelfde aandacht. Een payload ondertekenen maar de tijdstempel, tenant-id, bestandsnaam of permissies buiten de bescherming laten, kan ruimte laten voor misbruik.

Sleutelbeheer is een tweede bron van fouten. HMAC-sleutels mogen niet worden hergebruikt voor verschillende protocollen, omgevingen of doeleinden zonder duidelijke scheiding. Een sleutel voor webhooks hoort bijvoorbeeld niet tegelijk te dienen voor interne serviceberichten. Afzonderlijke sleutels per context beperken schade bij lekken en maken rotatie eenvoudiger.

Een derde punt is algoritme-agility. Systemen moeten niet hard vastzitten aan één algoritme zonder migratiepad. Dat betekent niet dat elke aanvraag willekeurige algoritmen mag kiezen, maar wel dat configuratie, testvectors, documentatie en monitoring rekening houden met toekomstige deprecatie. Zo kan een organisatie overstappen wanneer standaarden of bibliotheken veranderen zonder het protocol volledig te herschrijven.

Oude bron, nieuwe context

De oorspronkelijke Engelstalige pagina bevatte vooral een inleiding op hashing en verwees naar vervolgmateriaal. Wie de oude context wil nalezen, vindt die via de bewaarde pagina over Kevin Henry. De commerciële verwijzingen uit die oudere pagina naar CISSP Overview en CISM Overview blijven hier behouden als archieflinks, maar de inhoudelijke kern is breder: berichtintegriteit vraagt een keuze op basis van dreiging, vertrouwen en verificatiebehoefte.

Berichtintegriteit toepassen zonder schijnzekerheid

Een goede integriteitscontrole begint niet bij het algoritme, maar bij de vraag wat er fout kan lopen. Toevallige corruptie, kwaadwillige wijziging, vervalste herkomst en betwistbare ondertekening zijn verschillende problemen. CRC, hash, HMAC en digitale handtekening lossen elk een deel van dat spectrum op.

De meest robuuste aanpak is sober en expliciet: kies moderne algoritmen zoals SHA-256, SHA-512 of SHA-3 waar cryptografische hashing nodig is, gebruik HMAC voor gedeelde-geheim-scenario’s, gebruik digitale handtekeningen wanneer onafhankelijke verificatie telt, en documenteer exact welke gegevens worden beschermd. Wie deze concepten verder wil plaatsen binnen governance, risico en securitycertificering kan gestructureerde training bij Readynez gebruiken als vervolgstap, maar de technische keuze blijft dezelfde: stem het integriteitsmechanisme af op het dreigingsmodel.