Bugs gebeuren: De eenvoudige manier om solo PQ te vergelijken met ECC+PQ

De eenvoudigste manier om in te zien dat solo PQ een onvergeeflijke beveiligingsramp zal zijn, is als volgt:

• PQ-software zal vaak gebreken vertonen.
• Sommige van deze gebreken zullen exploiteerbaar zijn.
• Het behouden van ECC als onderdeel van ECC+PQ, in plaats van het gebruik van solo PQ, vermindert de schade die door deze kwetsbaarheden wordt aangericht.
• De kosten van ECC zijn gemakkelijk draagbaar in vergelijking met de kosten van PQ, dus er is geen reden om ECC weg te gooien.

Context en eerdere waarschuwingen

Ik heb dit standpunt consistent verdedigd:

• In een presentatie uit 2016 raadde ik ECC+PQ aan.
• In 2018 beschreef ik de post-quantum wedstrijd van het NIST als "de grootste regressie in de kwaliteit van cryptografische software ooit" en stelde ik dat dit "niet gemakkelijk te herstellen zal zijn".
• In 2024 schreef ik dat "bugs in post-quantum software" reden zijn voor "een algemene regel om altijd te upgraden van ECC naar PQ+ECC, in plaats van de ECC-laag weg te gooien".
• Begin juni 2026 publiceerde ik een paper waarin standaardtechnieken worden gebruikt om het aantal ML-DSA-sleutels te schatten dat breekbaar zal zijn door de voorspelbare instroom van softwarebugs. (Voor ML-KEM zal dit aantal veel hoger liggen, omdat er veel meer KEM-sleutels worden gebruikt dan handtekeningsleutels).

Daarnaast bestaat het risico dat een kwetsbaarheid in een PQ-specificatie nog meer schade aanricht door alle software voor die specificatie te beïnvloeden. Sommigen gebruiken pseudowetenschap en valse claims over stabiliteit om te beweren dat de specificaties voor ML-KEM en ML-DSA niet riskant zijn.

Het voordeel van het focussen op software is dat beveiligingsexperts vaak ook software-experts zijn. Dit maakt het argument voor softwarekwaliteit zeer uitdagend voor voorstanders van solo PQ. In dit artikel loop ik stap voor stap door de zwaktes van de argumenten voor solo PQ.

---

1. Het argument dat er geen softwarefouten zullen zijn

Dit argument is onhoudbaar. Er zijn al honderden kwetsbaarheden in cryptografische bibliotheken gevonden. Software voor Dilithium (ML-DSA) en Kyber (ML-KEM) heeft al diverse bugs en timing-leaks vertoond, waaronder:

• Een bug in de oorspronkelijke officiële Dilithium-implementatie in 2017.
• Twee timing-leaks, KyberSlash1 en KyberSlash2, in elke officiële referentie-implementatie van Kyber van 2017 tot eind 2023. De meeste Kyber/ML-KEM-implementaties hebben hier patches voor uitgebracht.

In 2026 zijn er CVE's of andere bugs gemeld voor ML-DSA-code in de volgende bibliotheken:

• libcrux
• libgcrypt
• RustCrypto
• wolfSSL

Opvallend genoeg werd op 24 juni 2026 door voorstanders van het verwijderen van ECC uit ECC+PQ een nieuwe stemming aangevraagd; de volgende dag volgde de aankondiging van CVE-2026-6330, een ML-KEM softwarebug in WolfSSL.

Ik gebruik SUPERCOP om cryptografische implementaties te testen. Momenteel worden 5036 implementaties van honderden verschillende mensen continu getest. De fouten die deze tests vinden, zijn vergelijkbaar met de fouten in ML-KEM en ML-DSA software.

Een typische cryptografische bibliotheek heeft nieuwe implementaties van ML-KEM en ML-DSA die niet door SUPERCOP worden gedekt en tests die veel minder strikt zijn. Mijn paper uit juni 2026 over ML-DSA-bugs benadrukt dat, hoewel de technologie om randomness-expansie in software te testen al voor 2017 beschikbaar was, deze nog steeds verre van universeel wordt toegepast.

Sommige bugs zijn bovendien moeilijker te vangen, zoals aangetoond in een paper uit mei 2026 over ML-DSA-bugs die "standaard testen overleven". Formele verificatie kan in theorie alle bugs vangen, maar een paper over specifieke ML-KEM-software meldt dat de verificatie — ondanks shortcuts in de AVX2-implementatie — bijna drie jaar werk kostte van een groot aantal mensen. Typische ML-KEM-software is dus niet geverifieerd.

2. Het argument dat softwarefouten niet exploiteerbaar zullen zijn

Hoewel niet elke bug exploiteerbaar is, zijn er vaak wel degelijk ernstige kwetsbaarheden. In cryptografische bibliotheken is ongeveer 1 op de 8 cryptografische kwetsbaarheden ernstig. Zelfs met decennia aan ervaring met ECC-software zien we nog steeds exploiteerbare fouten, zoals CVE-2023-6135 in Firefox.

ML-KEM en ML-DSA zijn veel nieuwer. De KyberSlash-fout werd in december 2023 ontdekt. Hoewel de oorspronkelijke Kyber-paper uit 2017 claimde dat de software in "constant time" draaide (bescherming tegen timing-attacks), toonde KyberSlash aan dat dit niet zo was. Binnen een maand volgde een exploit-demo. Later werd ook KyberSlash2 ontdekt.

In 2024 werd Clangover aangekondigd, een timing-leak veroorzaakt door de interactie tussen Kyber/ML-KEM-code en nieuw compilergedrag, die eveneens exploiteerbaar bleek. Sommige bedrijven claimden dat ze veilig waren omdat ze hun sleutels sneller wisselen dan de demo's werken, maar dit is een ongeverifieerde claim.

Statistisch gezien hebben cryptografische bibliotheken ongeveer 1 CVE per 1000 regels code. Met 1 op de 8 ernstig, betekent dit ongeveer 1 ernstige kwetsbaarheid per 8000 regels code. Een enkele ML-KEM-implementatie overschrijdt vaak de 1000 regels. Gezien het grote aantal TLS-bibliotheken is het onvermijdelijk dat sommige hiervan exploiteerbaar zullen zijn.

3. Wat voorstanders van solo PQ zeggen over softwarekwetsbaarheden

Voorstanders van solo ML-KEM en ML-DSA beweren zelden dat er geen fouten zullen zijn; in plaats daarvan wijzen ze op gevallen waarin het wél goed ging (bijv. "deze bibliotheek had deze fout niet" of "deze bug was niet exploiteerbaar").

Het argument voor ECC+PQ is echter niet dat PQ-software altijd exploiteerbaar is, maar dat het vaak gebreken zal hebben. Wanneer slachtoffers later verantwoording eisen, is het onhoudbaar om te zeggen: "Het is niet onze schuld dat we de veiligheidsgordels hebben verwijderd; het is jullie schuld dat je in een auto zat die crashte."

Enkele specifieke claims:

• Filippo Valsorda (april 2026): Beweerde dat ML-KEM en ML-DSA veel gemakkelijker veilig te implementeren zijn dan klassieke alternatieven en dat hij "extreem weinig bugs" verwacht. Hij ontweek herhaalde vragen over wat "extreem weinig" precies betekent.
• Sophie Schmieg (november 2025) & Mark Schultz-Wu (juli 2026): Beweerden zonder bewijs dat lattice-based schemes eenvoudiger te implementeren zijn dan RSA/ECC.

De werkelijke codegrootte in bibliotheken spreekt dit tegen. Bovendien heeft ECC-code veel meer tijd gehad om fouten te laten vinden en oplossen. Elke bug heeft ongeveer 20% kans per jaar om ontdekt te worden. ECC-code is volwassen, terwijl ML-KEM/ML-DSA-code nog in de kinderschoenen staat.

Zelfs als we aannemen dat de ECC-laag vaker exploiteerbaar zou zijn dan ML-KEM (wat onwaarschijnlijk is), zou het behoud van ECC nog steeds zin hebben voor alle gebruikers van de exploiteerbare ML-KEM-bibliotheken.

4. Het argument dat ECC nutteloos is omdat quantumcomputers komen

