SHA-1 vs SHA-256 vs SHA-512: Het juiste hash-algoritme kiezen in 2026

Open een TLS-certificaat, een Git-objectendatabase, een Bitcoin-blokheader, een Linux-pakketbeheerder en een Docker image manifest — in elk vind je een SHA-hash. Maar niet dezelfde SHA. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: de familie beslaat drie decennia, twee ontwerplijnen en een cruciale collision-aanval die het oudste lid in productie brak.

Deze gids brengt de volledige familie in kaart zodat je het juiste algoritme voor jouw gebruik kunt kiezen zonder twijfel.

Snelle beslisboom

Voordat je in de details duikt, hier de tabel die de meeste ontwikkelaars eigenlijk nodig hebben:

Jouw situatie	Beste keuze	Reden
TLS/HTTPS-certificaat	SHA-256 (minimum), SHA-384 voor hoge beveiliging	Verplicht door CA/Browser Forum Baseline Requirements
JWT-ondertekening (HMAC of RSA)	SHA-256 (HS256/RS256)	Universele ondersteuning; SHA-384/512 voor compliancevereisten
Software-integriteitscontrole	SHA-256	Industriestandaard; breed begrepen
Archief of langdurige integriteit	SHA-512	Grotere uitvoer, veilige marge voor de komende decennia
Content-adressering (IPFS, OCI)	SHA-256	De-facto standaard voor content-addressed opslag
Git (bestaande repo’s lezen/schrijven)	SHA-1 voor bestaand; SHA-256 voor nieuw via `--object-format=sha256`	Git is halverwege migratie; SHA-1 domineert nog
Samenwerken met Ethereum	Keccak-256 (niet NIST SHA-3)	Ethereum gebruikt de pre-standaardisatie Keccak-variant
Defense-in-depth of geclassificeerde systemen	SHA-384 of SHA-512	NSA Suite B; combineert met AES-256-GCM
Nieuwe code, geen legacy-beperkingen	SHA-3 (SHA3-256)	Andere ontwerplijn; geen length-extension-kwetsbaarheid
Wachtwoordopslag	Geen van bovenstaande	Gebruik bcrypt, Argon2id of scrypt — SHA is te snel

De SHA-familie in één oogopslag

Algoritme	Standaard	Uitvoerbits	Hex-tekens	Jaar	NIST-status	Primair gebruik vandaag
SHA-1	FIPS 180-4	160	40	1995	Verouderd (2011), ingetrokken voor digitale handtekeningen	Git legacy, vingerafdrukken
SHA-256	FIPS 180-4	256	64	2001	Actueel	TLS, JWT, Bitcoin, checksums
SHA-384	FIPS 180-4	384	96	2001	Actueel	Suite B, hoge-beveiliging TLS
SHA-512	FIPS 180-4	512	128	2001	Actueel	Archief, LUKS, HMAC-SHA-512
SHA-3 (elke variant)	FIPS 202	224/256/384/512	varieert	2015	Actueel	Alternatieve lijn, hardwareversnelling

SHA-1 en SHA-2 (de groep 256/384/512) delen een Merkle-Damgard-constructie. SHA-3 gebruikt een spons-constructie — een onderscheid dat meer uitmaakt dan het lijkt, verderop behandeld.

SHA-1: Gebroken maar niet dood

SHA-1 was het werkpaard van de jaren 2000. SSL-certificaten, S/MIME-e-mail, PGP-vingerafdrukken en Git kwamen er allemaal op samen. In februari 2017 publiceerden Google en CWI Amsterdam SHAttered: een chosen-prefix collision-aanval die twee afzonderlijke PDF-bestanden met identieke SHA-1-hashes produceerde. De aanval vereiste ongeveer 6,5 × 10^19 SHA-1-evaluaties — duur in 2017, betaalbaar vandaag met cloudcomputing.

NIST had SHA-1 al in 2011 verouderd verklaard voor digitale handtekeningen (NIST Special Publication 800-131A). De SHAttered-demonstratie versnelde de opruiming: browsers stopten in 2017 met het vertrouwen van SHA-1 TLS-certificaten, en het CA/Browser Forum maakte SHA-256 verplicht voor nieuwe uitgiftes.

Waarvoor SHA-1 nog wordt gebruikt:

Git-objectendatabase: Git is ontworpen rond SHA-1 als snelle content-hash, niet als beveiligingsprimitief. Het repository-formaat heeft 40-hex object-ID’s hardgecodeerd. Een migratiepad naar SHA-256 (git init --object-format=sha256) bestaat, maar adoptie gaat traag omdat elk hostingplatform, elke CI-tool en elke bestaande kloon synchroon moeten migreren.
Vingerafdrukken in legacy-systemen: Oude SSH host-key vingerafdrukken, PGP-sleutelvingerafdrukken en certificaatserienummerregelingen tonen nog SHA-1-waarden. Dit is informatief, niet beveiligingskritiek in de meeste contexten.

Wat te doen: Gebruik SHA-1 niet voor iets nieuws. Voor Git is het collision-risico laag bij typische softwareontwikkeling (een aanvaller moet beide bestanden in de collision kunnen beheersen), maar nieuwe projecten met --object-format=sha256 zijn de juiste langetermijnrichting.

Genereer een SHA-1-hash in je browser: SHA-1 Generator.

SHA-256: Het werkpaard

SHA-256 is het algoritme dat het internet draait in 2026. Elk TLS-certificaat uitgegeven door een publieke CA gebruikt SHA-256 voor de handtekeninghash. Elk JWT ondertekend met HS256, RS256 of ES256 gebruikt SHA-256 intern. Bitcoins proof-of-work is double-SHA-256. Docker content hashing is SHA-256. npm-pakketintegriteit gebruikt SHA-256.

De redenen zijn praktisch:

Beveiligingsmarge: 256 uitvoerbits betekent 2^128 bewerkingen voor een brute-force preimage-aanval — voorbij elke denkbare hardware voor de voorzienbare toekomst. Het werkelijke beveiligingsniveau ligt iets lager door birthday-bound collision-aanvallen (2^128 bewerkingen), maar nog steeds onneembaar.
Hardwareversnelling: SHA-256 is in silicium geïmplementeerd op elke Intel Goldmont+-CPU (SHA-NI-extensie), elk Apple silicon-chip, elke ARMv8-processor en dedicated ASICs in netwerkapparaten en opslagcontrollers. Via het hardwarepad overtreft SHA-256-doorvoer die van veel schijnbaar snellere software-alternatieven.
Alomtegenwoordige bibliotheekondersteuning: Elke TLS-bibliotheek, elke JWT-bibliotheek, elke standaardbibliotheek van elke taal implementeert SHA-256. Je stuit niet op een compatibiliteitsmuur.

Voor content-adressering, integriteitsverificatie en de meeste ondertekeningsworkflows is SHA-256 de juiste standaard, tenzij een specifieke norm anders vereist.

Genereer een SHA-256-hash in je browser: SHA-256 Generator.

SHA-384: De TLS-specialist

SHA-384 is SHA-512 afgekapt tot 384 bits. Het werd gemaakt om een 192-bit beveiligingsniveau te bieden (de helft van de uitvoergrootte is de collision-resistance-ondergrens) en opgenomen in NSA Suite B-cryptografie naast AES-256-GCM en P-384 elliptische-curve-sleutels.

Twee eigenschappen maken SHA-384 specifiek aantrekkelijk voor TLS:

Immuun voor length-extension bij deze uitvoergrootte: SHA-256 en SHA-512 zijn kwetsbaar voor length-extension-aanvallen — een aanvaller die H(geheim || bericht) kent kan H(geheim || bericht || uitbreiding) berekenen zonder het geheim te kennen. SHA-384 en SHA-512/256 zijn afgekapt uit de volledige interne toestand, waardoor length extension niet van toepassing is. Als je ruwe SHA-hashes als MAC’s gebruikt (in plaats van HMAC), is SHA-384 veiliger.
Suite B-compliance: Organisaties die moeten voldoen aan NSA/CNSA (Commercial National Security Algorithm) suite-vereisten moeten SHA-384 of SHA-512 gebruiken naast RSA-3072+, ECDH P-384 en AES-256. Als jouw klant een Amerikaanse federale instantie of aannemer is die onder FIPS 140-3-vereisten werkt, kan SHA-384 verplicht zijn.

SHA-384 is niet zinvol veiliger dan SHA-256 voor de meeste toepassingen — het praktische verschil tussen 128-bit en 192-bit collision-resistance is theoretisch op huidige rekenniveaus. Kies het wanneer compliance of de Suite B-koppeling het vereist, niet voor algemeen gebruik.

