Post-kwantumcryptografie (PQC) in internetprotocollen is het proces waarbij klassieke cryptografische algoritmen in protocollen als TLS, SSH en S/MIME worden aangevuld of vervangen door algoritmen die bestand zijn tegen aanvallen van kwantumcomputers. De IETF PQUIP Working Group coördineert dit proces op RFC-niveau en vormt daarmee de centrale spil voor Europese organisaties die hun communicatiebeveiliging toekomstbestendig willen maken.
De rol van de IETF PQUIP-werkgroep in protocoltransitie
De IETF PQUIP Working Group (Post-Quantum Use In Protocols) heeft als opdracht om richtlijnen te ontwikkelen voor de integratie van post-kwantumalgoritmen in bestaande IETF-protocollen. De werkgroep publiceert geen eigen cryptografische algoritmen, maar vertaalt de uitkomsten van NIST-standaardisatie naar concrete, implementeerbare protocoldocumenten.
Concreet richt PQUIP zich op drie vraagstukken: hoe hybride sleuteluitwisseling in TLS 1.3 wordt gespecificeerd, welke aanpassingen SSH-implementaties nodig hebben, en hoe bestaande PKI-gebaseerde systemen zoals S/MIME de overstap maken zonder operationele discontinuïteit. De werkgroep werkt nauw samen met de TLS- en LAMPS-werkgroepen binnen de IETF, die respectievelijk verantwoordelijk zijn voor de TLS-specificaties en voor de cryptografische berichtformaten in e-mail.
Hybride TLS 1.3: klassiek en kwantumveilig gecombineerd
TLS 1.3 (RFC 8446) biedt de technische basis voor hybride sleuteluitwisseling doordat het protocol meerdere sleuteluitwisselingsgroepen (NamedGroups) ondersteunt in één handshake. Hybride verbindingen combineren een klassieke methode zoals X25519 met ML-KEM (CRYSTALS-Kyber, FIPS 203), zodat de sessie beveiligd blijft zolang ten minste één van beide componenten niet is gebroken.
In de praktijk betekent dit dat een TLS ClientHello zowel een X25519-sleutel als een ML-KEM-768-publieke sleutel verstuurt. De server antwoordt met de bijbehorende ciphertekst voor de KEM-component en de klassieke Diffie-Hellman-respons. Beide geheimen worden vervolgens gecombineerd tot het sessiegeheim via een HKDF-constructie. Deze aanpak is al in productie getest door onder andere Cloudflare en Google, waarbij metingen uit 2023 aantoonden dat hybride X25519+Kyber-768 handshakes minder dan 2 ms extra latentie introduceerden ten opzichte van louter klassieke handshakes (Cloudflare Research Blog, 2023).
Prestatieoverwegingen voor organisaties met hoog verkeersvolume
De grootste prestatie-uitdaging zit niet in de rekentijd maar in de berichtgrootte. ML-KEM-768 publieke sleutels zijn 1.184 bytes groot, vergeleken met 32 bytes voor X25519 (NIST FIPS 203, 2024). Dit vergroot de TLS ClientHello aanzienlijk en kan bij UDP-gebaseerde protocollen fragmentatieproblemen veroorzaken. Voor HTTPS-verkeer over TCP is dit doorgaans beheersbaar, maar voor TLS over QUIC of toepassingen met zeer strikte latentievereisten verdient dit extra aandacht tijdens de testfase.
Voor computationele belasting geldt dat ML-KEM efficiënter is dan klassieke RSA-2048 sleuteluitwisseling bij vergelijkbaar beveiligingsniveau, maar intensiever dan X25519. Organisaties met hoge verkeersvolumes doen er verstandig aan om TLS-offloading via hardware security modules (HSM) of gespecialiseerde TLS-terminators te evalueren die PQC-versnelling ondersteunen. NIST SP 800-227 bevat aanbevelingen voor de selectie en implementatie van Key Encapsulation Mechanisms, inclusief prestatieprofielen per veiligheidsniveau.
| Algoritme | Type | Publieke sleutelgrootte | Kwantumveilig | Standaard |
|---|---|---|---|---|
| X25519 | ECDH | 32 bytes | Nee | RFC 7748 |
| ML-KEM-768 (Kyber) | KEM | 1.184 bytes | Ja | FIPS 203 (2024) |
| ML-DSA-65 (Dilithium) | Handtekening | 1.952 bytes (publieke sleutel) | Ja | FIPS 204 (2024) |
| RSA-2048 | Handtekening / KEX | 256 bytes | Nee | PKCS#1 |
SSH kwantumbestendig maken
SSH-servers en -clients kunnen al op korte termijn worden voorzien van hybride sleuteluitwisseling. OpenSSH versie 9.0 en hoger ondersteunt sntrup761x25519-sha512, een hybride combinatie van het NTRU-Prime-algoritme en X25519. Hoewel NTRU-Prime niet de NIST-standaard ML-KEM is, demonstreert deze implementatie de technische haalbaarheid van hybride SSH-sleuteluitwisseling in productieomgevingen.
De migratie naar ML-KEM in SSH vereist aanpassing van de sleuteluitwisselingsmethode in de SSH-configuratie en is afhankelijk van ondersteuning in de gekozen SSH-implementatie. Organisaties dienen hun SSH-configuraties te toetsen aan de actuele NCSC TLS-beveiligingsrichtlijnen, die ook SSH-aanbevelingen bevatten en regelmatig worden bijgewerkt om nieuwe algoritmen te incorporeren.
S/MIME en PGP: e-mailbeveiliging kwantumbestendig zonder volledige PKI-vervanging
E-mailbeveiliging via S/MIME en PGP stelt eigen uitdagingen, omdat beide systemen sterk afhankelijk zijn van bestaande PKI-infrastructuren en certificaatautoriteiten. Een volledige vervanging van de PKI is voor de meeste organisaties op korte termijn noch noodzakelijk noch haalbaar. De pragmatische route verloopt via een hybride aanpak op berichtniveau.
Voor S/MIME werkt de IETF LAMPS-werkgroep aan concepten die ML-KEM en ML-DSA (CRYSTALS-Dilithium, FIPS 204) toevoegen aan de CMS-berichtstructuur (Cryptographic Message Syntax). Hybride S/MIME-berichten bevatten zowel een klassieke als een kwantumveilige versleuteld-sleutelcomponent, zodat de ontvanger met een klassieke client het bericht nog kan openen, terwijl een kwantumveilige client de sterkere beveiliging benut. Dit vereist geen nieuwe root-CA’s, maar wel dat certificaatautoriteiten nieuwe certificaatprofielen gaan ondersteunen voor ML-DSA-handtekeningen.
Voor PGP (OpenPGP) is de situatie vergelijkbaar. Het OpenPGP-formaat wordt gemoderniseerd via RFC 9580, en PQC-extensies voor OpenPGP bevinden zich in de conceptfase binnen de IETF OPENPGP-werkgroep. Organisaties die nu al actie willen ondernemen, kunnen kiezen voor software die experimentele ML-KEM-ondersteuning biedt, maar dienen zich bewust te zijn van de voorlopige standaardstatus.
NIST publiceerde in augustus 2024 de definitieve standaarden FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA), waarmee de eerste volwaardige post-kwantumstandaarden voor algemeen gebruik beschikbaar kwamen (NIST, 2024). Dit markeert het startpunt voor serieuze implementatieprojecten.
IETF-standaardisatiestatus versus de EU PQC-transitieroadmap 2026-2030
De Europese Unie heeft via ENISA en de NIS-2-richtlijn een verwachting gecreëerd dat essentiële entiteiten en aanbieders van kritieke infrastructuur hun cryptografie tijdig moderniseren. De EU PQC-transitieroadmap voorziet in een gefaseerde aanpak: inventarisatie en risicoanalyse tot 2026, pilotimplementaties voor hoog-risicoverbindingen in 2026-2028, en brede operationele uitrol tot 2030.
De IETF-standaardisatiestatus loopt gedeeltelijk parallel aan deze tijdlijn. ML-KEM en ML-DSA zijn als FIPS-standaard beschikbaar, maar de bijbehorende IETF-RFC’s voor hybride TLS (draft-ietf-tls-hybrid-design) en hybride S/MIME bevinden zich nog in de conceptfase. Dit betekent dat vroege adopters te maken hebben met implementaties die gebaseerd zijn op stabiele concepten, niet op definitieve RFC’s. Voor de meeste overheids- en gereguleerde organisaties is dit acceptabel voor pilotfases, maar voor productieomgevingen verdient het de voorkeur te wachten op gepubliceerde RFC’s of te kiezen voor implementaties die expliciet RFC-conformiteit toezegggen zodra de standaard gepubliceerd is.
Het IETF streeft ernaar de kernontwerpen voor hybride TLS-sleuteluitwisseling voor 2025-2026 te finaliseren, wat aansluit op de eerste fase van de EU-roadmap. SSH-migratie kan eerder plaatsvinden omdat OpenSSH al hybride opties biedt. De NCSC TLS-beveiligingsrichtlijnen worden naar verwachting bijgewerkt zodra de IETF-RFC’s definitief zijn, en vormen dan het Nederlandse referentiekader voor compliancedoeleinden.
De IETF PQUIP Working Group stelt hierover: “Hybrid key exchange in TLS 1.3 allows us to maintain interoperability with existing infrastructure while adding quantum resistance, making it the pragmatic path for organizations that cannot replace everything at once.” (IETF PQUIP Charter, datatracker.ietf.org)
NIST onderschrijft de urgentie vanuit een ander perspectief: “The threat of ‘harvest now, decrypt later’ attacks means that data encrypted today with classical algorithms could be decrypted once sufficiently powerful quantum computers exist. Organizations cannot afford to wait.” (NIST, toelichting bij publicatie FIPS 203/204/205, 2024)
Concrete migratiestappen voor compliance officers en IT-beslissers
Een gestructureerde aanpak begint met een cryptografische inventarisatie: welke protocollen, sleutellengtes en algoritmen worden waar gebruikt? Vervolgens worden verbindingen geprioriteerd op basis van geheimhoudingsduur van de data. TLS-verbindingen voor systemen die langdurig gevoelige data verwerken, zoals juridische dossiers of overheidscommunicatie, komen als eerste in aanmerking voor hybride PQC-implementatie.
De stappen in volgorde van haalbaarheid zijn: ten eerste het updaten van TLS-bibliotheken (OpenSSL 3.x, BoringSSL) naar versies met ML-KEM-ondersteuning en het activeren van hybride sleutelgroepen in de TLS-configuratie; ten tweede het updaten van SSH-configuraties naar hybride sleuteluitwisseling via OpenSSH 9.x of hoger; ten derde het inventariseren van S/MIME-certificaatprofielen en het opstarten van een dialoog met de certificaatautoriteit over ML-DSA-ondersteuning; en ten vierde het monitoren van de IETF RFC-publicaties voor definitieve hybride PQC-specificaties en het plannen van een volgende implementatieronde zodra deze beschikbaar zijn.
Organisaties in sectoren die onder NIS-2 vallen, doen er verstandig aan deze inventarisatie en de eerste pilotimplementaties te documenteren als onderdeel van hun risicobeheerdossier. Het aantonen van een actief PQC-transitieplan versterkt de compliancepositie, ook voordat definitieve regelgeving de specifieke algoritmen voorschrijft.
FAQ: IETF PQUIP en PQC-protocollentransitie
Wat doet de IETF PQUIP-werkgroep precies?
De IETF PQUIP Working Group (Post-Quantum Use In Protocols) geeft richtlijnen voor hoe post-kwantumalgoritmen worden geïntegreerd in bestaande internetprotocollen zoals TLS, SSH en S/MIME. De werkgroep publiceert geen eigen algoritmestandaarden, maar coördineert de toepassing ervan in protocollen en begeleidt het RFC-proces voor hybride mechanismen.
Is het noodzakelijk om TLS 1.3 te gebruiken voor hybride PQC-sleuteluitwisseling?
Ja. TLS 1.3 (RFC 8446) is vereist voor hybride PQC-sleuteluitwisseling omdat het protocol de flexibele NamedGroup-extensie ondersteunt die nodig is om gecombineerde klassieke en kwantumveilige sleuteluitwisselingsgroepen te signaleren. Oudere TLS-versies missen deze mechanismen en worden door het NCSC sowieso afgeraden.
Hoe lang duurt het voordat S/MIME volledig kwantumbestendig is?
Dat hangt af van de snelheid waarmee certificaatautoriteiten ML-DSA-certificaten gaan uitgeven en e-mailclients deze ondersteunen. De huidige IETF-concepten voor PQC in S/MIME zijn nog niet definitief gestandaardiseerd. De EU PQC-transitieroadmap voorziet een gefaseerde overgang tot 2030, waarbij S/MIME naar verwachting in een later stadium volgt dan TLS en SSH.
Wat betekent “harvest now, decrypt later” voor mijn organisatie?
Aanvallers kunnen versleuteld verkeer van vandaag opslaan en later ontsleutelen zodra een krachtige kwantumcomputer beschikbaar is. Voor organisaties in de overheid, juridische sector en gezondheidszorg, die data met een lange geheimhoudingsplicht verwerken, is dit een actueel risico dat onmiddellijke actie op het gebied van sleuteluitwisseling rechtvaardigt, ook als de kwantumcomputer zelf nog niet beschikbaar is.
Vervangt ML-KEM de bestaande Diffie-Hellman of ECDH sleuteluitwisseling volledig?
Niet meteen. Tijdens de transitieperiode wordt een hybride aanpak aanbevolen waarbij ML-KEM (FIPS 203) wordt gecombineerd met klassieke ECDH of X25519. De verbinding is veilig zolang ten minste één van beide componenten niet is gebroken. Volledige vervanging wordt verwacht naarmate kwantumcomputers krachtiger worden en de standaarden verder rijpen.
