De toestand van het post-kwantuminternet in 2025

In deze laatste week van oktober 2025 hebben we een belangrijke mijlpaal voor de internetbeveiliging bereikt: het merendeel van het door mensen geïnitieerde verkeer met Cloudflare maakt gebruik van post-kwantumversleuteling, waardoor het risico van 'nu oogsten, later ontsleutelen'-aanvallen wordt gereduceerd.

Wij willen even bij dit moment stilstaan en ook update geven over de huidige stand van zaken met betrekking tot de migratie van het internet naar post-kwantumcryptografie en de lange weg die nog voor ons ligt. Ons laatste overzicht is van 21 maanden geleden. Sindsdien is er heel wat gebeurd. Veel heeft precies aan onze voorspellingen voldaan: de NIST-standaarden zijn afgerond, de post-kwantumversleuteling wordt goed geaccepteerd, toezichthouders hebben meer uitgewerkte stappenplannen opgesteld, er is vooruitgang geboekt bij de ontwikkeling van kwantumcomputers, de cryptografie was deels gekraakt (echter zonder invloed op wat is toegepast) en er is een nieuwe, veelbelovende cryptografie voorgesteld.

Er waren echter ook enkele verrassingen: er is grote voortgang geboekt richting Q-day dankzij de verbetering van kwantumalgoritmes, en een nieuw kwantumalgoritme liet ons flink schrikken. We bespreken dit alles hieronder en nog veel meer, zoals wat onze verwachtingen zijn voor de komende jaren en wat je vandaag al kunt doen.

Laten we bij het begin beginnen: waarom moeten we onze cryptografie veranderen? Dat komt door kwantumcomputers. Deze wonderbaarlijke apparaten beperken zich niet tot eentjes en nulletjes, maar maken gebruik van wat de natuur ons schenkt: kwantumsuperpositie, interferentie en verstrengeling. Hierdoor kunnen kwantumcomputers uitblinken in heel specifieke berekeningen, met name het simuleren van de natuur zelf. Dit is erg nuttig voor de ontwikkeling van nieuwe materialen.

Kwantumcomputers zullen gewone computers echter nooit vervangen. Ze zijn voor de meeste taken die van belang zijn voor ons dagelijks leven gewoon veel slechter dan gewone computers. Beschouw ze als grafische kaarten of neural engines: gespecialiseerde apparaten voor specifieke berekeningen, niet voor algemene taken.

Helaas zijn kwantumcomputers ook heel goed in het kraken van de belangrijke cryptografie die vandaag de dag nog veel wordt gebruikt, zoals RSA en elliptische curven (ECC). We gaan dus over op post-kwantumcryptografie, ofwel cryptografie die bestand is tegen kwantumaanvallen. Later zullen we de precieze impact hiervan op de verschillende soorten cryptografie bespreken.

Momenteel zijn kwantumcomputers nog vrij zwak: ze zijn gewoon nog niet goed genoeg om echte cryptografische sleutels te kraken. Dat wil niet zeggen dat we ons geen zorgen hoeven te maken. Versleuteld verkeer kan vandaag worden verzameld en worden ontcijferd na Q-day, de dag waarop kwantumcomputers in staat zijn om de huidige, nog veelgebruikte cryptografie te kraken, zoals RSA-2048. We noemen dat een 'nu oogsten, later ontsleutelen'-aanval.

Als kwantumcomputers de benchmark zijn voor het ontbinden in factoren, zijn ze bepaald niet indrukwekkend: het grootste getal dat door een kwantumcomputer zonder vals te spelen is ontbonden, is 15. Dat record kan op allerlei grappige manieren worden verbroken. Het is verleidelijk om kwantumcomputers te negeren totdat ze de klassieke computers gaan verslaan op het gebied van ontbinden in factoren, maar dat zou een grote vergissing zijn. Zelfs voorzichtige schattingen geven aan dat Q-day minder dan drie jaar later is dan de dag waarop kwantumcomputers de klassieke computers op het gebied van ontbinden in factoren kunnen verslaan. Hoe kunnen we deze voortgang bijhouden?

Er zijn twee belangrijke overwegingspunten op ons traject naar Q-day: vooruitgang op het gebied van kwantumhardware en algoritmische verbeteringen van de software die op die hardware draait. Op beide fronten hebben we aanzienlijke vooruitgang gezien.

Zoals elk jaar verschijnen er in het nieuws berichten over nieuwe kwantumcomputers met een recordaantal qubits. Deze nadruk op het tellen van qubits is bovendien nogal misleidend. Om te beginnen zijn kwantumcomputers analoge machines en is er altijd sprake van ruis die de berekeningen verstoort.

Er zijn grote verschillen tussen de diverse technologieën die worden gebruikt om kwantumcomputers te bouwen: kwantumcomputers op basis van silicium lijken goed op te kunnen schalen, voeren instructies snel uit, maar hebben qubits met veel ruis. Dat wil niet zeggen dat ze nutteloos zijn: met behulp van codes voor het corrigeren van kwantumfouten kunnen miljoenen ruisende siliciumqubits effectief worden omgezet in een paar duizend zeer betrouwbare qubits. Dat zou genoeg kunnen zijn om RSA te kraken. Kwantumcomputers met ingesloten ionen veroorzaken daarentegen veel minder ruis, maar zijn lastiger op te schalen. Slechts een paar honderdduizend qubits met ingesloten ionen zouden potentieel het einde van RSA-2048 kunnen betekenen.

^{Timelapse van de stand van zaken op het gebied van kwantumcomputing van 2021 tot en met 2025, gebaseerd op het aantal qubits op de x-as en de ruis op de y-as. De stippen in het grijze gebied zijn de verschillende kwantumcomputers die momenteel bestaan. Zodra het gearceerde grijze gebied de meest linkse rode lijn bereikt, zitten we in de problemen. Dit betekent namelijk dat een kwantumcomputer grote RSA-sleutels kan kraken. Samengesteld door Samuel Jaques van de Universiteit van Waterloo.}

We staan nog maar aan het begin van het aantal qubits en de ruis. Er zijn kleine details die een groot verschil kunnen maken, zoals de onderlinge verbondenheid van qubits. Belangrijker nog: de grafiek laat niet zien hoe schaalbaar de techniek is.

Op deze grafieken lijkt het erop dat de vooruitgang op het gebied van kwantumcomputers de laatste twee jaar is gestagneerd. De Willow-aankondiging van Google in december 2024, die op de grafiek niet opvalt, was voor deskundigen echter een ware mijlpaal: voor het eerst werd een logische qubit op een schaalbare manier in de oppervlaktecode gebruikt. Citaat van Sam Jaques:

Toen ik deze resultaten [Willow's prestaties] voor het eerst las, kreeg ik kippenvel: "Wauw, kwantumcomputing bestaat echt."

Het is een echte mijlpaal, maar geen onverwachte sprong. Ik citeer Sam nogmaals:

Ondanks mijn enthousiasme ligt dit in de lijn der verwachtingen en komt deze ontwikkeling misschien zelfs wat laat. Alle grote doorbraken die zij lieten zien, zijn gewoon de stappen die gezet moeten worden om te kunnen hopen op de 20 miljoen qubits tellende machine die RSA kan kraken. Dit zijn geen onverwachte doorbraken. Vergelijk het met de jaarlijkse toename van de transistordichtheid in klassieke chips: een indrukwekkende prestatie, maar uiteindelijk is het gewoon business as usual.

Ook de strategie blijft business as usual: de supergeleidende qubit-aanpak die Google voor Willow hanteert, was altijd al de meest veelbelovende, waarbij de problemen rechtstreeks en met zo min mogelijk technische sprongen worden aangepakt.

Microsoft hanteert een tegenovergestelde strategie met hun inzet op topologische qubits. Dit zijn qubits die in theorie niet door ruis worden gestoord. Ze worden echter nog niet volledig in de hardware gebruikt. Als ze op schaalbare wijze gebouwd kunnen worden, zijn ze veel beter dan supergeleidende qubits. Maar we weten nog niet eens of ze überhaupt gebouwd kunnen worden. Begin 2025 kondigde Microsoft de Majorana 1-chip aan, die laat zien hoe ze gebouwd kunnen worden. De chip is echter verre van een volwaardig: hij ondersteunt geen enkele berekening en is daarom ook niet te zien in Sam's eerdere vergelijkingsgrafiek.

Tussen topologische en supergeleidende qubits zijn er nog allerlei andere benaderingen die door laboratoria over de hele wereld worden toegepast en die wel op de grafiek voorkomen, zoals QuEra met neutrale atomen en Quantinuum met ingesloten ionen.

De voortgang op het gebied van hardware om Q-day te bereiken krijgt veruit de meeste aandacht in de pers. De grootste doorbraak van de afgelopen twee jaar heeft echter niets met hardware te maken.

We dachten dat we met de supergeleidende aanpak ongeveer 20 miljoen qubits nodig zouden hebben om RSA-2048 te kunnen kraken. Blijkt dat het met veel minder kan. In een verbazingwekkend uitgebreid artikel uit juni 2025 laat Craig Gidney zien dat we met slimme optimalisaties van de kwantumsoftware minder dan een miljoen qubits nodig hebben. Dit is de reden dat de rode lijnen in de grafiek van Sam hierboven, die de omvang van een kwantumcomputer aangeven die RSA moet doorbreken, in 2025 drastisch naar links zijn verschoven.

Even een ander perspectief: laten we een gok wagen en zeggen dat Google een soort wet van Moore in stand kan houden en het aantal fysieke qubits om de 18 maanden kan verdubbelen. Dat is een veel sneller tempo dan Google tot nu toe heeft laten zien, maar het is niet ondenkbaar dat ze dit kunnen bereiken zodra de basis is gelegd. Dan zou het tot 2052 duren om 20 miljoen qubits te bereiken, maar één miljoen al in 2045: Craig heeft in zijn eentje Q-day zeven jaar dichterbij gebracht!

Hoe ver kan software-optimalisatie gaan? Het lijkt Sam onmogelijk om het aantal onder de 100.000 supergeleidende qubits te brengen, terwijl hij verwacht dat er meer dan 242.000 supergeleidende qubits nodig zijn om RSA-2048 te kraken. Gezien de wilde voorspellingen over de vooruitgang van de kwantumcomputer, zou dat overeenkomen met een Q-day van respectievelijk 2039 en 2041+.

Hoewel Craigs schatting gedetailleerde en redelijke aannames bevat over de architectuur van een grootschalige supergeleidende qubits-kwantumcomputer, blijft het een gok en hebben deze schattingen een grote foutmarge.

Wat de algoritmen betreft, zien we mogelijk niet alleen verbeteringen van de bestaande kwantumalgoritmes, maar ook compleet nieuwe kwantumalgoritmes. In april 2024 publiceerde Yilei Chen een preprint waarin hij beweerde een nieuw kwantumalgoritme te hebben gevonden om bepaalde lattice-problemen op te lossen. Deze lijken op de algoritmen die we gebruiken voor de post-kwantumcryptografie, maar zijn niet identiek. Dit zorgde voor de nodige ophef: onze post-kwantumalgoritmes kunnen mogelijk vandaag nog niet worden aangevallen, maar kan het algoritme van Chen worden verbeterd? Om een idee te krijgen van de mogelijke verbeteringen, moet je begrijpen wat het algoritme daadwerkelijk op een hoger niveau doet. Met Chen's algoritme is dat lastig, omdat het heel complex is, veel complexer dan Shor's kwantumalgoritme dat RSA kan kraken. Het duurde dan ook een tijdje voordat experts de beperkingen van Chens aanpak ontsluierden. Na tien dagen ontdekten ze een fundamentele fout in het algoritme: de aanpak werkt niet. Crisis afgewend.

Wat kunnen we hiervan leren? Optimistisch gezien is dit business as usual voor cryptografie, en de lattices staan er nu beter voor, aangezien één aanvalsroute een doodlopende weg bleek te zijn. Realistisch gezien worden we op het feit gedrukt dat we heel veel aandacht aan lattices geven. Zoals we later zullen zien, is er momenteel geen echt alternatief dat overal werkt.

Voorstanders van kwantumsleuteldistributie (quantum key distribution of QKD) zullen wellicht beweren dat QKD precies dit probleem oplost, aangezien het veilig is dankzij de natuurwetten. Nou ja, er zijn wel wat kanttekeningen bij die bewering te plaatsen, maar wat nog fundamenteler is, is dat niemand heeft uitgevonden hoe QKD verder kan worden opgeschaald dan point-to-point-verbindingen, zoals wij in dit blogbericht aan de orde hebben gesteld.

Het is leuk om te speculeren over welke cryptografie gekraakt zou kunnen worden met een compleet nieuwe aanval, maar laten we niet vergeten dat kwantumcomputers ongetwijfeld veel cryptografie zullen kraken. Q-day komt eraan, de vraag is wanneer.

Als je al lang genoeg met cryptografie en beveiliging bezig bent, dan heb je de afgelopen jaren waarschijnlijk elk jaar gehoord dat "Q-day nog X jaar op zich zal laten wachten". Hierdoor kan het lijken alsof Q-day altijd 'ergens in de toekomst' ligt, totdat we zo’n bewering in de juiste context plaatsen.

Sinds 2019 voert het Global Risk Institute jaarlijks een enquête uit onder deskundigen, waarin wordt gevraagd hoe waarschijnlijk het is dat RSA-2048 binnen 5, 10, 15, 20 of 30 jaar zal worden gekraakt. Dit zijn de resultaten uit 2024, waarvan de interviews plaatsvonden vóór Willows release en Gidneys doorbraak.

^{De resultaten van een onderzoek van het Global Risk Institute uit 2024 onder deskundingen over de waarschijnlijkheid dat een kwantumcomputer RSA-2048 binnen verschillende tijdlijnen kan kraken.}

Zoals de middelste kolom in deze grafiek laat zien, dacht ruim de helft van de ondervraagde experts dat er een kans van ~50% was dat een kwantumcomputer RSA-2048 binnen 15 jaar zou kraken. Laten we de historische antwoorden uit 2019, 2020, 2021, 2022 en 2023 eens bekijken. Hier brengen we de waarschijnlijkheid van Q-day binnen 15 jaar (vanaf het tijdstip van het interview) in kaart:

^{Historische antwoorden in de tijdlijn van kwantumdreigingen geven aan hoe groot de kans is op Q-day binnen 15 jaar.}

Dit laat zien dat de antwoorden langzaam maar zeker zekerder worden, maar is dit het tempo dat we verwachten? Met zes jaar aan antwoorden kunnen we in kaart brengen hoe consistent de voorspellingen zijn: komt de 15-jarige schatting uit 2019 overeen met de 10-jarige schatting uit 2024?

^{Historische antwoorden in de tijdlijn van kwantumdreigingen over het aantal jaren tot aan de datum van Q-day. De x-as geeft het vermeende jaar voor Q-day aan en de y-as toont het percentage geïnterviewde deskundigen dat denkt dat de kans minimaal ~50% (links) of 70% (rechts) is.}

Als we deskundigen vragen wanneer er 50-50 kans op een Q-day bestaat (grafiek links), dan hebben ze altijd hetzelfde gezegd: ja, het zou nog wel een 15 jaar kunnen duren. Als we echter om meer zekerheid vragen en vragen om een Q-day met een waarschijnlijkheid van >70% (grafiek rechts), dan zijn de deskundigen het over het algemeen met elkaar eens. Bijvoorbeeld: 20% van de deskundigen dacht in de interviews van 2019 en 2024 al aan 2034.

Dus als je een consistent antwoord van een deskundige wilt, vraag dan niet wanneer Q-day zal vallen, maar wanneer het waarschijnlijk is. Het is leuk om te gokken over Q-day, maar het eerlijke antwoord is dat niemand het echt zeker weet: er zijn gewoon te veel onbekenden. Uiteindelijk is de datum van Q-day veel minder belangrijk dan de deadlines die door de wet worden vereist.

We kunnen ook kijken naar de tijdlijnen van verschillende toezichthouders. In 2022 publiceerde de National Security Agency (NSA) de CNSA 2.0-richtlijnen, met deadlines tussen 2030 en 2033 voor de migratie naar post-kwantumcryptografie. Ook in 2022 stelde de Amerikaanse federale overheid 2035 als doel om de Verenigde Staten volledig te laten migreren. De nieuwe regering is daar niet van afgeweken. In 2024 bepaalde Australië 2030 als de ambitieuze deadline voor de migratie. Begin 2025 bepaalde het Britse NCSC de vaak gebruikte deadline van 2035 voor het Verenigd Koninkrijk. Medio 2025 publiceerde de Europese Unie haar stappenplan met 2030 en 2035 als deadlines, afhankelijk van de toepassing.

Lang niet alle nationale toezichthouders hebben een tijdschema voor de migratie naar de kwantumtechnologie vastgesteld, maar zij die dat wel doen, houden zich over het algemeen aan het tijdsbestek van 2030-2035.

Wanneer gaan kwantumcomputers problemen veroorzaken? Of het nu 2034 of 2050 is, het wordt vast en zeker te vroeg. Het immense succes van cryptografie van de afgelopen vijftig jaar heeft ervoor gezorgd dat we criptografie overal voor gebruiken: van vaatwassers en pacemakers tot satellieten. De meeste upgrades zijn eenvoudig en passen op een natuurlijke manier in de levenscyclus van het product. Maar dit zal worden gevolgd door een lange reeks van zeer moeilijke en kostbare upgrades.

Laten we dan nu eens kijken naar de migratie naar post-kwantumcryptografie.

Om prioriteiten te kunnen stellen, is het belangrijk te beseffen dat er een groot verschil is in de moeilijkheidsgraad, impact en urgentie van de post-kwantummigratie voor de verschillende soorten cryptografie die nodig zijn om veilige verbindingen te creëren. Voor de meeste organisaties zijn er na de kwantummigratie feitelijk twee migraties nodig: het key agreement en de handtekeningen/certificaten. Laten we dit uitleggen aan de hand van het voorbeeld van het maken van een beveiligde verbinding met een website in een browser.

Het cryptografische werkpaard van een verbinding is een symmetrische code, zoals AES-GCM. Dat is wat je je voorstelt wanneer je aan cryptografie denkt: beide partijen, in dit geval de browser en de server, hebben een gedeelde sleutel en ze versleutelen/ontsleutelen hun berichten met dezelfde sleutel. Zonder deze sleutel kun je niets lezen of wijzigen.

Het goede nieuws is dat symmetrische cijfers, zoals AES-GCM, al post-kwantum veilig zijn. Er bestaat een veelvoorkomend misverstand dat het kwantumalgoritme van Grover vereist dat we de lengte van symmetrische sleutels verdubbelen. Bij nadere beschouwing van het algoritme wordt het duidelijk dat het niet praktisch is. De manier waarop NIST, het Amerikaanse National Institute for Standards and Technology (dat het voortouw neemt in de standaardisatie van post-kwantumcryptografie) haar post-kwantumbeveiligingsniveaus definieert, is veelzeggend. Ze definiëren een specifiek beveiligingsniveau door te stellen dat het systeem net zo moeilijk te kraken moet zijn met een klassieke of een kwantumcomputer als met een bestaande symmetrische code, en wel als volgt:

Niveau	Definitie, minstens zo moeilijk te kraken als …	Voorbeeld
1	Het terughalen van de sleutel van AES-128 door middel van een uitgebreide zoekopdracht	ML-KEM-512, SLH-DSA-128s
2	Het vinden van een botsing in SHA256 door middel van een uitgebreide zoekopdracht	ML-DSA-44
3	Het terughalen van de sleutel van AES-192 door middel van een uitgebreide zoekopdracht	ML-KEM-768, ML-DSA-65
4	Het vinden van een botsing in SHA384 door middel van een uitgebreide zoekopdracht
5	Het terughalen van de sleutel van AES-256 door middel van een uitgebreide zoekopdracht	ML-KEM-1024, SLH-DSA-256s, ML-DSA-87

^{NIST PQC-beveiligingsniveaus voor post-kwantumcomputers: hoe hoger, hoe moeilijker te omzeilen ('veiliger'). De ML-DSA-, SLH-DSA- en ML-KEM-voorbeelden worden hieronder behandeld.}

Het voorstel om de sleutellengtes van symmetrische cryptografie te verdubbelen heeft goede bedoelingen. Vaak zijn de extra kosten niet zo hoog en wordt het theoretische risico volledig geminimaliseerd. Het opschalen van symmetrische cryptografie is goedkoop: twee keer zoveel bits kost meestal veel minder dan de helft. Op het eerste gezicht is het dus goed advies.

Maar als we vasthouden aan AES-256, lijkt het ook logisch om ook voor de public key cryptografie NIST PQC-niveau 5 te eisen. Het probleem is dat public key cryptografie niet erg goed schaalbaar is. Afhankelijk van het schema leidt de overgang van niveau 1 naar niveau 5 doorgaans tot meer dan een verdubbeling van het dataverbruik en de CPU-kosten. Zoals we zullen zien, is het implementeren van post-kwantumhandtekeningen op niveau 1 al lastig, en is het implementeren ervan op niveau 5 slopend.

Belangrijker nog: organisaties beschikken over beperkte middelen. Wij willen niet dat een organisatie prioriteit geeft aan het upgraden van AES-128 ten koste van het laten bestaan van de zeer kwantumgevoelige RSA.

Symmetrische cijfers alleen zijn echter niet voldoende: hoe weet ik welke sleutel ik moet gebruiken als ik voor het eerst een website bezoek? De browser kan niet zomaar een willekeurige sleutel versturen, aangezien iedereen die meekijkt die sleutel ook kan zien. Je zou denken dat dit onmogelijk is, maar er is een slimme wiskundige manier om dit op te lossen. De browser en de server kunnen het eens worden over een gedeelde sleutel. Een dergelijk schema wordt een sleutelovereenkomstprotocol ofwel een 'key agreement' genoemd en wordt tijdens de TLS-handshake uitgevoerd. In 2024 was vrijwel al het verkeer beveiligd met X25519, een key agreement in Diffie-Hellman-stijl, maar de beveiliging ervan wordt door het algoritme van Shor op een kwantumcomputer volledig omzeild. Zo kan elke opgeslagen communicatie die vandaag de dag met Diffie-Hellman is beveiligd, in de toekomst door een kwantumcomputer worden ontcijferd.

Daarom is het dringend noodzakelijk om vandaag nog een key agreement te actualiseren. Gelukkig is de implementatie van post-kwantum key agreement relatief eenvoudig. Zoals we eerder zagen, is eind 2025 de helft van de verzoeken via Cloudflare al met post-kwantum key agreement beveiligd!

Key agreement maakt het mogelijk om op een veilige manier overeenstemming te bereiken over een sleutel, maar luchtdicht is dit niet: we weten namelijk niet met wie we overeenstemming hebben bereikt over de sleutel. Als we alleen sleutelafspraken maken, kan een aanvaller tussen de twee partijen afzonderlijke key agreements maken met de browser en de server, en alle uitgewisselde berichten opnieuw versleutelen. Om dit te voorkomen hebben we nog één laatste ingrediënt nodig: authenticatie.

Dit gebeurt door middel van handtekeningen. Wanneer je bijvoorbeeld een website bezoekt, zoalscloudflare.com, presenteert de webserver een certificaat dat is ondertekend door een certificeringsinstantie (certification authority of CA). Deze instantie garandeert dat de public key in dat certificaat door cloudflare.com wordt beheerd. De webserver ondertekent vervolgens de handshake en de gedeelde sleutel met behulp van de private key die overeenkomt met de public key in het certificaat. Hierdoor kan de klant er zeker van zijn dat hij een key agreement met cloudflare.com heeft.

Tegenwoordig worden RSA en ECDSA veel gebruikt om traditionele handtekeningen te leveren. Ook hiermee wordt door Shor's algoritme korte metten gemaakt, waardoor een kwantumaanvaller elke handtekening kan vervalsen. Dat betekent dat een aanvaller met een kwantumcomputer zich kan voordoen als elke website waarvoor wij niet-post-kwantumcertificaten accepteren (of als een MitM).

Deze aanval kan alleen worden uitgevoerd zodra kwantumcomputers RSA/ECDSA kunnen kraken. Dit maakt het upgraden van handtekeningschema's voor TLS op het eerste gezicht minder urgent, aangezien iedereen pas voorafgaand aan Q-day gemigreerd moet zijn. Helaas zullen we zien dat de migratie naar post-kwantumhandtekeningen veel moeilijker is en meer tijd zal kosten.

Voordat we ingaan op de technische uitdagingen bij de migratie van het internet naar post-kwantumcryptografie, gaan we eerst kijken hoe we hier terecht zijn gekomen en wat we de komende jaren kunnen verwachten. Laten we beginnen met hoe post-kwantumcryptografie is ontstaan.

De natuurkundigen Feynman en Manin presenteerden rond 1980 en onafhankelijk van elkaar het concept van kwantumcomputers. Het duurde nog eens 14 jaar voordat Shor zijn algoritme publiceerde waarmee hij RSA/ECC aanviel. De meeste post-kwantumcryptografie dateert van vóór het beroemde algoritme van Shor.

Er zijn verschillende takken van post-kwantumcryptografie, zoals lattice-gebaseerd, hash-gebaseerd, multivariate, code-gebaseerd en isogeny-gebaseerd. Met uitzondering van de op isogenie gebaseerde cryptografie werd geen van deze methoden oorspronkelijk als post-kwantumcryptografie ontwikkeld. De eerste code- en hash-based schema's zijn feitelijk tijdgenoten van RSA. Ze werden in de jaren 1970 voorgesteld en dateren van ruim vóór de publicatie van Shor's algoritme in 1994. Bovendien is het eerste multivariabele schema uit 1988 aanzienlijk ouder dan het algoritme van Shor. Het is een mooi toeval dat de succesvolste tak, lattice-based cryptografie, Shor's meest verwante tijdgenoot is omdat die in in 1996 werd voorgesteld. Ter vergelijking: elliptic curve cryptography, die tegenwoordig veel wordt gebruikt, werd voor het eerst in 1985 voorgesteld.

In de jaren na de publicatie van Shor's algoritme namen cryptografen de bestaande cryptografie onder de loep: wat zijn de duidelijke defecten en wat kan beveiligd worden in het post-kwantumtijdperk? In 2006 vond de eerste jaarlijkse internationale workshop over post-kwantumcryptografie plaats. Na die conferentie werd een inleidende tekst opgesteld, die goed bruikbaar is als introductie tot het vakgebied. Een opvallend aandachtspunt is het verdwijnen van het Rainbow-handtekeningschema. In datzelfde jaar, 2006, werd de elliptische-curve-key agreement X25519 voorgesteld, die nu de meeste internetverbindingen beveiligt, hetzij op zichzelf of als hybride met de post-kwantum ML-KEM-768. 

Tien jaar later, in 2016, schreef NIST, het Amerikaanse National Institute of Standards and Technology, een openbare competitie uit om post-kwantumcryptografie te standaardiseren. Ze gebruikten een soortgelijk open formaat als werd gebruikt om AES in 2001 en SHA3 in 2012 te standaardiseren. Iedereen kon meedoen door plannen in te dienen en de voorstellen te evalueren. Cryptografen van over de hele wereld dienden algoritmes in. De aandacht werd gefocust door de lijst met inzendingen in drie ronden te verkorten. Van de oorspronkelijke 82 inzendingen haalden er acht de finale, op basis van de publieke feedback. Van die acht koos NIST er in 2022 vier uit om als eerste te standaardiseren: één KEM (voor key agreement) en drie handtekeningenschema's.

Oude naam	Nieuwe naam	Tak
Kyber	ML-KEM (FIPS 203) Standaard voor het op module-lattice-gebaseerde key encapsulation-mechanisme	Lattice-gebaseerd
Dilithium	ML-DSA (FIPS 204) Standaard voor op module-lattice-gebaseerde digitale handtekeningen	Lattice-gebaseerd
SFINCIES+	SLH-DSA (FIPS 205) Standaard voor de stateless hash-gebaseerde digitale handtekening	Hash-gebaseerd
Falcon	FN-DSA (nog niet gestandaardiseerd) Standaard voor FFT via NTRU-lattice digitale handtekening	Lattice-gebaseerd

De definitieve standaarden voor de eerste drie zijn in augustus 2024 gepubliceerd. FN-DSA volgt nog, en we zullen later uitleggen waarom.

ML-KEM is het enige post-kwantum key agreement dat momenteel gestandaardiseerd is. Afgezien van enkele incidentele problemen met de grotere sleutelgroottes, is het grotendeels een directe upgrade.

Bij de handtekeningen ligt de situatie anders: het is veelzeggend dat NIST ervoor heeft gekozen om er al drie te standaardiseren. En er zullen in de toekomst nog meer handtekeningen worden gestandaardiseerd. De reden hiervoor is dat geen van de voorgestelde handtekeningen in de verste verte ideaal is. Ze hebben namelijk allemaal veel grotere sleutels en handtekeningen dan wij gewend zijn.

Vanuit een veiligheidsperspectief is SLH-DSA de meest conservatieve keuze, die echter ook het slechtste presteert. Voor public key en handtekeninggroottes is FN-DSA de beste optie van de drie, maar het is moeilijk om de handtekening veilig te gebruiken vanwege de drijvende-kommaberekeningen. Aangezien de toepasbaarheid van FN-DSA beperkt en het ontwerp complex is, heeft NIST ervoor gekozen om zich eerst op de andere drie schema's te richten.

Daarom is ML-DSA nu de standaardkeuze. Hieronder staat een meer diepgaande vergelijking.

Het is niet voldoende om alleen de NIST-standaarden te hanteren. Het is ook nodig om de manier te standaardiseren waarop de nieuwe algoritmen in protocollen op hoger niveau worden gebruikt. Vaak kan dit zo eenvoudig zijn als het toewijzen van een identificatiecode aan de nieuwe algoritmen, zoals het key agreement in TLS. In andere gevallen, zoals DNSSEC, moet er wat dieper worden nagedacht. Veel IETF-werkgroepen bereiden zich al jaren voor op de komst van de definitieve NIST-standaarden. We dachten dat veel protocolintegraties kort daarna afgerond zouden zijn, vóór eind 2024. Dat was te optimistisch: sommige zijn klaar, maar vele andere nog niet.

Laten we met het goede nieuws beginnen en kijken wat er al is gedaan.

• Het hybride TLS-key agreement X25519MLKEM768 dat X25519 en ML-KEM-768 combineert (later meer hierover), is klaar voor gebruik en wordt inderdaad op grote schaal toegepast. Ook andere protocollen maken gebruik van ML-KEM in een hybride werkingsmodus, zoals IPsec, dat klaar is voor eenvoudige installaties. (Voor bepaalde installaties bestaat er nog een klein probleempje dat opgelost moet worden. We zullen dit in een toekomstige blogpost verder uitleggen.) Mogelijk komt het als een verrassing dat de bijbehorende RFC's nog niet zijn gepubliceerd. Voor het registreren van een key agreement bij TLS of IPsec is echter geen RFC nodig. In beide gevallen wordt de RFC nog steeds nageleefd om verwarring te voorkomen bij degenen die een RFC verwachten. Voor TLS is het vereist om het key agreement als aanbevolen te markeren.

• Voor handtekeningen is de integratie van ML-DSA in X.509-certificaten en TLS gebruiksklaar. De eerste is een recent uitgegeven RFC en de laatste heeft er geen nodig.

En dan nu het slechte nieuws. Op het moment van schrijven in oktober 2025, had de IETF nog niet vastgelegd hoe de hybride certificaten eruit moeten zien: certificaten waarin zowel een post-kwantum- als een traditioneel handtekeningenschema worden gecombineerd. Maar het scheelt niet veel. Wij hopen dat dit begin 2026 opgelost zal zijn.

Als het dus alleen om het toekennen van een aantal identificatiegegevens gaat, wat is dan de oorzaak van de vertraging? Het gaat vooral om keuzes. Laten we beginnen met de keuzes die gemaakt moesten worden in ML-DSA.

De twee belangrijkste discussiepunten voor ML-DSA-certificaten waren prehashing en de indeling van de private keys.

Prehashing houdt in dat één deel van het systeem het bericht hasht, terwijl een ander deel de definitieve handtekeningen creëert. Dit is handig als je geen groot bestand voor een handtekening naar een HSM wilt sturen. Vroege versies van ML-DSA ondersteunen prehashing met SHAKE256, maar dat was niet duidelijk. In de definitieve versie van ML-DSA heeft NIST twee varianten opgenomen: de reguliere ML-DSA en een expliciet vooraf gehashte versie, zodat elke hash gekozen kan worden. Het is niet ideaal om verschillende varianten te hebben, omdat gebruikers dan moeten kiezen welke ze willen gebruiken. Bovendien ondersteunt niet alle software alle varianten en moeten alle varianten getest en gevalideerd worden. Het is niet controversieel om slechts één variant te willen kiezen, maar de vraag is welke. Na veel discussie werd gekozen voor de reguliere ML-DSA.

Het tweede punt is de indeling van de private key. Vanwege de manier waarop de kandidaten met elkaar worden vergeleken op basis van prestatiebenchmarks, lijkt het erop dat de oorspronkelijke ML-DSA-inzending een deel van de berekeningen in de private key cachet. Dit betekent dat de private key (enkele kilobytes) groter dan nodig is en dat er meer validatiestappen nodig zijn. Er werd voorgesteld om de private key terug te brengen tot de essentie: slechts één seed van 32 bytes. Voor de definitieve standaard besloot NIST om zowel de seed als de oorspronkelijke, grotere private key toe te staan. Dit is niet ideaal: het zou beter zijn geweest als er één was gekozen. In dit geval kon de IETF geen keuze maken en werd er zelfs een derde optie toegevoegd: een paar bestaande uit de seed en de uitgebreide private key. Technisch gezien was bijna iedereen het erover eens dat de seed de beste keuze was. De reden dat dit niet in de smaak viel, was dat sommige leveranciers al sleutels hadden gemaakt waarvan ze de seed niet hadden bewaard. Ja, we hebben al een post-kwantum-geschiedenis. Het duurde bijna een jaar om deze twee keuzes te maken.

Om een hybride ML-DSA-handtekeningschema te definiëren, moeten er nog veel meer keuzes worden gemaakt. Met welk traditioneel schema kan ML-DSA worden gecombineerd? Welk beveiligingsniveau bestaat er aan weerszijden? Dan moeten we ook voor beide schema's keuzes maken: welke indeling van de private key moeten we gebruiken? Welke hash moet met ECDSA worden gebruikt? Hybriden brengen nieuwe, eigen vragen met zich mee. Staan we hergebruik van de sleutels in de hybride toe en willen we daarom stripping-aanvallen voorkomen? Ook de vraag over prehashing komt terug met een derde optie: prehash op hybride-niveau.

De ontwerpversie van de hybride ML-DSA-handtekeningen van oktober 2025 bevat 18 varianten, een daling ten opzichte van 26 een jaar eerder. Iedereen is het erover eens dat dit te veel is, maar het is lastig om het nog verder terug te brengen. Om eindgebruikers te helpen bij hun keuze, werd een korte lijst toegevoegd. Deze begon met drie opties, maar groeide natuurlijk uit tot zes. Wij denken dat MLDSA44-ECDSA-P256-SHA256 veel ondersteuning zal krijgen en uitgebreid op het internet zal worden gebruikt.

Laten we nu teruggaan naar het key agreement waarvoor de standaarden werden vastgesteld.

De volgende stap is softwareondersteuning. Niet alle ecosystemen kunnen zich met dezelfde snelheid ontwikkelen, maar we hebben al een grote acceptatie van post-kwantum key agreement gezien om nu al iets te doen aan de 'nu opslaan, later ontcijferen'-dreiging. Recente versies van alle belangrijke browsers en veel TLS-bibliotheken en -platformen, met name OpenSSL, Go en recente Apple OS'en, hebben standaard X25519MLKEM768 ingeschakeld. Hier is ons overzicht.

Ook voor TLS is er weer een groot verschil tussen key agreement en handtekeningen. Voor key agreement kunnen de server en de client onafhankelijk van elkaar ondersteuning voor post-kwantum key agreement toevoegen en inschakelen. Als dit aan weerszijden is ingeschakeld, gebruikt de TLS-onderhandeling een post-kwantum key agreement. In dit blogbericht gaan we dieper op de TLS-onderhandelingen in. Als jouw product alleen TLS gebruikt, kan het 'nu opslaan, later ontcijferen'-probleem worden opgelost met een eenvoudige software-update van de TLS-bibliotheek.

Post-kwantum TLS-certificaten zijn omslachtiger. Tenzij je beide kanten beheert, moeten er twee certificaten worden geïnstalleerd: een post-kwantumcertificaat voor de nieuwe clients en een traditioneel certificaat voor de oude clients. Als je automatische certificaatuitgifte nog niet gebruikt, is dit wellicht een goede reden om dat eens te proberen. Met TLS kan de client aangeven welke handtekeningenschema's hij ondersteunt, zodat de server ervoor kan kiezen om een post-kwantumcertificaat alleen te verstrekken aan clients die dit ondersteunen. Hoewel bijna alle TLS-bibliotheken het instellen van meerdere certificaten ondersteunen, stellen jammer genoeg niet alle servers deze configuratie beschikbaar. Is dat wel het geval, dan is in de meeste gevallen toch een configuratiewijziging nodig. (Hoewel caddy dat ongetwijfeld voor jou zal regelen.)

Over post-kwantumcertificaten gesproken: het zal nog wel even duren voordat certificeringsinstanties (CA's) deze kunnen uitgeven. Hun HSM's hebben eerst (hardware) ondersteuning nodig, die vervolgens gecontroleerd moet worden. Bovendien moet het CA/Browserforum het gebruik van de nieuwe algoritmen goedkeuren. Rootprogramma's hebben verschillende meningen over tijdlijnen. Via via vernemen we dat een van de rootprogramma's bezig is met het voorbereiden van een pilot om ML-DSA-87-certificaten van één jaar te accepteren, mogelijk zelfs al vóór eind 2025. Er wordt een CA/Browserforumstemming georganiseerd om dit te ondersteunen. Anderzijds is er Chrome, dat liever eerst het grote certificaatprobleem oplost. Voor degenen die er als eerste bij betrokken zijn, vormen de audits waarschijnlijk een knelpunt, omdat er na de publicatie van de NIST-standaarden veel inzendingen zullen volgen. Hoewel we de eerste post-kwantumcertificaten in 2026 zullen zien, is het onwaarschijnlijk dat ze vóór 2027 algemeen beschikbaar zijn of door alle browsers vertrouwd zullen worden.

We bevinden ons in een interessante tussenperiode, waarin veel internetverkeer door post-kwantum key agreement wordt beschermd, maar waarin geen enkel openbaar post-kwantumcertificaat wordt gebruikt.

NIST is nog niet klaar met het standaardiseren van post-kwantumcryptografie. Er vinden nog twee post-kwantumcompetities plaats: ronde 4 en de handtekeningen on-ramp.

NIST heeft tot nu toe slechts één post-kwantum key agreement gestandaardiseerd: ML-KEM. Ze willen graag een tweede hebben, een reserve-KEM, die niet op lattices is gebaseerd voor het geval dat deze zwakker blijken te zijn dan verwacht. Om die te vinden, hebben ze de oorspronkelijke competitie uitgebreid met een vierde ronde, om zo een reserve-KEM uit de finalisten te selecteren. In maart 2025 werd HQC voor standaardisatie geselecteerd.

HQC presteert op alle vlakken veel slechter dan ML-KEM. HQC-1, de variant met het laagste beveiligingsniveau, vereist 7 kB aan data. Dit is bijna het dubbele van de 3 kB die nodig is voor ML-KEM-1024, de variant met het hoogste beveiligingsniveau. Er is een vergelijkbaar verschil in CPU-prestaties. Bovendien schaalt HQC slechter naarmate het beveiligingsniveau hoger is: ML-KEM-1024 kost ongeveer het dubbele van ML-KEM-512, terwijl het hoogste beveiligingsniveau van HQC drie keer zoveel data (21 kB!) en meer dan vier keer zoveel rekenkracht vereist.

Hoe zit het met de beveiliging? Voor bescherming tegen steeds krachtigere aanvallen, heeft ML-KEM-768 een duidelijk voordeel ten opzichte van HQC-1. Het presteert veel beter en heeft een enorme beveiligingsmarge op niveau 3 vergeleken met niveau 1. Hoe zit het met ontwikkelingsdoorbraken? Zowel ML-KEM als HQC gebruiken een vergelijkbare algebraïsche structuur op basis van respectievelijk eenvoudige lattices en codes. Het is dus niet ondenkbaar dat daar een doorbraak voor beide mogelijk is. Ook zonder de algebraïsche structuur voelen codes en lattices verwant aan. We zijn al flink aan het speculeren: een catastrofale aanval op lattices heeft mogelijk geen invloed op de codes, maar het zou ook geen grote verrassing zijn als dat wel het geval is. RSA en ECC, die meer van elkaar verschillen, worden immers allebei door kwantumcomputers gekraakt.

Toch kan het een geruststellende gedachte zijn om HQC achter de hand te houden, voor alle zekerheid. We willen hier graag een anekdote delen uit de chaotische week waarin het nog niet duidelijk was of Chen's kwantumalgoritme voor lattices fouten bevatte. Waarmee moet ML-KEM worden vervangen als dit probleem zich voordoet? Er werd kort gedacht aan HQC, maar het was duidelijk dat een aangepaste variant van ML-KEM nog steeds veel beter zou presteren.

Even een stapje terug: dat we op zoek zijn naar een tweede efficiënte KEM is een luxepositie. Als ik iets voor een nieuw post-kwantumschema zou mogen wensen, zou dat geen beter KEM zijn, maar een beter handtekeningschema. Het is afwachten of mijn wens wordt vervuld.

Eind 2022, na de aankondiging van de eerste vier keuzes, schreef NIST ook een nieuwe competitie uit die de Signatures Onramp werd genoemd, om aanvullende handtekeningenschema's te vinden. Deze competitie heeft twee doelen. Het eerste is het indekken tegen cryptoanalytische doorbraken van de lattice-gebaseerde cryptografie. NIST wil een handtekening standaardiseren die beter presteert dan SLH-DSA (zowel qua grootte als rekenkracht), maar die niet op lattices is gebaseerd. Ten tweede zijn ze op zoek naar een handtekeningenschema dat goed presteert in situaties waarin de bestaande handtekeningen niet goed presteren. We zullen hier later in deze blog uitgebreid op ingaan.

In juli 2023 publiceerde NIST de 40 inzendingen voor een eerste openbare beoordelingsronde. De cryptografische gemeenschap ging aan de slag en, zoals gebruikelijk in een eerste ronde, werden veel systemen binnen een week gekraakt. In februari 2024 waren tien inzendingen volledig verworpen en waren verschillende andere drastisch verzwakt. Uit de overgebleven kandidaten selecteerde NIST in oktober 2024 14 inzendingen voor de tweede ronde.

Een jaar geleden schreven we een blogpost waarin we deze 14 inzendingen uitgebreid hebben besproken. Kortom: er is verbazingwekkende vooruitgang geboekt op het gebied van post-kwantum-handtekeningschema's. We zullen hier later kort op ingaan en een update geven over de ontwikkelingen sinds vorig jaar. Het is belangrijk te vermelden dat, net als bij de post-kwantumcompetitie, het selectieproces vele jaren in beslag zal nemen. Het is onwaarschijnlijk dat deze on-ramp-handtekeningschema's vóór 2028 gestandaardiseerd zullen worden, zolang ze daarvoor nog niet zijn gekraakt. Dat betekent dat we er niet op kunnen vertrouwen dat betere handtekeningenschema's onze huidige problemen zullen oplossen, ook al zijn ze in de toekomst zeer welkom. Zoals Eric Rescorla, de redacteur van TLS 1.3, schrijft: "Je gaat de strijd aan met de algoritmes die je hebt, niet met de algoritmes die je zou willen hebben."

Laten we met dat in gedachten eens naar de geboekte vooruitgang kijken.

Nu we de context hebben begrepen, duiken we dieper in de details van deze X25519MLKEM768 die nu veel wordt gebruikt.

Eerst het post-kwantumdeel. ML-KEM werd ingediend onder de naam CRYSTALS-Kyber. Hoewel het een Amerikaanse standaard is, zijn ontwerpers ervan actief in de industrie en de academische wereld in Frankrijk, Zwitserland, Nederland, België, Duitsland, Canada, China en de Verenigde Staten. Laten we eens naar de prestaties kijken.

Tegenwoordig gebruikt het overgrote deel van de klanten de traditionele key agreement X25519. Laten we die eens vergelijken met ML-KEM.

^{Grootte en CPU van X25519 en ML-KEM. De prestaties variëren aanzienlijk afhankelijk van het hardwareplatform en de implementatiebeperkingen en mogen slechts als een ruwe indicatie worden beschouwd.}

ML-KEM-512, -768 en -1024 zijn net zo resistent tegen (kwantum)aanvallen als AES-128, -192 en -256. Zelfs op AES-128-niveau is ML-KEM veel groter dan X25519, met 800 + 768 = 1568 bytes, terwijl X25519 slechts 64 bytes nodig heeft.

Anderzijds is zelfs ML-KEM-1024 doorgaans aanzienlijk sneller dan X25519, hoewel dit nogal kan variëren, afhankelijk van het platform en de toepassing.

Van die snelheidswinst maken we nog geen gebruik. Net als veel andere early adopters spelen we op safe en implementeren we een hybride key agreement die X25519 en ML-KEM-768 combineert. Twee redenen waarom deze combinatie waarschijnlijk verrassend is.

1. Waarom X25519 ('128 bits-beveiliging') met ML-KEM-768 ('192 bits-beveiliging') combineren?

2. Waarom zou je de non-post-kwantum X25519 gebruiken?

Het schijnbare verschil in het beveiligingsniveau is een indekking tegen verbeteringen van de cryptoanalyse in lattice-gebaseerde cryptografie. Er is veel vertrouwen in de (niet-post-kwantum) beveiliging van X25519: het evenaren van AES-128 is meer dan voldoende. Hoewel we momenteel tevreden zijn met de veiligheid van ML-KEM-512, kan de cryptoanalyse in de komende tientallen jaren verbeteren. Daarom willen we voorlopig nog een marge aanhouden.

Er zijn twee redenen waarom X25519 is opgenomen. Ten eerste bestaat er altijd een kleine kans dat een doorbraak alle varianten van ML-KEM onveilig maakt. In dat geval biedt X25519 nog steeds non-post-kwantumbeveiliging en heeft onze post-kwantummigratie de situatie niet verergerd.

Belangrijker is dat we ons niet alleen zorgen maken over aanvallen op het algoritme, maar ook over aanvallen op de toepassing. Een opmerkelijk voorbeeld van pure mazzel is dat van KyberSlash, een timingaanval die veel toepassingen van Kyber (een eerdere versie van ML-KEM) trof, waaronder die van ons. Gelukkig heeft KyberSlash geen invloed op Kyber omdat het in TLS wordt gebruikt. Een vergelijkbare toepassingsfout die daadwerkelijk gevolgen zou hebben voor TLS, vereist waarschijnlijk een actieve aanvaller. In dat geval is het waarschijnlijke doel van de aanvaller niet om de gegevens over tientallen jaren te ontsleutelen, maar om een cookie of ander token te stelen of een schadelijke payload te injecteren. Door X25519 toe te voegen, wordt een dergelijke aanval voorkomen.

Hoe goed presteren ML-KEM-768 en X25519 samen in de praktijk?

Aangezien Google zich terdege bewust is van de mogelijke problemen met compatibiliteit en prestaties, startte het bedrijf al in 2016, ofwel hetzelfde jaar waarin NIST hun competitie uitschreef, een eerste experiment met post-kwantumcryptografie. In 2018 volgde een tweede, groter en gezamenlijk experiment van Cloudflare en Google. We hebben twee verschillende hybride post-kwantum key agreements getest: CECPQ2, een combinatie van de lattice-gebaseerde NTRU-HRSS en X25519, en CECPQ2b, een combinatie van de isogeny-gebaseerde SIKE en opnieuw X25519. NTRU-HRSS is qua omvang vergelijkbaar met ML-KEM, maar vergt aan clientzijde iets meer rekenkracht. SIKE daarentegen heeft hele kleine sleutels, die heel veel rekenkracht vergen, en werd in 2022 volledig gekraakt. Wat betreft de TLS-handshake-tijden presteerde X25519+NTRU-HRSS uitstekend.

Helaas ondervond een klein maar belangrijk deel van de cliënten een verbroken verbinding met NTRU-HRSS. De reden was de grootte van de NTRU-HRSS-sleutelshares. Vroeger paste het eerste bericht dat de client verstuurde bij het maken van een TLS-verbinding, het zogenaamde ClientHello, vrijwel altijd in één netwerkpakket. De TLS-specificatie staat een grotere ClientHello toe, maar niemand maakte daar echt gebruik van. Dit zorgt opnieuw voor protocol-verstarring, omdat er middleboxes, load-balancers en andere software zijn die er gewoon van uitgaan dat de ClientHello altijd in één pakket past.

In de daaropvolgende jaren bleven we experimenteren met PQ. In 2022 stapten we over op Kyber en in 2024 op ML-KEM. Chrome heeft uitstekend werk geleverd door contact te leggen met leveranciers waarvan de producten niet compatibel waren. Als deze compatibiliteitsproblemen er niet waren geweest, hadden we Chrome waarschijnlijk vijf jaar eerder al zien beginnen met het versnellen van post-kwantum key agreement. Het duurde tot maart 2024 voordat Chrome er voldoende vertrouwen in had om het post-kwantum key agreement standaard op Desktop in te schakelen. Sindsdien hebben veel andere clients en alle grote browsers zich bij Chrome aangesloten en standaard het post-kwantum key agreement ingeschakeld. Een onvolledige tijdlijn:

Juli 2016	Het eerste experiment met PQ (CECPQ) van Chrome
Juni 2018	Het experiment (CECPQ2) van Cloudflare / Google
Oktober 2022	Cloudflare schakelt PQ standaard aan de serverzijde in
November 2023	Chrome verhoogt PQ naar 10% op Desktop
Maart 2024	Chrome schakelt PQ standaard in op Desktop
Augustus 2024	Go schakelt PQ standaard in
November 2024	Chrome schakelt PQ standaard in op Android en Firefox op Desktop.
April 2025	OpenSSL schakelt PQ standaard in
Oktober 2025	Apple rolt PQ standaard uit met de release van iOS/iPadOS/macOS 26

Opvallend is dat er een verschil zit tussen de mate waarin Chrome PQ op Desktop en Android ondersteunt. Hoewel ML-KEM geen grote impact op de prestaties heeft, zoals je dat in de grafieken kunt zien, is het zeker niet verwaarloosbaar, vooral niet op de 'long tail' van tragere verbindingen die vaker voorkomen op mobiele apparaten. Er moest iets langer nagedacht worden om hiermee door te gaan.

Maar nu zijn we er dan eindelijk: meer dan 50% (en het neemt toe!) van het menselijke verkeer is beveiligd tegen 'nu opslaan/later ontcijferen'-dreigingen. Daarmee is een post-kwantum key agreement de nieuwe basisbeveiliging voor het web.

Browsers zijn één kant van het verhaal. Maar hoe zit het met servers?

In 2022 hebben we voor vrijwel al onze klanten post-kwantum key agreement aan de serverzijde ingeschakeld. Google deed hetzelfde voor de meeste van hun servers (behalve GCP) in 2023. Sindsdien hebben velen dit voorbeeld gevolgd. Jan Schaumann post regelmatig scans van de top 100.000 domeinen. In zijn post van september 2025 meldt hij dat 39% nu PQ steunt, tegenover 28% slechts zes maanden daarvoor. Uit zijn onderzoek blijkt dat niet alleen de ondersteuning wordt uitgerold bij grote dienstverleners, zoals Amazon, Fastly, Squarespace, Google en Microsoft, maar dat ook steeds meer zelfgehoste servers ondersteuning van Hetzner en OVHcloud toevoegen.

Dit is het openbaar toegankelijke web. Hoe zit het met servers achter een dienst als Cloudflare?

In september 2023 hebben we ondersteuning toegevoegd voor onze klanten om post-kwantum key agreement mogelijk te maken op verbindingen van Cloudflare naar hun startpunt. Dat is verbinding (3) in het volgende diagram:

^{Typische verbindingsstroom wanneer een gebruiker een niet-gecachte pagina wil bezoeken.}

In 2023 ondersteunde slechts 0,5% van de startpunten een post-kwantum key agreement. Tot 2024 is daar niet veel verandering in gekomen. Dit jaar, in 2025, zien we dat de ondersteuning langzaam toeneemt met de uitrol van softwareondersteuning. We zitten nu op 3,7%.

^{Fractie van startpunten die de post-kwantum key agreement X25519MLKEM768 ondersteunen.}

3,7% klinkt niet bepaald indrukwekkend vergeleken met de eerdere 50% en 39% voor respectievelijk clients en publieke servers, maar het is ook zeker niet slecht. Er is veel meer diversiteit van de startpunten dan in cliënten: er moeten veel meer mensen iets doen om dat percentage te verhogen. Maar het is nog steeds een meer dan zevenvoudige toename, en laten we niet vergeten dat we in 2024 vierden dat we 1,8% klantondersteuning bereikten. Voor klanten is het lang niet altijd eenvoudig om startpunten te upgraden. Betekent dit dat we post-kwantumbeveiliging mislopen? Nee, niet noodzakelijkerwijs: je kunt de verbinding tussen Cloudflare en jouw startpunt beveiligen door Cloudflare Tunnel in te stellen als sidecar voor het startpunt.

Deze ondersteuning is leuk en aardig, maar zoals we zagen bij browserexperimenten is protocol-verstarring een groot probleem. Hoe zit dat met startpunten? Tja, dat hangt ervan af.

Er zijn twee manieren om post-kwantum key agreement te activeren: de snelle manier en de langzame, maar veiligere manier. In beide gevallen geldt dat als het startpunt geen post-kwantum ondersteunt, alles veilig terugvalt op het traditionele key agreement. We leggen de details in dit blogbericht uit, maar samengevat: voor de snelle manier versturen we de post-kwantumsleutels direct, en voor de veiligere manier wordt er eerst één roundtrip met behulp van HelloRetryRequest gemaakt. Alle grote browsers gebruiken de snelle manier.

We hebben alle startpunten regelmatig gescand om te zien wat ze ondersteunen. Het goede nieuws is dat alle startpunten de veilige, langzame methode ondersteunen. De snelle methode presteerde minder goed: daarbij werd 0,05% van de verbindingen verbroken. Dat is te hoog om de snelle methode standaard in te schakelen. We hebben PQ naar startpunten standaard ingeschakeld met de veiligere methode voor alle niet-zakelijke klanten. Zakelijke klanten kunnen hiervoor kiezen.

Wij zijn pas tevreden als het snel gaat en voor iedereen beschikbaar is. Daarom zullen we voor alle klanten automatisch post-kwantum naar startpunten inschakelen met behulp van de snelle methode, als onze scans aantonen dat het veilig is.

Tot nu toe hebben we het alleen gehad over verbindingen tussen Cloudflare en externe partijen. Er zijn ook veel interne verbindingen binnen Cloudflare (gemarkeerd met 2 in de twee diagrammen hierboven). In 2023 hebben we een grote inspanning verricht om onze interne verbindingen naar post-kwantum key agreement te upgraden. Vergeleken met al onze andere post-kwantuminspanningen, was dit veruit de grootste klus: we hebben alle engineeringteams in het bedrijf gevraagd om te stoppen met wat ze aan het doen waren, een inventarisatie te maken van de data en verbindingen die hun producten beveiligen en deze te upgraden naar post-kwantum key agreement. In de meeste gevallen was de upgrade eenvoudig. Veel teams waren al geüpgraded dankzij de software-updates. Toch kan het nog wel even duren voordat het duidelijk is dat de upgrade al heeft plaatsgevonden! We hebben gelukkig bij deze push geen prestatie- of verstarringsproblemen opgemerkt.

We hebben de meeste interne verbindingen een upgrade gegeven, maar we hebben dit project nog niet afgerond. De belangrijkste verbinding die we in 2023 niet hebben kunnen upgraden, is de verbinding tussen de WARP-client en Cloudflare. In september 2025 is de upgrade gelukt door over te stappen van Wireguard naar QUIC.

Zoals we hebben gezien, is post-kwantum key agreement, ondanks de aanvankelijke problemen met de protocol-verstarring, eenvoudig te implementeren. In de overgrote meerderheid van de gevallen gaat het om een software-update die zonder problemen verloopt. En met een implementatie van 50% (en dat percentage neemt toe) is dit de nieuwe beveiligingsbasis voor het internet.

Laten we het dan nu over de tweede, moeilijkere migratie hebben.

Nu gaan we onze aandacht richten op het verbeteren van de handtekeningen die op internet worden gebruikt.

Vorig jaar, in november 2024, schreven we een uitgebreid artikel over post-kwantum-handtekeningschema's. De meeste informatie is nog steeds actueel, maar er zijn ook een aantal interessante ontwikkelingen. Hier bespreken we enkele hoogtepunten en een aantal geweldige updates van vorig jaar.

Laten we beginnen met het in kaart brengen van de post-kwantumhandtekeningen die we momenteel beschikbaar hebben op het AES-128-beveiligingsniveau: ML-DSA-44 en de twee varianten van SLH-DSA. Wij gebruiken ML-DSA-44 als uitgangspunt, omdat dit het schema is dat in eerste instantie het meeste gebruikt zal worden. Ter vergelijking nemen we ook de eerbiedwaardige Ed25519 en RSA-2048 op die vandaag de dag veel worden gebruikt, evenals FN-DSA-512 die binnenkort gestandaardiseerd zal worden, en een voorbeeld van negen veelbelovende TLS-handtekeningschema's uit de handtekeningen on-ramp.

^{De verschillende handtekeningsschema's op het AES-128-beveiligingsniveau. De CPU-tijden variëren aanzienlijk afhankelijk van het platform en de implementatiebeperkingen en dienen slechts als een ruwe schatting. ⚠️ FN-DSA-ondertekieningstijd bij gebruik van snelle maar gevaarlijke drijvende-kommaberekeningen — zie onderstaande waarschuwing. ⚠️ SQISign-handtekeningen hebben geen timingbeveiliging voor het zijkanaal.}

Het is meteen duidelijk dat geen van de huidige post-kwantum-handtekeningschema's Ed25519 (vergelijkbaar met ECDSA P-256) direct kan vervangen, aangezien de meeste handtekeningen gewoon veel groter zijn. Uitzonderingen zijn SQISign, MAYO, SNOVA en UOV van de on-ramp, maar deze zijn verre van ideaal. MAYO, SNOVA en UOV hebben grote public keys en SQISign vereist veel rekenkracht.

Even vooruitkijken: de beste kandidaat uit de eerste competitie lijkt FN-DSA-512 te zijn. De handtekeningen en de public key van FN-DSA-512 zijn samen slechts 1563 bytes en hebben een redelijke ondertekeningstijd. FN-DSA heeft echter een nadeel: voor acceptabele ondertekeningsprestaties is een snelle drijvende-kommaberekening nodig. Zonder dit protocol verloopt het ondertekenen ongeveer 20 keer langzamer. Maar snelheid is niet genoeg, omdat de drijvende-kommaberekening in een constante tijd moet worden uitgevoerd, anders kan de FN-DSA private key worden teruggehaald door de handtekeningcreatie te timen. Het schrijven van veilige FN-DSA-implementaties blijkt een behoorlijke uitdaging te zijn. Dit maakt FN-DSA gevaarlijk wanneer handtekeningen snel worden gegenereerd, zoals bij een TLS-handshake. Het is goed om te benadrukken dat dit alleen betrekking heeft op de ondertekening. Voor FN-DSA-verificatie is geen drijvende-kommaberekening nodig (en tijdens de verificatie zou er sowieso geen private key kunnen uitlekken.)

Het grootste pijnpunt bij het migreren van het internet naar post-kwantumhandtekeningen is dat er zelfs in één verbinding heel veel handtekeningen zijn. Wanneer je voor het eerst deze website bezoekt, versturen wij vijf handtekeningen en twee public keys.

De meeste hiervan zijn voor de certificaatketen: de CA ondertekent het tussenliggende certificaat, dat het bladcertificaat ondertekent, dat op zijn beurt het TLS-transcript ondertekent om de authenticiteit van de server te bewijzen. Hou je het bij? We komen nog twee handtekeningen tekort.

Deze zijn voor SCT's die nodig zijn voor de certificaattransparantie. Certificaattransparantie (CT) is een belangrijk, maar minder bekend, onderdeel van Web PKI, het ecosysteem dat browserverbindingen beveiligt. Het doel hiervan is om elk uitgegeven certificaat openbaar te registreren, zodat eventuele fouten in de uitgifte achteraf kunnen worden opgespoord. Het is het systeem achter crt.sh en Cloudflare Radar. CT heeft onlangs zijn waarde weer eens bewezen door een frauduleus certificaat voor 1.1.1.1 te vinden.

Certificaattransparantie werkt door onafhankelijke partijen CT-logs te laten uitvoeren. Voordat een CA een certificaat uitgeeft, moet het eerst bij ten minste twee verschillende CT-logs worden ingediend. Een SCT is een handtekening van een CT-logboek dat dient als bewijs of als een ontvangstbewijs dat het certificaat is geregistreerd.

Er zijn twee aspecten van het gebruik van een handtekening die we hier willen benadrukken: of de public key bij de handtekening is inbegrepen en of de handtekening online of offline is.

Voor de SCT's en de handtekening van de root op de intermediate wordt de public key niet tijdens de handshake verzonden. Hiervoor is een schema met kleinere handtekeningen maar grotere public keys, zoals MAYO, SNOVA of UOV, bijzonder geschikt. Bij de overige handtekeningen is de public key inbegrepen. Het is belangrijker om de grootte van de gecombineerde public key en handtekening zo klein mogelijk te houden.

De handshake-handtekening is de enige handtekening die online wordt aangemaakt. Alle andere handtekeningen worden vooraf aangemaakt.  De handshake-handtekening wordt slechts één keer aangemaakt en geverifieerd, terwijl de andere handtekeningen doorgaans meerdere keren door verschillende klanten worden geverifieerd. Dit betekent dat het voor de handshake-handtekening voordelig is om de ondertekenings- en verificatietijd in evenwicht te brengen, aangezien ze zich beide in het 'hot path' bevinden. Voor de andere handtekeningen is het daarentegen de moeite waard om een langere verificatietijd te hebben, en dus een langzamere ondertekening. Dit is een van de voordelen die RSA nog steeds heeft ten opzichte van elliptische curven.

Het combineren van verschillende handtekeningenschema's is een leuke puzzel, maar heeft ook enkele nadelen. Het gebruik van meerdere verschillende schema's vergroot het aanvalsoppervlak, omdat een algoritmische of implementatiekwetsbaarheid in één schema het geheel in gevaar brengt. Bovendien moet het hele ecosysteem meerdere algoritmes implementeren en optimaliseren, wat een grote inspanning vergt.

Welke combinaties zijn dan goede gegadigden?

Gezien de huidige conceptnormen hebben we niet veel keus.

Als we voor alle handtekeningen simpelweg op ML-DSA-44 overstappen, moet er tijdens de TLS-handshake 15 kB aan gegevens van de server naar de client worden verzonden. Is dat veel? Waarschijnlijk wel. We zullen hier later op terugkomen.

Als we nog even wachten en alles behalve de handshake-handtekening vervangen door FN-DSA-512, voegen we uiteindelijk slechts 7 kB toe. Dat is veel beter, maar ik moet nogmaals benadrukken dat het lastig is om FN-DSA-512-ondertekening veilig te implementeren zonder timing van de zijkanalen. Bovendien is de kans groot dat we het onszelf alleen maar moeilijker maken, als we niet voorzichtig zijn. Een andere manier om onszelf vandaag de dag het leven zuur te maken, is met stateful hash-gebaseerde handtekeningen, zoals we dat hier hebben uitgelegd. Al met al lijkt het erop dat FN-DSA-512 en stateful hash-gebaseerde handtekeningen ons een vergelijkbaar en duidelijk prestatievoordeel ten opzichte van ML-DSA-44 geven, maar ze zijn lastig veilig te gebruiken.

Er zijn een aantal veelbelovende nieuwe handtekeningenschema's ingediend tijdens de on-ramp van NIST.

Als je puur naar de grootte kijkt, is SQISign I de duidelijke winnaar, zelfs beter dan RSA-2048. Helaas is de benodigde rekenkracht voor de ondertekening en vooral voor de verificatie te groot. SQISign verkeert in een slechtere positie dan FN-DSA wat betreft implementatiebeveiliging: het is zeer ingewikkeld en het is onduidelijk hoe de ondertekening in constante tijd moet worden uitgevoerd. Voor nichetoepassingen is SQISign mogelijk handig, maar voor een algemene toepassing moeten de verificatietijden aanzienlijk worden verbeterd, zelfs als daarvoor een grotere handtekening moet worden gebruikt. De afgelopen jaren is er enorme vooruitgang geboekt in het verbeteren van de verificatietijd, het vereenvoudigen van het algoritme en het beveiligen van de implementatie voor (varianten van) SQISign. Ze zijn er nog niet, maar de afstand die overbrugd moet worden, is veel kleiner dan we hadden gedacht. Als het tempo van de verbeteringen aanhoudt, dan is een toekomstige SQISign mogelijk een optie voor TLS.

Een conservatieve kandidaat is UOV (unbalanced oil and vinegar). Het is een oud multivariabel schema met een grote public key (66,5 kB), maar kleine handtekeningen (96 bytes). In de loop van afgelopen tientallen jaren zijn er veel pogingen gedaan om structuur in de UOV public keys aan te brengen, om zo een betere balans te krijgen tussen de grootte van de public key en de handtekening. Veel van deze zogenaamde gestructureerde multivariabele schema's, waaronder Rainbow en GeMMS, zijn helaas 'op een laptopje in het weekend' op overtuigende wijze gekraakt. MAYO en SNOVA, waar we later op terugkomen, zijn de nieuwste gestructureerde multivariate-pogingen. UOV zelf is grotendeels ongeschonden gebleven. Verrassend genoeg ontdekte Lars Ran in 2025 een geheel nieuwe 'wedges'-aanval op UOV. Voor UOV had het niet zoveel gevolgen, maar SNOVA en MAYO werden zwaarder getroffen. Het opmerkelijke aan deze aanval is dat die gebaseerd is op een relatief eenvoudig idee: het is verbazingwekkend dat dit idee nog niet eerder is ontdekt. Laten we even teruggaan naar de prestaties: als we UOV voor de root en SCT's combineren met ML-DSA-44 voor de anderen, dan is dat slechts 10 kB — niet zo'n groot verschil met FN-DSA-512.

En dan nu waar iedereen het over heeft:

Als we naar de selectie van vandaag kijken, zien we dat MAYO en vooral SNOVA er qua prestaties geweldig uitzien. Vorig jaar waren de prestaties van SNOVA en MAYO niet zo verschillend, maar nu zijn ze behoorlijk uit elkaar gegaan.

MAYO is ontworpen door de cryptograaf die Rainbow heeft gekraakt. Aangezien dit een gestructureerd multivariabel schema betreft, is de veiligheid ervan zorgvuldig gecontroleerd, maar de functionaliteit ervan is zeer aantrekkelijk (zolang die niet gekraakt wordt). MAYO maakt een nauwkeurige afweging mogelijk tussen de grootte van de handtekening en de public key. Om het eenvoudig te houden, stelden de auteurs bij hun indiening twee concrete varianten voor: MAYO_één met een gebalanceerde handtekening (454 bytes) en een public key (1,4 kB), en MAYO_twee met handtekeningen van 216 bytes met een beheersbare public key van 4,3 kB. De verificatietijden zijn uitstekend, terwijl de ondertekeningstijden iets langzamer zijn dan bij ECDSA, maar veel beter dan bij RSA. Als we beide varianten op de voor de hand liggende manier combineren, dan is het resultaat slechts 4,3 kB. Deze cijfers zijn iets hoger dan vorig jaar, omdat MAYO de parameters opnieuw iets heeft aangepast om rekening te houden met pas ontdekte aanvallen.

Tijdens de competitie heeft SNOVA meer last gehad van aanvallen dan MAYO. SNOVA heeft agressiever gereageerd: in plaats van alleen parameters aan te passen, hebben ze ook de interne werking van het systeem ingrijpend gewijzigd om de aanvallen tegen te gaan en de prestaties te verbeteren. Door SNOVA_(37,17,16,2) en SNOVA_(24,5,23,4) op de voor de hand liggende manier te combineren, voegen we tot onze verrassing slechts 2,1 kB toe.

We verwachten een confrontatie tussen de risicovolle, maar veel kleinere SNOVA en de conservatieve, maar tragere MAYO. Als we verder uitzoomen, zien we dat beide zeer goede prestaties leveren, maar dat ze momenteel te riskant zijn om te gebruiken. Ran's nieuwe 'wedges'-aanval maakt het duidelijk dat multivariabele cryptoanalyse nog steeds verrassend kan zijn, en dus meer tijd en moeite vergt. Het is nog te vroeg om een winnaar aan te wijzen tussen SNOVA en MAYO: laat ze vooral blijven concurreren. Ook al worden ze veilig verklaard, toch het is onwaarschijnlijk dat ze al in 2029 gestandaardiseerd zullen zijn, en dat betekent dat we niet op deze twee kunnen vertrouwen voor de eerste migratie naar post-kwantumauthenticatie.

Even een stapje terug: zijn die 15 kB voor ML-DSA-44 nou echt zo slecht?

Gemiddeld worden er per seconde ongeveer 18 miljoen TLS-verbindingen met Cloudflare tot stand gebracht. Een upgrade naar ML-DSA zou 2,1 Tbps kosten. Dat is 0,5% van onze huidige totale netwerkcapaciteit. Geen probleem, zou je zeggen. De vraag is hoe deze extra bytes de prestaties beïnvloeden.

Het kost 15 kB extra om ML-DSA-44 te gaan gebruiken. Dat is veel vergeleken met de typische handshake van vandaag de dag, maar het is niet veel vergeleken met de JavaScript en images die op veel webpagina worden weergegeven. Het belangrijkste is dat de wijziging die we hier moeten doorvoeren, van invloed is op elke afzonderlijke TLS-verbinding, zowel voor een uitgebreide website als voor een tijdkritische API-aanroep. Bovendien is het probleem niet dat we iets langer moeten wachten. Als je een slechte mobiele verbinding hebt, dan loop je met die extra 15 kB het risico dat je een website niet kunt laden of dat je de verbinding kwijtraakt. (Over bloat gesproken: veel apps voeren verrassend veel TLS-handshakes uit).

Net als bij key agreement is de prestatie niet het enige waar we op letten: we willen in de eerste plaats dat de verbinding slaagt. In 2021 hebben we een experiment uitgevoerd waarbij we de certificaatketen kunstmatig vergrootten om grotere post-kwantumcertificaten te simuleren. Het resultaat hebben we hier samengevat. Een belangrijke les is dat sommige clients of middleboxen niet van certificaatketens van meer dan 10 kB houden. Dit is problematisch bij een migratiestrategie met één certificaat. Bij deze aanpak installeert de server één enkel traditioneel certificaat dat een apart post-kwantumcertificaat bevat in een zogenaamde niet-kritieke extensie. Een client die geen post-kwantumcertificaten ondersteunt, zal de extensie negeren. Bij deze aanpak zorgt de installatie van één enkel certificaat er direct voor dat alle clients met compatibiliteitsproblemen niet langer functioneren. Deze aanpak is dan ook geen optie. Ook op het vlak van prestaties is er sprake van een sterke prestatiedaling bij 10 kB vanwege het initiële congestievenster.

Is 9 kB te veel? De vertraging van de TLS-handshake-tijd bedraagt ongeveer 15%. Wij denken dat dit laatste haalbaar is, maar verre van ideaal: een dergelijke vertraging is merkbaar en mensen stellen de implementatie van post-kwantumcertificaten mogelijk uit.

Chrome is voorzichtiger en heeft 10% als doel gesteld voor de maximale TLS-handshake-vertraging. Zij melden dat de implementatie van post-kwantum key agreement al heeft geleid tot een vertraging van 4% in de TLS-handshake-tijd, gezien de extra 1,1 kB van server naar client en de 1,2 kB van client naar server. Die vertraging is proportioneel groter dan de 15% die we voor 9 kB hebben opgemerkt, maar dat zou verklaard kunnen worden door tragere uploads dan downloads. 

Er is weerstand ontstaan tegen alle aandacht die TLS-handshake-tijden krijgen. Eén argument is dat het hervatten van de sessie de noodzaak wegneemt om de certificaten opnieuw te versturen. Een tweede argument is dat de hoeveelheid data die nodig is om een typische website te bezoeken, veel groter is dan het aantal extra bytes voor post-kwantumcertificaten. Een voorbeeld hiervan is deze publicatie uit 2024, waarin onderzoekers van Amazon de impact van grote post-kwantumcertificaten op data-intensieve TLS-verbindingen hebben gesimuleerd. Zij beweren dat typische verbindingen meerdere verzoeken van honderden kilobytes overdragen en dat de vertraging van de TLS-handshake hierbij vrijwel onzichtbaar is.

Komen sessiehervattingen en honderden kilobytes via een verbinding echter vaak voor? Wij willen graag delen wat wij zien. Wij richten ons op QUIC-verbindingen, die waarschijnlijk worden geïnitieerd door browsers of clients die op browsers lijken. Van alle QUIC-verbindingen met Cloudflare die minimaal één HTTP-verzoek bevatten, is 27% een hervatting. Dit betekent dat belangrijk materiaal van een eerdere TLS-verbinding wordt hergebruikt, waardoor het niet nodig is om certificaten te verzenden. Het gemiddelde aantal bytes dat van een server naar client wordt verzonden via een hervatte QUIC-verbinding is 4,4 kB, terwijl het algemene gemiddelde 259 kB is. Bij niet-hervattingen zijn dit respectievelijk 8,1 kB en 583 kB. Dit enorme verschil tussen de twee gemiddelden geeft aan dat een klein deel van de data-intensieve verbindingen het algemene gemiddelde vertekent. Feit is dat slechts 15,5% van alle QUIC-verbindingen meer dan 100 kB transporteert.

De gemiddelde certificaatketen is vandaag de dag (met compressie) 3,2 kB. Dat betekent dat bijna 40% van alle gegevens die van server naar client worden verzonden via meer dan de helft van de niet-hervatte QUIC-verbindingen uitsluitend bestemd zijn voor de certificaten. En dit zal bij post-kwantumalgoritmen alleen maar erger worden. Voor de meeste QUIC-verbindingen zou het gebruik van ML-DSA-44 als directe vervanging voor klassieke handtekeningen het aantal verzonden bytes gedurende de levensduur van de verbinding meer dan verdubbelen.

Het klinkt niet goed als het overgrote deel van de data die via een typische verbinding wordt verzonden alleen bestemd is voor de post-kwantumcertificaten. Het is nog steeds slechts een weergave voor wat werkelijk belangrijk is: het effect op de statistieken die relevant zijn voor de eindgebruiker, zoals de browse-ervaring (bijv. largest contentful paint) en de hoeveelheid data die deze certificaten van de maandelijkse datalimiet van een gebruiker afsnoepen. Wij blijven onderzoek doen om een beter beeld te krijgen van deze impact.

Het traject voor de migratie van het internet naar post-kwantumauthenticatie is veel minder duidelijk dan dat voor key agreement. Tenzij we de prestaties veel dichter bij de huidige authenticatie kunnen brengen, verwachten we dat de overgrote meerderheid van de gebruikers de post-kwantumauthenticatie uitgeschakeld zal houden. Als we het inschakelen van post-kwantumauthenticatie uitstellen totdat Q-day haast is bereikt, bestaat het risico dat we de problemen niet opmerken voordat het te laat is om er een oplossing voor te vinden. Daarom is het essentieel om post-kwantumauthenticatie zo efficiënt te maken dat deze functie standaard ingeschakeld wordt.

We onderzoeken verschillende ideeën om het aantal handtekeningen te verminderen, in toenemende mate van ambitie: het weglaten van tussenliggende handtekeningen, KEMTLS en Merkle Tree-certificaten. Vorig jaar hebben we dit uitgebreid besproken. De meeste vooruitgang is geboekt met het laatste certificaat: Merkle Tree Certificates (MTC). In dit voorstel worden alle handtekeningen, behalve de handshake-handtekening, meestal door een kort Merkle-boombewijs van < 800 bytes vervangen. Dit zou post-kwantumauthenticatie mogelijk kunnen maken die zelfs sneller is dan het gebruik van traditionele certificaten op dit moment! Samen met Chrome gaan we het dit aan het einde van het jaar uitproberen: lees hier meer over in dit blogbericht.

In dit lange blogbericht hebben we het eigenlijk alleen maar gehad over de migratie van TLS. En zelfs TLS hebben we niet volledig behandeld, aangezien we niets hebben gezegd over Encrypted ClientHello (we zijn het niet vergeten). Hoewel TLS belangrijk is, is dat niet het enige protocol dat essentieel is voor de veiligheid van het internet. We willen kort ook enkele andere uitdagingen noemen, maar daar kunnen er nu niet dieper op ingaan. Een specifieke uitdaging is DNSSEC, dat verantwoordelijk is voor het beveiligen van de resolutie van domeinnamen.

Hoewel key agreement en handtekeningen de meestgebruikte cryptografische primitieven zijn, werd de afgelopen jaren meer esoterische cryptografie gebruikt om meer geavanceerde use cases te bedienen. Denk hierbij aan niet-koppelbare tokens met Privacy Pass / PAT, anonieme inloggegevens en op kenmerken gebaseerde versleuteling, om er slechts een paar te noemen. Voor de meeste van deze geavanceerde cryptografische schema's bestaat er nog geen praktisch post-kwantum alternatief. Toch is er tot onze vreugde grote vooruitgang geboekt op het gebied van post-kwantum anonieme inloggegevens.

Samenvattend zijn er twee belangrijke post-kwantummigraties waar we op moeten letten: key agreement en certificaten.

Wij adviseren om over te stappen op post-kwantum key agreement om 'nu oogsten, later ontsleutelen'-aanvallen tegen te gaan. Hiervoor is alleen een software-update aan weerszijden nodig. Dat betekent dat je met de snelle acceptatie (we houden een lijst bij) van X25519MLKEM768 voor software en services mogelijk al tegen dergelijke aanvallen beschermd bent! Op Cloudflare Radar kun je controleren of jouw browser X25519MLKEM768 ondersteunt; als je Firefox gebruikt, is er een uitbreiding om de ondersteuning van websites te controleren waar je naar toe gaat; je kunt hier scannen of jouw website dit ondersteunt; en je kunt Wireshark gebruiken om dit online te controleren.

Dat zijn echter gewoon steekproeven. Voor een correcte migratie moet je uitzoeken waar cryptografie wordt gebruikt. Dat is een hele opgave, omdat de meeste organisaties het sowieso al lastig vinden om alle software, services en externe leveranciers die ze gebruiken, bij te houden. Sommige systemen zijn moeilijk te upgraden of hebben externe afhankelijkheden, maar vaak is het heel eenvoudig. Sterker nog, in veel gevallen zul je na veel tijd en moeite erachter komen dat dit al afgerond is.

Omdat uitzoeken wat er gedaan moet worden het grootste deel van het werk uitmaakt, is het misschien verleidelijk om dat als eerste mijlpaal op te splitsen: maak eerst een gedetailleerde inventarisatie, de zogenaamde cryptografische stuklijst (cryptographic bill of materials of CBOM). De inventarisatie mag echter geen doel op zich worden: we mogen niet vergeten waar we mee bezig zijn. Meestal is de migratie eenvoudig: als je in een bepaald geval weet wat je moet doen, hoef je niet te wachten om van context te wisselen, je kunt het gewoon doen. Dat wil niet zeggen dat het snel zal gaan: het is een marathon en geen sprint, maar eenmaal gestart, is het verrassend hoeveel vooruitgang geboekt kan worden.

Certificaten. Toen ik deze blog in oktober 2025 schreef, waren de definitieve normen voor post-kwantumcertificaten nog niet vastgesteld. Hopelijk duurt het niet te lang voordat dit probleem is opgelost. Maar er is veel wat je nu kunt doen om je op post-kwantumcertificaten voor te bereiden, waar je absoluut geen spijt van zult krijgen. Houd alle software up-to-date. Automatiseer de uitgifte van certificaten. Zorg ervoor dat je meerdere certificaten kunt installeren.

Als je je zorgen maakt over protocol-verstarring, dan is er geen reden om te wachten: de uiteindelijke post-kwantumstandaarden zullen niet veel verschillen van het concept. U kunt dit vandaag nog testen met voorlopige implementaties (of grote dummy-certificaten).

De post-kwantummigratie is vrij uniek. Als de cryptografie gekraakt wordt, gebeurt dat meestal ofwel plotseling ofwel heel geleidelijk, zodat het een tijd lang makkelijk genegeerd kan worden. In beide gevallen worden de migraties uiteindelijk overhaast uitgevoerd. Door de kwantumdreiging weten we zeker dat we veel cryptografie moeten vervangen, maar daar hebben we nu genoeg tijd voor. Beschouw dit niet als een vervelende klus, maar als een kans: we moeten nu onderhoud uitvoeren aan veel systemen die nauwelijks worden gebruikt. In plaats van alleen maar hotfixes uit te voeren, is dit het moment om keuzes uit het verleden opnieuw te overwegen.

Tenminste, als je nu begint. Veel succes met de migratie. Mocht je problemen ondervinden, neem dan contact met ons op: ask-research@cloudflare.com