Uri Blumenthal stelde dat als data gevoelig blijft tot de komst van een CRQC (Cryptographically Relevant Quantum Computer), ECC "helemaal niet helpt".

Dit is een ontkenning van de waarde van het vertragen van aanvallen. Gebruikers (zoals artsen, patiënten en journalisten) willen dat data zo lang mogelijk vertrouwelijk blijft. Elke extra jaar confidentiality voegt waarde toe. Het verzwakken van ECC+PQ naar solo PQ gooit dit voordeel weg.

Bovendien gaat de aanname dat alle ECC-sleutels onmiddellijk gebroken zijn zodra een CRQC arriveert, voorbij aan de feiten:

1. Vertraging: ECC vertraagt aanvallen tot aan de komst van quantumcomputers.
2. Kosten: Het beperkt aanvallen tot aanvallers die een quantumcomputer kunnen betalen (geschat op minimaal $1 miljard).
3. Schaal: Het beperkt het aantal gebroken sleutels vanwege de kosten per sleutel bij quantum-aanvallen.

Een paper uit maart 2026 schat dat een realistisch model van zo'n computer ongeveer 215 ECC-sleutels per jaar kan breken. Ter vergelijking: TLS gebruikte twee jaar geleden al meer dan 250 ECC-sleutels per jaar. Solo PQ zal simpelweg leiden tot veel meer gebroken sleutels dan ECC+PQ.

5. Het argument dat ECC+PQ de beveiliging schaadt vergeleken met solo PQ

Het basisprincipe is dat ECC+PQ veiliger is: een aanvaller moet beide (ECC en PQ) smeden om een bericht te vervalsen of te ontsleutelen.

Sommigen beweren dat de complexiteit van ECC+PQ de implementatie vertraagt. Valsorda en John Mattsson suggereerden dat dit de migratie naar PQC zou vertragen, waardoor deadlines van 2030 gemist zouden worden.

De praktijk spreekt dit tegen. Cloudflare rapporteerde in september 2025 dat ongeveer 95% van hun post-quantum HTTPS-verbindingen al hybride (X25519MLKEM768) waren. De implementatie was simpel: men koos het meest gebruikte ECC-systeem (X25519) en combineerde dit via eenvoudige concatenatie met de PQ-output.

De IETF-goedgekeurde specificatie voor ECC+ML-KEM in TLS bevat slechts drie opties:

• X25519MLKEM768
• SecP256r1MLKEM768
• SecP384r1MLKEM1024

Dit vereist slechts enkele regels "glue code" bovenop bestaande software. Het is onlogisch om te beweren dat we deze mitigatie moeten overslaan vanwege het theoretische risico op bugs in een paar regels code, terwijl we daarmee het risico accepteren van bugs in de vele honderden regels ML-KEM-code.

6. Het argument dat ECC onbetaalbaar is

De kosten van ECC zijn verwaarloosbaar vergeleken met PQ.

• ML-KEM-512: Sleutels van 800 bytes, ciphertexts van 768 bytes.
• X25519: Voegt slechts 32 bytes per onderdeel toe.

De totale kosten van X25519 (rekenkracht en communicatie) zijn minimaal vergeleken met de communicatiekosten van ML-KEM-512.

Paul Wouters claimde in februari 2026 dat in de wereld van "high-frequency trading" de prestatiebeperking van ECC+PQ een reden zou zijn om te wachten tot een CRQC publiekelijk bekend is. Echter, de kosten van ECC+PQ om een sessie op te zetten voordat de handelsdag begint, hebben nul effect op de latency tijdens het handelen zelf. Wouters heeft deze claim nooit verdedigd of ingetrokken.

Samenvatting

• ML-KEM-software zal vaak gebreken vertonen, waarvan sommige exploiteerbaar zijn. Het behouden van ECC in ECC+ML-KEM vermindert de schade van deze kwetsbaarheden.
• ML-DSA-software zal evenzo vaak gebreken vertonen. Het behouden van ECC in ECC+ML-DSA vermindert de schade.
• De kosten van ECC zijn in beide gevallen gemakkelijk draagbaar vergeleken met de kosten van de PQ-componenten.

Er is geen legitieme reden om de ECC-laag weg te gooien.