Niet elke post-quantumstandaard is klaar voor gebruik

Niet elke post-quantumstandaard is klaar voor gebruik

·5 min leestijdBeveiliging en Privacy

Sinds Google zijn schatting voor Q-Day van 2035 naar 2029 heeft vervroegd, klinkt post-quantumcryptografie een stuk minder als iets voor later. Volgens een bericht van CyberScoop over de aangepaste planning van Google is het vooral een kwestie van timing geworden. Wie bankgegevens, medische dossiers of privécommunicatie nog vooral beschermt met RSA of ECC, heeft minder uitstelruimte dan veel securityteams dachten.

Daar komt nog iets bij. Het risico begint niet pas op de dag dat een bruikbare quantumcomputer echt bestaat. De strategie “nu verzamelen, later ontsleutelen” is al logisch genoeg om rekening mee te houden. Versleuteld verkeer dat vandaag wordt buitgemaakt, kan later alsnog waardevol blijken. In een wereld waarin 67 procent van de datalekken begint met een gestolen login, is de houdbaarheid van geheimhouding ineens een praktische bestuursvraag.

Niet elke standaard is even ver

NIST heeft in augustus 2024 drie belangrijke post-quantumstandaarden afgerond en werkt tegelijk verder aan aanvullende opties, zoals blijkt uit het officiële post-quantumprogramma van NIST. Dat klinkt overzichtelijk, maar in de praktijk zitten die algoritmes niet in dezelfde fase. Sommige zijn bijna klaar voor breed gebruik, andere zijn vooral nuttig als vangnet en één optie is eigenlijk al afgevallen.

Dat verschil is belangrijk, omdat cryptografie niet alleen draait om mooie wiskunde. Je moet ook kijken naar sleutelgroottes, snelheid, energieverbruik, implementatierisico en de vraag of je het in bestaande infrastructuur krijgt zonder nieuwe problemen te maken. Anders gezegd: de beste keuze is meestal de keuze die veilig én uitvoerbaar is.

Eén kandidaat kun je nu al wegstrepen

BIKE staat onderaan. Het algoritme verloor de NIST-competitie en miste ook de reserveplek van de vierde ronde, die naar HQC ging. Op papier had BIKE voordelen bij geheugengebruik, maar bij hogere beveiligingsniveaus werden latency en energieverbruik een te groot nadeel.

Dat maakt de praktische conclusie vrij simpel. Er komt geen FIPS-standaard voor BIKE. Als een leverancier toch BIKE-ondersteuning opvoert als pluspunt, is dat eerder een waarschuwing dan een geruststelling. In security wil je meestal niet inzetten op iets dat al buiten de hoofdroute is gevallen.

HQC is een reserveband, geen standaardkeuze

HQC heeft een andere rol. Het is gekozen als codegebaseerd alternatief naast de roosteralgoritmes. Dat is op zichzelf verstandig. Mocht er ooit twijfel ontstaan over die roosterwiskunde, dan is er in elk geval nog een andere cryptografische basis achter de hand.

Alleen werkt een reserveoplossing niet automatisch goed in het dagelijks verkeer. HQC vraagt veel geheugen en legt extra druk op beperkte hardware. Voor servers is dat nog te managen. Voor mobiele apparaten, sensoren en andere krappe omgevingen blijft het lastig. Daarmee is HQC vooral een verzekering voor een scenario dat je liever nooit nodig hebt.

Bij handtekeningen gaat het om lastige afruilen

Bij digitale handtekeningen zie je de verschillen misschien nog het duidelijkst. SLH-DSA, afgeleid van SPHINCS+, leunt volledig op hashfuncties. Dat maakt het aantrekkelijk voor situaties waarin verificatie heel lang houdbaar moet blijven, zoals archieven, juridische documenten of logbestanden van kritieke infrastructuur.

Het nadeel is behoorlijk concreet. De handtekeningen zijn groter dan 7.800 bytes, tegenover ongeveer 3.300 bytes voor ML-DSA, en het ondertekenen gaat merkbaar trager. Voor TLS of andere latencygevoelige processen is dat gewoon onhandig.

FN-DSA, afgeleid van FALCON, kiest de andere kant: compacte sleutels en handtekeningen. Dat is interessant voor certificaatketens, IoT-netwerken en omgevingen waar bandbreedte schaars is. Die compactheid sluit ook aan bij de beweging van wachtwoorden naar passkeys. Alleen is de implementatie lastig, omdat sleutelgeneratie constante floating-pointrekenkunde vereist. Precies daar liggen bekende risico’s voor side-channellekken.

Wat je nu wel serieus kunt uitrollen

Voor organisaties die moeten prioriteren, is het beeld inmiddels vrij helder. ML-DSA, gebaseerd op CRYSTALS-Dilithium, is de werkpaardoptie voor code signing, documentverificatie en authenticatie. De prestatieanalyse van PQC in TLS op arXiv laat zien dat ondertekenen veel sneller kan dan met RSA-2048, terwijl de praktische overhead beperkt blijft.

Bovenaan staat ML-KEM, afgeleid van CRYSTALS-Kyber. Dat komt niet alleen door de theorie, maar vooral door adoptie. Google heeft het in Chrome aangezet en Cloudflare meldt dat 65 procent van het menselijke verkeer op zijn netwerk al post-quantum sleutelinkapseling gebruikt. Als NIST vervolgens zegt dat de sector dit “onmiddellijk” moet integreren, dan is dat ongeveer zo duidelijk als standaarden ooit worden.

Wachten is inmiddels ook een keuze met risico

Voor de meeste toepassingen ligt de route daarom redelijk vast. ML-KEM voor sleuteluitwisseling. ML-DSA voor de meeste handtekeningen. SLH-DSA als langetermijnverzekering. FN-DSA om goed in de gaten te houden, maar nog niet om overhaast uit te rollen. BIKE kun je intussen vooral als een afgesloten hoofdstuk zien.

NIST verwacht bovendien dat quantumkwetsbare algoritmes tegen 2035 worden uitgefaseerd, terwijl gevoelige systemen eerder moeten overstappen. Tel daar de snelheid bij op waarmee AI-gestuurde aanvallen gestolen data sneller bruikbaar maken, en de comfortabele migratieperiode is eigenlijk voorbij. De quantumcomputer die je versleuteling ooit kan breken, hoeft er vandaag nog niet te zijn. Voor je risicoplan is dat verschil steeds minder relevant.

Bronnen en Referenties

  1. NIST Computer Security Resource Center
  2. CyberScoop / Google
  3. Cloudflare
  4. arXiv (Performance Analysis of PQC in TLS)

Lees over onze redactionele standaarden

Misschien vind je dit ook leuk: