Versleuteling uitgelegd: van AES tot post-quantumcryptografie en end-to-end berichten

Elk bericht dat je verstuurt, elke betaling die je doet en elk wachtwoord dat je typt leunt op versleuteling. Het is de onzichtbare laag die het digitale leven privé houdt — en ze zit in vrijwel elke applicatie waar je zaak van afhangt. Dit artikel legt uit hoe verschillende soorten versleuteling echte applicaties beschermen, waarom opkomende technieken als elliptische krommen en post-quantumalgoritmen ertoe doen voor je producten, en wat het recente besluit van Instagram om end-to-end-versleuteling te laten vallen zegt over de spanning tussen privacy en regelgeving.

Wat versleuteling werkelijk doet

Versleuteling zet leesbare gegevens (leesbare tekst) om in een onleesbare vorm (cijfertekst) met een geheime waarde die de sleutel heet. Alleen wie de juiste sleutel bezit kan het proces omkeren en de oorspronkelijke gegevens terughalen.

Twee eigenschappen tellen het zwaarst:

• Vertrouwelijkheid — een aanvaller die de cijfertekst onderschept leert niets over de leesbare tekst.
• Integriteit — moderne versleutelingsschema's merken bovendien op wanneer er onderweg met de cijfertekst is geknoeid.

Alle praktische versleuteling valt in een van twee families: symmetrisch en asymmetrisch. Echte systemen gebruiken ze samen, en begrijpen waarom helpt je onderbouwde keuzes te maken over de applicaties die je bouwt of gebruikt.

Symmetrische versleuteling: het werkpaard van gegevensbescherming

Bij symmetrische versleuteling wordt dezelfde sleutel gebruikt om te versleutelen en te ontsleutelen. Zie het als een kluis met één cijfercombinatie: iedereen die de combinatie kent kan hem openen, en die combinatie geheim houden is wat de inhoud beschermt.

Waar je het dagelijks tegenkomt

AES (Advanced Encryption Standard) is de meest gebruikte symmetrische versleuteling ter wereld. In 2001 door NIST aangenomen, ondersteunt hij sleutellengtes van 128, 192 of 256 bits en wordt hij door vrijwel elke moderne processor in hardware versneld.

Zo beschermt AES je gegevens in de praktijk:

• Cloudopslag. Upload je bestanden naar AWS S3, Google Cloud Storage of Azure Blob Storage, dan worden ze in rust met AES-256 versleuteld. Zelfs wie fysiek bij de opslaghardware komt, leest de gegevens niet zonder de sleutel.
• Databaseversleuteling. PostgreSQL, MongoDB en MySQL bieden alle drie versleuteling op basis van AES om gegevens op schijf te beschermen. Een gestolen databaseback-up is daarmee waardeloos zonder de sleutels.
• HTTPS en TLS. Elke keer dat je browser een hangslotje toont, doet AES het zware werk. TLS 1.3 gebruikt AES-GCM (Galois/Counter Mode) als belangrijkste versleuteling — het versleutelt gegevens en controleert tegelijk de integriteit ervan, en beschermt zo alles van inloggegevens tot API-aanroepen.
• Mobiele applicaties. Zowel de bestandsversleuteling van Android als Data Protection van Apple gebruikt AES-256 om gegevens op het toestel te versleutelen. Vergrendelt een gebruiker zijn telefoon, dan worden de sleutels uit het geheugen verwijderd en zijn de opgeslagen gegevens onbereikbaar.
• Betalingsverwerking. PCI DSS — de beveiligingsstandaard voor het verwerken van kaartgegevens — vereist AES-versleuteling voor kaarthoudergegevens, zowel onderweg als in rust.

ChaCha20-Poly1305 is een andere symmetrische versleuteling die terrein wint. Hij is sneller dan AES op toestellen zonder hardwareversnelling voor AES — vooral oudere smartphones en IoT-apparaten. Google koos hem voor TLS-verbindingen op Android, en het is de standaardversleuteling in WireGuard VPN.

Probeer het zelf: AES-versleuteling in je terminal

Je hebt geen speciale software nodig — OpenSSL staat standaard op macOS, Linux en de meeste serveromgevingen. Open een terminal en probeer deze commando's.

Versleutel een bericht met AES-256:

echo "I want to secure my app with AES" | openssl enc -aes-256-cbc -a -salt -pass pass:nerdy_pro

De uitvoer is een blok willekeurig ogende Base64-tekst — je versleutelde cijfertekst. Om het te ontsleutelen neem je die uitvoer en draai je:

echo "U2FsdGVkX181dnX8SWIhZTumWK0Uc7Kh947omVSNpH8lujB43L5OjlubfkGa3Y1dyxj5cfzyPZjhWiyGzIWdPw==" | openssl enc -aes-256-cbc -a -d -salt -pass pass:nerdy_pro

Je krijgt je oorspronkelijke bericht terug. OpenSSL toont mogelijk een waarschuwing: *** WARNING : deprecated key derivation used. — dat is te verwachten. Het betekent dat OpenSSL bij -pass pass: op een oudere methode voor sleutelafleiding terugvalt. In productie zou je -pbkdf2 gebruiken voor sterkere afleiding, maar voor deze demonstratie volstaat de standaard.

Je kunt ook hele bestanden versleutelen:

# Encrypt
openssl enc -aes-256-cbc -salt -in report.pdf -out report.pdf.enc -pass pass:nerdy_pro

# Decrypt
openssl enc -aes-256-cbc -d -in report.pdf.enc -out report-decrypted.pdf -pass pass:nerdy_pro

Het probleem van sleuteldistributie

Symmetrische versleuteling is snel en efficiënt, maar beide partijen moeten dezelfde geheime sleutel delen voordat ze kunnen communiceren. Bedient je applicatie een miljoen gebruikers, dan kun je niet vooraf een miljoen verschillende sleutels veilig delen. Precies dat probleem lost asymmetrische cryptografie op.

Asymmetrische versleuteling: vertrouwen tussen vreemden

Asymmetrische versleuteling gebruikt een sleutelpaar: een publieke sleutel die je vrijelijk mag delen, en een private sleutel die geheim moet blijven. Gegevens die met de publieke sleutel zijn versleuteld, kunnen alleen met de bijbehorende private sleutel worden ontsleuteld.

RSA: het fundament van internetbeveiliging

RSA, gepubliceerd in 1977, was het eerste praktische cryptosysteem met publieke sleutels. De veiligheid rust op de moeilijkheid van het ontbinden van het product van twee zeer grote priemgetallen — een probleem dat makkelijk op te zetten en met huidige technologie vrijwel onmogelijk om te keren is.

Zo drijft RSA echte applicaties aan:

• SSL- en TLS-certificaten. Bezoek je een website via HTTPS, dan toont de server een certificaat ondertekend met RSA (of ECC). Je browser verifieert die handtekening om te bevestigen dat je met de echte server praat en niet met een bedrieger. Certificaatautoriteiten als Let's Encrypt geven miljoenen met RSA ondertekende certificaten uit.
• Code ondertekenen. Download je een app uit de Apple App Store of installeer je een Windows-applicatie met een digitale handtekening, dan verifiëren RSA-handtekeningen dat er sinds de publicatie niet met de code is geknoeid.
• E-mailversleuteling. PGP/GPG en S/MIME gebruiken RSA om e-mails te versleutelen en te ondertekenen, en borgen zo zowel privacy als de echtheid van de afzender.
• SSH-toegang. Systeembeheerders gebruiken RSA-sleutelparen om zonder wachtwoord veilig bij servers te komen — ssh-keygen -t rsa is een van de meest gebruikte commando's in elke DevOps-werkstroom.

Probeer het zelf: RSA-versleuteling in je terminal

Genereer een RSA-sleutelpaar:

# Generate a 2048-bit private key
openssl genrsa -out private.pem 2048

# Extract the public key
openssl rsa -in private.pem -pubout -out public.pem

Versleutel nu een bericht met de publieke sleutel en ontsleutel het met de private:

# Encrypt — anyone with your public key can do this
echo "I want to secure my app with RSA" | openssl pkeyutl -encrypt -pubin -inkey public.pem -out message.enc

# Decrypt — only the private key holder can do this
openssl pkeyutl -decrypt -inkey private.pem -in message.enc

Dat is de kerngedachte: je zakenpartner versleutelt gegevens met jouw publieke sleutel, stuurt de cijfertekst over welk kanaal dan ook (zelfs e-mail), en alleen jij kunt het lezen. Zonder de private sleutel is het versleutelde bestand waardeloos.

De hybride aanpak

In de praktijk is asymmetrische versleuteling te traag om grote hoeveelheden gegevens te versleutelen. Echte systemen gebruiken daarom een hybride aanpak: RSA (of ECC) wisselt veilig een eenmalige symmetrische sleutel uit, en daarna verzorgt AES de bulkversleuteling op hoge snelheid. Precies zo werken TLS, SSH en PGP onder de motorkap.

Cryptografie met elliptische krommen: sterkere beveiliging, kleinere sleutels

Cryptografie met elliptische krommen (ECC) bereikt hetzelfde beveiligingsniveau als RSA met dramatisch kleinere sleutels. Dat vertaalt zich rechtstreeks in snellere verbindingen, kleinere certificaten, minder bandbreedte en betere prestaties op mobiele en IoT-apparaten.

Het praktische verschil

Een ECC-sleutel van 256 bits biedt dezelfde bescherming als een RSA-sleutel van 3072 bits — een twaalfvoudige verkleining van de sleutel. Voor applicaties die duizenden verbindingen per seconde afhandelen of op batterijen draaien, is dat verschil aanzienlijk.

Waar ECC vandaag wordt gebruikt

• TLS 1.3. De nieuwste versie van TLS gebruikt uitsluitend sleuteluitwisseling op basis van ECC (ECDHE). Sleuteluitwisseling met RSA is volledig verwijderd. Elke moderne HTTPS-verbinding die je maakt gebruikt elliptische krommen.
• Signal en WhatsApp. Het Signal-protocol gebruikt Curve25519 — een elliptische kromme ontworpen op hoge prestaties en bestendigheid tegen implementatiefouten — voor de sleuteluitwisseling. Dat is hetzelfde protocol dat berichten van meer dan twee miljard WhatsApp-gebruikers beschermt.
• WireGuard VPN. WireGuard gebruikt Curve25519 voor alle sleuteluitwisselingen, wat bijdraagt aan de reputatie van een eenvoudiger en sneller VPN dan OpenVPN of IPsec.
• SSH-sleutels. Ed25519 — een handtekeningschema met een elliptische kromme — is het aanbevolen sleuteltype voor SSH geworden. Het levert kortere sleutels en snellere handtekeningen dan RSA: ssh-keygen -t ed25519 genereert een sleutel die zowel veiliger als handiger is dan de oudere RSA-standaard.
• Cryptovaluta. Bitcoin en Ethereum gebruiken de elliptische kromme secp256k1 om elke transactie te ondertekenen. Verstuur je cryptovaluta, dan bewijst een ECC-handtekening dat je de portemonnee bezit zonder je private sleutel prijs te geven.
• Inloggen met Apple en Google. Inloggen met Apple gebruikt ECC (P-256) voor zijn identiteitstokens. Cloud KMS van Google ondersteunt ECC-sleutels om te ondertekenen en te verifiëren.

Probeer het zelf: ECC-sleutels in je terminal

Genereer een sleutelpaar met een elliptische kromme en vergelijk het met RSA:

# Generate an ECC private key (Curve P-256)
openssl ecparam -genkey -name prime256v1 -noout -out ec-private.pem

# Extract the public key
openssl ec -in ec-private.pem -pubout -out ec-public.pem

# Compare file sizes — ECC keys are dramatically smaller
wc -c private.pem ec-private.pem

Je ziet dat de private ECC-sleutel ongeveer vier tot vijf keer kleiner is dan de RSA-sleutel, bij gelijkwaardige beveiliging. Op een server die duizenden TLS-handdrukken per seconde afhandelt, telt dat verschil snel op.

Digitale handtekeningen en controlegetallen: echtheid en integriteit bewijzen

Versleuteling houdt gegevens geheim, maar twee even belangrijke vragen blijven staan: wie stuurde deze gegevens? en zijn ze onderweg gewijzigd? Digitale handtekeningen en controlegetallen beantwoorden die vragen — en ze zijn net zo fundamenteel voor applicatiebeveiliging als versleuteling zelf.

Controlegetallen en CRC's: onbedoelde beschadiging opmerken

Een controlegetal is een korte waarde berekend uit een blok gegevens. Verandert er ook maar één bit, dan verandert het controlegetal mee. De eenvoudigste vorm is de CRC (Cyclic Redundancy Check) — een snel algoritme ontworpen om onbedoelde fouten bij overdracht of opslag te vangen.

Je gebruikt CRC's vaker dan je denkt:

• Bestanden downloaden. Download je een Linux-ISO of een softwarepakket, dan noemt de website vaak een SHA-256- of MD5-controlegetal. Je berekent het controlegetal van je gedownloade bestand en vergelijkt — komen ze overeen, dan is het bestand intact aangekomen.
• Netwerkprotocollen. Ethernetframes, TCP-pakketten en ZIP-bestanden bevatten allemaal CRC-controlegetallen om beschadiging tijdens overdracht te merken.
• Databasereplicatie. Systemen als PostgreSQL gebruiken controlegetallen om beschadiging op schijf te merken voordat die zich naar replica's verspreidt.
• Git. Elke commit, elk bestand en elke boom in een Git-repository wordt geïdentificeerd door een SHA-1-hash. Daarom kan Git elke wijziging in de geschiedenis van de repository opmerken.

Probeer het in je terminal:

# Create a file and compute its SHA-256 checksum
echo "I want to secure my app with checksums" > document.txt
shasum -a 256 document.txt

# Modify even one character and the checksum changes completely
echo "I want to secure my app with Checksums" > document.txt
shasum -a 256 document.txt

De twee controlegetallen zijn volstrekt verschillend — niet net iets anders, maar volledig onherkenbaar ten opzichte van elkaar. Die eigenschap heet het lawine-effect, en die maakt controlegetallen betrouwbaar om wijzigingen op te merken.

Belangrijk onderscheid: CRC's en eenvoudige controlegetallen merken onbedoelde beschadiging op — ze beschermen niet tegen opzettelijk knoeien. Een aanvaller die een bestand wijzigt kan het controlegetal simpelweg opnieuw berekenen. Om je tegen opzettelijke wijziging te verdedigen heb je cryptografische handtekeningen nodig.

Digitale handtekeningen: bewijzen wie de gegevens stuurde

Een digitale handtekening gebruikt asymmetrische cryptografie in omgekeerde richting: in plaats van versleutelen met de publieke sleutel en ontsleutelen met de private, ondertekent de afzender een bericht met zijn private sleutel, en kan iedereen met de publieke sleutel de handtekening verifiëren.

Dat geeft je twee garanties:

• Authenticatie — het bericht is gemaakt door de houder van de private sleutel en door niemand anders.
• Integriteit — het bericht is na ondertekening niet gewijzigd.

Digitale handtekeningen zitten overal in productiesystemen:

• Software-updates. Installeert je telefoon een iOS- of Android-update, dan verifieert het besturingssysteem de digitale handtekening van Apple of Google voordat het hem toepast. Een gewijzigde update zonder geldige handtekening wordt geweigerd — de belangrijkste verdediging tegen kwaadaardige firmware.
• API-authenticatie. JWT's (JSON Web Tokens) voor API-authenticatie zijn digitaal ondertekend. Ontvangt je backend een JWT, dan verifieert hij de handtekening om te bevestigen dat het token door je authenticatieserver is uitgegeven en er niet mee is geknoeid.
• Pakketbeheerders. npm, PyPI, Docker Hub en APT gebruiken allemaal handtekeningen om te verifiëren dat pakketten door de opgegeven auteurs zijn gepubliceerd. Aanvallen op de toeleveringsketen — zoals het beruchte event-stream-incident — buiten gaten in die verificatie uit.
• Blockchaintransacties. Elke Bitcoin- of Ethereum-transactie wordt met de private sleutel van de afzender ondertekend. Het netwerk verifieert de handtekening voordat het de transactie accepteert — zo werkt cryptovaluta zonder centrale autoriteit.
• Documenten ondertekenen. PDF-documenten, contracten en facturen kunnen digitale handtekeningen dragen die het auteurschap bewijzen en wijzigingen opmerken — in de meeste rechtsgebieden juridisch bindend onder eIDAS (EU) en ESIGN (VS).

Probeer zelf een bericht te ondertekenen en te verifiëren:

# Create a document
echo "I want to secure my app with digital signatures" > message.txt

# Sign it with your RSA private key (from the earlier example)
openssl dgst -sha256 -sign private.pem -out message.sig message.txt

# Verify the signature with the public key
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Output: Verified OK

# Now tamper with the file and verify again
echo "I want to secure my app with Digital Signatures" > message.txt
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Output: Verification Failure

Het gewijzigde bericht zakt voor de verificatie — de handtekening bewijst zowel wie het document maakte als dat het niet is gewijzigd. Dat is hetzelfde mechanisme dat elk HTTPS-certificaat, elke ondertekende Git-commit en elke app die je uit een appwinkel installeert beschermt.

HMAC: handtekeningen voor symmetrische systemen

Delen beide partijen een geheime sleutel (zoals bij veel API-koppelingen), dan levert HMAC (Hash-based Message Authentication Code) integriteit en authenticatie zonder de overhead van cryptografie met publieke sleutels. Stripe, AWS en GitHub gebruiken alle drie HMAC om webhook-ladingen te ondertekenen zodat je server kan verifiëren dat ze echt zijn:

# Compute an HMAC-SHA256 of a message
echo -n "I want to secure my app with HMAC" | openssl dgst -sha256 -hmac "nerdy_pro"

Je server berekent dezelfde HMAC met zijn kopie van het gedeelde geheim en vergelijkt die met de handtekening in de verzoekheader. Komen ze overeen, dan is de webhook echt.

JWT's: handtekeningen in de praktijk