Genereer een SHA-384-hash in je browser: SHA-384 Generator.

SHA-512: Wanneer je meer bits nodig hebt

SHA-512 produceert een 512-bit (128-hex-teken) digest. Op 64-bit hardware is het vaak sneller dan SHA-256 omdat het algoritme opereert op 64-bit woorden in plaats van 32-bit woorden — SHA-256’s interne schema gebruikt 32-bit rekenkunde, terwijl SHA-512’s 64-bit rekenkunde gebruikt die efficiënter mappt op moderne CPU’s.

Benchmarks op 64-bit hardware (indicatief; browser Web Crypto API):

Algoritme	Benaderende doorvoer
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Opmerking: SHA-384 en SHA-512 delen dezelfde interne compressiefunctie en draaien daardoor even snel. SHA-256 is trager op 64-bit omdat het 32-bit woordformaat meer iteraties vereist om elk 512-bit berichtblok te verwerken. Op 32-bit of beperkte hardware is SHA-256 sneller.

SHA-512 is goed geschikt voor:

Archiefintegriteit: Checksums bedoeld om decennia te overleven profiteren van de grotere uitvoermarge.
Full-disk-encryptie: Linux LUKS gebruikt SHA-512 als de standaard sleutelafleiding PBKDF-hash (als component van PBKDF2, niet als zelfstandige hash).
HMAC-SHA-512: Gebruikt in sommige JWT-ondertekeningsregelingen (HS512) en API-authenticatie waarbij grotere MAC’s gewenst zijn.
Grote hoeveelheden pseudowillekeurige data genereren: Applicaties die een seed hashen en veel uitvoerbits nodig hebben kunnen SHA-512 gebruiken om het aantal hash-aanroepen te verminderen.

Genereer een SHA-512-hash in je browser: SHA-512 Generator.

SHA-3: Een andere ontwerpfilosofie

SHA-3 is niet SHA-2 met een grotere uitvoer. Het is een fundamenteel ander algoritme gebaseerd op een spons-constructie genaamd Keccak, ontworpen door Guido Bertoni, Joan Daemen, Michaël Peeters en Gilles Van Assche. NIST selecteerde het als winnaar van een zeven jaar durende publieke competitie (2007–2012) bedoeld om een hash-familie te produceren die als backup zou dienen als zwakheden werden gevonden in SHA-2’s Merkle-Damgard-constructie.

De spons-constructie werkt anders dan Merkle-Damgard:

De invoer wordt gevuld en gesplitst in blokken.
Elk blok wordt via XOR toegevoegd aan het eerste deel van een grote interne toestand (de “rate”), waarna de volledige toestand wordt gepermuteerd met de Keccak-f-permutatie.
Na het absorberen van alle invoer wordt de uitvoer “uitgeknepen” uit het rate-deel van de toestand.

Omdat de uitvoer slechts uit een deel van de toestand wordt gehaald en omdat het capaciteitsdeel nooit direct wordt blootgesteld, zijn spons-constructies inherent immuun voor length-extension-aanvallen zonder afkapping.

SHA-3-standaardvarianten (FIPS 202):

Variant	Uitvoerbits	Beveiligingsniveau
SHA3-224	224	112-bit
SHA3-256	256	128-bit
SHA3-384	384	192-bit
SHA3-512	512	256-bit
SHAKE128	variabel	128-bit
SHAKE256	variabel	256-bit

SHA-3 vs SHA-2 in de praktijk:

SHA-3 is nog niet breed ingezet in protocollen ontworpen voor 2015 — TLS, JWT en de meeste internetinfrastructuur gebruiken nog SHA-2. SHA-3 duikt op in post-quantum handtekeningschema’s (CRYSTALS-Dilithium, SPHINCS+ gebruiken SHA-3 intern), nieuwe protocolomgevingen die een back-up van een andere lijn willen, en hardware waar de Keccak-permutatie goed versnelt. In pure software is SHA-3 ruwweg 40% trager dan SHA-256 op x86.

Genereer een SHA-3-hash in je browser: SHA-3 Generator.

Het Ethereum Keccak-256-onderscheid

Een kritieke valkuil: Ethereum gebruikt niet NIST SHA-3. Ethereum werd ontworpen terwijl de Keccak-competitie nog gaande was en voordat NIST FIPS 202 finaliseerde. De Ethereum Virtual Machine gebruikt de originele Keccak-256-inzending, die andere padding gebruikt dan de definitieve NIST SHA-3-standaard.

Concreet:

NIST SHA3-256 voegt 0x06-padding toe voor het laatste blok.
Originele Keccak-256 (zoals gebruikt door Ethereum) voegt 0x01-padding toe.

Dezelfde invoer produceert verschillende hashes. NIST SHA3-256 aanroepen en Ethereums keccak256 aanroepen zijn niet uitwisselbaar. De meeste talen hebben beide: in Python is hashlib.sha3_256() NIST SHA-3; voor Keccak-256 zoals Ethereum het gebruikt, heb je een bibliotheek nodig zoals pysha3 (die keccak_256 implementeert). In JavaScript biedt de js-sha3-bibliotheek beide. De SHA-3 Generator implementeert NIST SHA3-256 — als je Ethereum Keccak-256-hashes nodig hebt, gebruik dan een Ethereum-specifieke tool.

Prestatiereferenties

De onderstaande getallen zijn indicatief voor de browser Web Crypto API op een moderne x86-64-laptop. De werkelijke doorvoer varieert met hardware, berichtgrootte en of het platform een hardwareversnellingspad gebruikt.

Algoritme	Streaming-doorvoer (64-bit)
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Voor kleine berichten (API-tokens, checksums onder enkele KB) voltooien alle algoritmen in minder dan 2 µs — het verschil is onzichtbaar. Voor grote data (tarballs, schijfkopieën) verslaan SHA-384/512 SHA-256 op 64-bit systemen omdat ze op 64-bit woorden opereren. SHA-3 is trager in pure software; geef de voorkeur aan SHA-2 in doorvoerkritieke code tenzij hardwareversnelling voor Keccak beschikbaar is. De doorvoer van SHA-1 is nooit een reden om het te gebruiken.

Veelgemaakte valkuilen

Codering-mismatch

SHA opereert op bytes. Als je de string "hello" hasht in een browser waar JavaScript hem als UTF-16 codeert in plaats van UTF-8, krijg je een andere digest dan een Python-script dat str.encode("utf-8") gebruikt. Normaliseer altijd naar UTF-8 voor je tekst hasht.

Een consistent patroon:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

Ontbrekende salting bij MAC’s

Een ruwe SHA-hash als message authentication code gebruiken (H(geheim || bericht)) is kwetsbaar voor length-extension-aanvallen op SHA-256 en SHA-512. Gebruik in plaats daarvan HMAC (RFC 2104): HMAC-SHA256(sleutel, bericht). HMAC omhult de hash met een inwendige en uitwendige gesleutelde pad die uitbreidingsaanvallen voorkomt.

Length-extension op SHA-256

Als je een API-handtekening opbouwt als SHA256(geheim + payload), kan een aanvaller die de resulterende hash kent SHA256(geheim + payload + aanvaller_uitbreiding) berekenen zonder het geheim te kennen. Oplossing: gebruik HMAC, of gebruik SHA-3 (immuun door constructie), of gebruik SHA-384/SHA-512/256 (immuun door afkapping).

Keccak-256 verwarren met NIST SHA-3

Zoals hierboven beschreven: Ethereum gebruikt Keccak-256 met 0x01-padding; NIST SHA3-256 gebruikt 0x06-padding. Ze produceren verschillende uitvoer van dezelfde invoer. Controleer welke variant je bibliotheek implementeert voor je integreert met Ethereum-contracten of Solidity ABI-codering.

SHA gebruiken voor wachtwoorden

SHA-algoritmen zijn ontworpen om snel te zijn. Dat is precies de verkeerde eigenschap voor wachtwoordopslag: een GPU-cluster kan miljarden SHA-256-hashes per seconde berekenen, waardoor een woordenboekaanval op een SHA-gehashte wachtwoorddatabase praktisch wordt. Gebruik voor wachtwoorden een memory-hard sleutelafleiding: Argon2id (aanbevolen), bcrypt of scrypt. Sla wachtwoorden nooit op als ruwe SHA-hashes, ook niet gezouten.

Veelgestelde vragen

Wat is het verschil tussen SHA-1 en SHA-256?

SHA-1 en SHA-256 zijn allebei Merkle-Damgard-hashfuncties gestandaardiseerd in FIPS 180-4, maar SHA-256 produceert een 256-bit digest tegenover SHA-1’s 160-bit digest. Wat nog belangrijker is: SHA-1 is gebroken. Een collision-aanval in de echte wereld (SHAttered, 2017) demonstreerde twee afzonderlijke PDF-bestanden met dezelfde SHA-1-hash. SHA-256 heeft geen bekende collision-aanvallen en biedt een 128-bit collision-resistance-niveau. Gebruik SHA-256 voor alles wat integriteitsgaranties vereist; gebruik SHA-1 niet voor nieuw werk.

Is SHA-512 sneller dan SHA-256?

Op 64-bit hardware ja, vaak met 30–40% voor grote invoer. SHA-512 gebruikt 64-bit woordrekenkunde, die moderne CPU’s native verwerken. SHA-256 gebruikt 32-bit woordrekenkunde, waarvoor twee keer zoveel bewerkingen per berichtblok nodig zijn op dezelfde hardware. Op 32-bit platforms of beperkte microcontrollers is SHA-256 sneller. Voor korte berichten (onder enkele KB) is het verschil onmerkbaar.

Moet ik migreren van SHA-1 naar SHA-256?

Voor digitale handtekeningen, TLS-certificaten en code signing: ja, absoluut — SHA-1 is verouderd en actief gebroken. Voor Git-repositories: het migratiepad bestaat (git init --object-format=sha256), maar adoptie gaat traag vanwege ecosysteem-coördinatievereisten; het collision-risico voor typisch repositorygebruik is laag. Voor informatieve vingerafdrukken (SSH host-key weergave): de beveiligingsblootstelling is minimaal, maar migreren naar SHA-256 is goede hygiëne.

Kan SHA-256 worden omgekeerd?

Nee. SHA-256 is door ontwerp een eenrichtingsfunctie. Met een hash kun je de originele invoer wiskundig niet terugvinden. Wat aanvallers kunnen doen is een woordenboek- of brute-force-aanval uitvoeren: miljoenen kandidaat-invoeren hashen en vergelijken. Voor invoer met lage entropie (korte strings, veelgebruikte wachtwoorden, opeenvolgende nummers) maken voorberekende rainbow tables dit praktisch. Voor invoer met hoge entropie (willekeurige UUID’s, grote bestanden) is omkering rekenkundig niet haalbaar. Daarom is SHA alleen ongeschikt voor wachtwoorden — je hebt een trage, gezouten KDF nodig.

Wanneer moet ik SHA-3 gebruiken in plaats van SHA-2?

SHA-3 is geschikt wanneer: (a) je een hash wilt van een andere ontwerplijn als verzekering tegen toekomstige SHA-2-zwakheden; (b) je protocol length-extension-immuniteit vereist zonder HMAC te gebruiken; (c) je post-quantum handtekeningschema’s implementeert die SHA-3 intern specificeren; of (d) je hardwareversnelling voor Keccak hebt en doorvoer nodig hebt. Voor de meeste alledaagse toepassingen (TLS, JWT, checksums) heeft SHA-256 bredere ecosysteemondersteuning en is het de pragmatische standaard. SHA-3 is niet veiliger dan SHA-2 bij equivalente uitvoergroottes — het is een andere gok op langetermijnbeveiliging.

Waarom gebruikt Ethereum Keccak-256 in plaats van NIST SHA-3?

Ethereum werd ontworpen in 2013–2014, voordat NIST FIPS 202 publiceerde (augustus 2015) ter finalisering van de SHA-3-standaard. Destijds werd de Keccak-inzending beschouwd als waarschijnlijke winnaar, en Ethereums auteurs gebruikten het direct. Toen NIST de standaard finaliseerde, veranderden ze de domeinscheidingspadding van 0x01 (originele Keccak) naar 0x06, waardoor andere uitvoer werd geproduceerd van dezelfde invoer. Ethereum was al ingezet met de originele Keccak-padding en kon dit niet meer wijzigen. Dus “Ethereum keccak256” en “NIST SHA3-256” zijn verschillende algoritmen ondanks dat ze dezelfde onderliggende Keccak-f-permutatie delen.

Probeer de tools: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — alles draait in je browser, geen data verlaat je apparaat.

SHA-1 vs SHA-256 vs SHA-512: hash-algoritme 2026