JSON Web Tokens (JWT's) zijn een van de meest voorkomende toepassingen van digitale handtekeningen. Heeft je applicatie gebruikersauthenticatie, dan is de kans groot dat er JWT's bij betrokken zijn. Een JWT is een compact, URL-veilig token met drie delen gescheiden door punten: een header, een lading en een handtekening.

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Miwicm9sZSI6Im5lcmR5X2FkbWluIn0.oAi5ALawUM_KpWDkiJcfA8504oQ_Yjx7OhEM8nZxlIc

De header noemt het ondertekeningsalgoritme. De lading draagt de eigenlijke gegevens — gebruikers-ID, rol, verloopmoment. De handtekening borgt dat er met geen van beide is geknoeid. Je server verifieert de handtekening bij elk verzoek en vertrouwt de lading alleen wanneer die verificatie slaagt.

Probeer dit token zelf te decoderen — plak het in jwt.io en kijk wat erin zit. Je merkt dat je de lading kunt lezen zonder het geheim te kennen. Dat is met opzet: JWT's zijn ondertekend, niet versleuteld. De handtekening bewijst alleen dat er niet met het token is geknoeid — ze verbergt de inhoud niet.

Ondertekeningsalgoritmen bepalen het beveiligingsmodel:

• HS256 (HMAC-SHA256) — symmetrisch. Dezelfde geheime sleutel ondertekent en verifieert het token. Eenvoudig op te zetten, maar elke dienst die tokens moet verifiëren heeft het geheim nodig — en dat wordt een risico naarmate je architectuur groeit.
• RS256 (RSA-SHA256) — asymmetrisch. De authenticatieserver ondertekent met een private sleutel, en elke dienst verifieert met de publieke. Die publieke sleutel mag vrij verspreid worden zonder de beveiliging aan te tasten.
• ES256 (ECDSA-P256) — asymmetrisch, met elliptische krommen. Hetzelfde vertrouwensmodel als RS256, maar met kleinere sleutels en snellere handtekeningen. Steeds vaker de aanbevolen keuze voor nieuwe applicaties.

Voordelen van JWT's:

• Staatloze authenticatie. De server hoeft bij elk verzoek geen database of sessieopslag te raadplegen — het token bevat zelf alle informatie om de gebruiker te autoriseren. Dat vereenvoudigt horizontaal schalen over meerdere servers.
• Vertrouwen tussen diensten. In microservicearchitecturen ondertekent de authenticatiedienst het token één keer, en kan elke dienst verderop het onafhankelijk verifiëren met de publieke sleutel. Geen gedeelde database of netwerkaanroep nodig.
• Standaard en overdraagbaar. JWT's zijn een open standaard (RFC 7519) die door bibliotheken in elke grote programmeertaal wordt ondersteund. Tokens kunnen in HTTP-headers, URL-parameters of cookies mee.

Valkuilen om op te letten:

• Tokens zijn niet in te trekken. Zodra een JWT is ondertekend, is hij geldig tot hij verloopt. Raakt het account van een gebruiker gecompromitteerd, dan kun je bestaande tokens niet ongeldig maken zonder aan de serverkant een blokkeerlijst toe te voegen — wat het staatloze voordeel deels tenietdoet. Korte verlooptijden (15 minuten) gecombineerd met vernieuwingstokens beperken dat.
• De lading is niet versleuteld. De met Base64 gecodeerde lading is ondertekend maar niet versleuteld — wie het token onderschept kan de inhoud lezen. Zet nooit gevoelige gegevens (wachtwoorden, persoonsgegevens, API-sleutels) in een JWT-lading. Heb je een versleuteld token nodig, gebruik dan JWE (JSON Web Encryption), al voegt dat complexiteit toe.
• Aanvallen met algoritmeverwarring. Accepteert de server meerdere algoritmen en controleert hij de alg-header niet streng, dan kan een aanvaller tokens vervalsen — bijvoorbeeld door van RS256 naar HS256 te wisselen en met de publieke sleutel als HMAC-geheim te ondertekenen. Dwing aan de serverkant altijd het verwachte algoritme af.
• Te grote tokens. Developers zetten soms te veel in de lading — hele gebruikersprofielen, rechtenlijsten, sessiestaat. JWT's gaan bij elk verzoek mee, meestal in een HTTP-header. Grote tokens kosten bandbreedte, kunnen headerlimieten overschrijden en vertragen elke API-aanroep. Houd ladingen minimaal: gebruikers-ID, rol, verloopmoment.

Voor de meeste applicaties bieden JWT's met ES256-ondertekening en korte verlooptijden een goede balans tussen veiligheid, prestaties en eenvoud. Heb je tokens nodig die je kunt intrekken, combineer ze dan met een lichte controle aan de serverkant tegen een intrekkingslijst, of gebruik ondoorzichtige vernieuwingstokens die je onafhankelijk ongeldig kunt maken.

De quantumdreiging: een reëel risico dat nu voorbereiding vraagt

Quantumcomputers gebruiken fundamenteel andere natuurkunde — qubits die tegelijk in meerdere toestanden kunnen bestaan — om bepaalde problemen exponentieel sneller op te lossen dan enige klassieke computer. Voor versleuteling heeft dat specifieke en goed begrepen gevolgen.

Wat quantumcomputers zullen breken

In 1994 publiceerde Peter Shor een quantumalgoritme dat bewees dat een voldoende krachtige quantumcomputer RSA, ECC en Diffie-Hellman kan breken — in wezen elk asymmetrisch algoritme dat vandaag in gebruik is. Dat is geen theoretische speculatie: het is een bewezen wiskundig resultaat. De enige open vraag is wanneer quantumhardware krachtig genoeg is om het op schaal uit te voeren.

Symmetrische versleuteling als AES wordt minder hard geraakt. Het algoritme van Grover halveert feitelijk de sterkte van symmetrische sleutels — waarmee AES-128 ontoereikend wordt maar AES-256 een comfortabele marge van 128 bits houdt.

"Nu oogsten, later ontsleutelen"

Dit is de dreiging die quantum computing vandaag urgent maakt, niet in een verre toekomst. Inlichtingendiensten en geraffineerde aanvallers onderscheppen en bewaren nu al versleuteld verkeer, met het plan het te ontsleutelen zodra quantumhardware volwassen is. Die strategie staat goed gedocumenteerd in de richtlijnen van de NSA over post-quantumbeveiliging.

Voor elke applicatie die gegevens verwerkt met een lange vertrouwelijkheidsduur — medische dossiers, financiële gegevens, juridische communicatie, intellectueel eigendom — is dat een risico van nu, geen hypothese.

Post-quantumcryptografie: het antwoord van de branche

In 2024 rondde NIST zijn eerste standaarden voor post-quantumcryptografie af:

• ML-KEM (CRYSTALS-Kyber) — een mechanisme voor sleuteluitwisseling dat ECDH vervangt. Al in productie: Chrome en Cloudflare gebruiken standaard een hybride sleuteluitwisseling met X25519 en ML-KEM.
• ML-DSA (CRYSTALS-Dilithium) — een handtekeningschema dat RSA- en ECDSA-handtekeningen vervangt.
• SLH-DSA (SPHINCS+) — een reserveschema voor handtekeningen op basis van hashfuncties, dat algoritmische diversiteit biedt mocht blijken dat op roosters gebaseerde schema's kwetsbaar zijn.

Wat dit voor je applicaties betekent

Bouw of onderhoud je vandaag applicaties, dan telt het volgende:

1. Stap over op AES-256. Dat is de eenvoudigste stap en levert quantumbestendige symmetrische versleuteling op tegen vrijwel geen prestatieverlies.
2. Zet hybride sleuteluitwisseling aan. Moderne TLS-bibliotheken (OpenSSL 3.x, BoringSSL) ondersteunen X25519 met ML-KEM al. Het aanzetten beschermt verbindingen tegen zowel klassieke als quantumaanvallen.
3. Beoordeel je cryptografische afhankelijkheden. Weet waar RSA en ECC in je stack zitten — dat zijn de onderdelen die uiteindelijk gemigreerd moeten worden. Is je applicatie snel of met AI-programmeergereedschap gebouwd, dan is een audit van AI-code de snelste manier om te vinden waar geheimen en zwakke cryptografie zich verstoppen.
4. Reken op grotere sleutels en handtekeningen. Post-quantumalgoritmen leveren grotere sleutels op dan ECC. Toets dat je protocollen, certificaten en opslag ze aankunnen.

End-to-end-versleuteling: de gouden standaard voor privéberichten

End-to-end-versleuteling (E2EE) betekent dat berichten op het toestel van de afzender worden versleuteld en alleen op het toestel van de ontvanger ontsleuteld kunnen worden. De dienstverlener — of dat nu een berichtenapp, een e-mailplatform of cloudopslag is — kan de inhoud niet lezen, ook niet onder een rechterlijk bevel of na een inbraak.

Hoe moderne E2EE in de praktijk werkt

Het Signal-protocol, gebruikt door Signal en WhatsApp, combineert meerdere technieken tot een gelaagd systeem:

1. Sleuteluitwisseling met een elliptische kromme (Curve25519) — twee toestellen spreken een gedeeld geheim af zonder het ooit over het netwerk te sturen.
2. Het Double Ratchet-algoritme — genereert voor elk afzonderlijk bericht een nieuwe sleutel. Bemachtigt een aanvaller op de een of andere manier één sleutel, dan kan hij eerdere noch latere berichten ontsleutelen. Die eigenschap heet forward secrecy.
3. AES-256 of ChaCha20 — versleutelt de eigenlijke berichtinhoud op hoge snelheid.
4. HMAC-authenticatie — zorgt dat er onderweg niet met berichten kan worden geknoeid.

Het resultaat is dat elk bericht een unieke sleutel heeft, sleutels nooit worden hergebruikt, en de schade van één gecompromitteerde sleutel beperkt blijft. Daarom bevelen beveiligingsonderzoekers het Signal-protocol consequent aan als de stand van de techniek in berichtenbeveiliging.

De uitdaging van groepsberichten

E2EE in gesprekken tussen twee mensen is een opgelost probleem. Groepsgesprekken zijn aanzienlijk lastiger. Heeft een groep 50, 200 of 1000 leden, dan moet het protocol nog een aantal complicaties aan:

• Sleuteldistributie op schaal. Elk bericht moet zo versleuteld worden dat alle huidige groepsleden — en alleen zij — het kunnen lezen. Het Signal-protocol gebruikt een mechanisme dat sender keys heet: elke deelnemer deelt een symmetrische sleutel met de groep, en berichten worden één keer versleuteld in plaats van één keer per ontvanger. Zo blijft groepsberichten sturen ook bij grote aantallen snel.
• Wijzigingen in het ledenbestand. Komt iemand bij een groep of vertrekt iemand, dan moeten de sleutels worden gewisseld zodat het nieuwe lid eerdere berichten niet kan lezen en het vertrokken lid latere niet. WhatsApp en Signal doen dat automatisch, maar het kost vertraging en overhead — zeker in grote groepen met veel verloop.
• Meerdere toestellen. Heeft een gebruiker een telefoon, een tablet en een desktopclient, dan heeft elk toestel eigen sleutels. Het protocol moet borgen dat alle toestellen groepsberichten kunnen ontsleutelen terwijl forward secrecy intact blijft. Het iMessage-protocol van Apple en de architectuur voor meerdere toestellen van Signal maken hierin verschillende afwegingen.

Voor bedrijven die functies voor groepssamenwerking bouwen — teamchats, projectkanalen, gedeelde werkruimtes — zijn dat geen theoretische zorgen. De architectuurkeuzes die vroeg in de bouw vallen bepalen of E2EE haalbaar is op de schaal die het product uiteindelijk nodig heeft.

De terugdraai van Instagram: een waarschuwing

In december 2023 rolde Meta E2EE standaard uit voor Messenger en begon het die uit te breiden naar de directe berichten van Instagram. De technische inspanning was enorm — het team van Meta beschreef de meerjarige verbouwing van de infrastructuur die nodig was om functies als zoeken, linkvoorbeelden en spamdetectie te herbouwen zonder toegang aan de serverkant tot berichtinhoud.

In maart 2026 draaide Meta het terug. Het bedrijf kondigde aan dat Instagram op 8 mei 2026 E2EE uit de directe berichten haalt. Anders dan bij WhatsApp, waar E2EE de standaard is voor alle gebruikers, was versleuteld berichten sturen op Instagram alleen beschikbaar als optie in bepaalde regio's — en Meta noemde het lage gebruik als reden om het te stoppen.

Die terugdraai is om meerdere redenen veelzeggend:

Privacy als functie, geen garantie. De E2EE van Instagram was nooit werkelijk "standaard" — gebruikers moesten hem per gesprek aanzetten, en hij was alleen in bepaalde landen beschikbaar. Dat staat in schril contrast met WhatsApp, waar elk bericht sinds 2016 end-to-end versleuteld is zonder dat de gebruiker iets hoeft te doen. De les: staat versleuteling niet standaard aan, dan blijft het gebruik laag, en wordt dat lage gebruik de rechtvaardiging om het te verwijderen.

Regeldruk wint. Overheden in de VS, het VK, de EU en Australië hebben zich hard tegen E2EE in berichtenapps verzet, met het argument dat het onderzoek naar kindermisbruik en terrorisme belemmert. De Britse Online Safety Act bevat bepalingen die platforms zouden kunnen dwingen E2EE te breken. De voorgestelde EU-verordening "Chat Control" zou het scannen van berichten aan de clientkant vóór versleuteling verplichten. E2EE uit de directe berichten van Instagram halen stelt Meta in staat berichten te scannen op materiaal van seksueel kindermisbruik en andere schadelijke inhoud — in lijn met wat toezichthouders verwachten.

Gebruikers verliezen de regie. Meta vertelde getroffen gebruikers hun versleutelde berichten en media vóór de deadline van 8 mei te downloaden, want versleutelde gespreksgeschiedenis wordt niet naar gewone onversleutelde gesprekken meegenomen. Wie E2EE wil, wordt naar WhatsApp verwezen.

Het E2EE-landschap vandaag. Zo verhouden de grote platforms zich na de terugdraai van Instagram:

Het gat tussen platforms die versleuteling als kernarchitectuurkeuze behandelen (Signal, WhatsApp, iMessage) en platforms die haar als optionele functie behandelen (Instagram, Telegram, Discord) was nooit duidelijker. Voor bedrijven die berichtenfuncties bouwen is dat het cruciale ontwerpbesluit: E2EE moet fundamenteel zijn, niet erop geschroefd — want optionele versleuteling kan worden afgenomen.

Wat E2EE niet beschermt

Voor elke applicatie die E2EE inbouwt of erop leunt is het belangrijk de grenzen te kennen:

• Metadata. E2EE beschermt inhoud, geen metadata. Het platform weet nog steeds wie wie berichtte, wanneer, hoe vaak, en vanaf welk IP-adres. Onderzoek van de EFF heeft laten zien dat metadata alleen al gevoelige informatie over relaties en gedragspatronen kan prijsgeven.
• Gecompromitteerd eindpunt. Is het toestel zelf gecompromitteerd — door malware, spyware als Pegasus, of fysieke toegang — dan leest de aanvaller berichten na ontsleuteling. E2EE beschermt gegevens onderweg en op de server, niet op een gecompromitteerd toestel.
• Cloudback-ups. Staan gespreksback-ups onversleuteld in iCloud of Google Drive, dan is E2EE feitelijk omzeild. WhatsApp biedt versleutelde back-ups, maar gebruikers moeten die zelf aanzetten.
• Menselijke factoren. Geen enkel cryptografisch protocol houdt tegen dat een ontvanger een schermafbeelding maakt of via social engineering wordt overgehaald een gesprek te delen.

Hoe het in een echte applicatie samenkomt

Wanneer wij veilige applicaties voor klanten bouwen, is versleuteling geen enkele functie — het is een gelaagde architectuur waarin elk soort versleuteling een specifieke rol speelt:

1. Cryptografie met elliptische krommen vestigt vertrouwen tussen partijen en wisselt veilig sleutels uit — met kleinere, snellere sleutels dan oudere aanpakken op RSA.
2. Symmetrische versleuteling (AES-256) verzorgt de snelle versleuteling van de eigenlijke gegevens — bestanden, berichten, databaserecords, API-ladingen.
3. Digitale handtekeningen en controlegetallen bewijzen echtheid en merken geknoei op — van ondertekende API-tokens en software-updates tot geverifieerde webhook-ladingen.
4. End-to-end-versleuteling zorgt dat zelfs de dienstverlener niet bij gebruikersinhoud kan — essentieel voor zorg, juridische technologie, financiën, en elke applicatie waar privacy een eis van toezichthouders of van de concurrentie is.
5. Gereedheid voor post-quantum beschermt langlevende gegevens tegen toekomstige dreigingen — iets waar vooruitkijkende bedrijven nu al mee bezig zijn.

De juiste versleutelingsstrategie hangt af van wat je bouwt: een mobiele app met persoonsgegevens, een B2B-platform dat financiële dossiers verwerkt, een berichtenfunctie, of een IoT-systeem. Elk kent andere dreigingsmodellen en regels, en de versleutelingsarchitectuur hoort daarbij te passen.

Die architectuur goed krijgen — en de plekken vangen waar ze stilletjes breekt, zoals geheimen die in versiebeheer belanden of persoonsgegevens die in leesbare tekst worden gelogd — is precies waar we in een audit van AI-code naar zoeken. Lever je een applicatie op die gevoelige gegevens verwerkt en wil je een tweede paar ogen op de beveiliging, neem dan contact op.

Bronnen

• Shor, P. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings 35th Annual Symposium on Foundations of Computer Science.
• Grover, L. (1996). A fast quantum mechanical algorithm for database search. arXiv.
• Cohn-Gordon, K. et al. (2016). A formal security analysis of the Signal messaging protocol. Cryptology ePrint Archive.
• NIST (2024). Post-Quantum Encryption Standards.
• NSA (2022). Post-Quantum Cybersecurity Resources.
• Meta Engineering (2024). End-to-end encryption on Messenger.
• EFF (2013). Why metadata matters.
• Citizen Lab (2021). Hooking Candiru: another mercenary spyware vendor comes into focus.