RFC 9958 voor ingenieurs: een praktische handleiding voor PQC-migratie

Kort antwoord: RFC 9958, "Post-Quantum Cryptography for Engineers", is een informatief IETF-document dat in juni 2026 is gepubliceerd door de PQUIP-werkgroep. Het document legt uit wat er precies misgaat wanneer protocollen overstappen op post-kwantumalgoritmen: sleutels en handtekeningen die 6 tot 700 keer groter zijn dan hun klassieke equivalenten, fragmentatie- en pakketverliesproblemen in protocollen zoals IKEv2, ketenvergroting in PKI en een hybride implementatiemodel dat is ontworpen om de kloof te overbruggen terwijl PQC-algoritmen zich verder ontwikkelen. Deze handleiding vertaalt dit naar een praktisch migratieplan voor engineers.

De meeste PQC-richtlijnen beperken zich tot "gebruik ML-KEM in plaats van ECDH". RFC 9958 is anders. Deze is specifiek geschreven door ingenieurs van Nokia, DigiCert en Entrust omdat het vervangen van algoritmen niet de reden is waarom PQC-migratie moeilijk is. Het gedrag van het protocol bij veel grotere sleutels en handtekeningen maakt het lastig, en dat gedrag komt pas aan het licht wanneer je daadwerkelijk probeert een ML-DSA-87-handtekening van 4,627 bytes in een protocol te passen dat is ontworpen voor ECDSA-handtekeningen van 64 bytes.

Deze handleiding vertaalt de kerninhoud van RFC 9958, de werkelijke omvang, de faalmodi op protocolniveau en het hybride implementatiemodel naar een praktische handleiding voor engineers die daadwerkelijk de migratie uitvoeren.

Key Takeaways

• RFC 9958 is een informatieve RFC van de IETF PQUIP-werkgroep, gepubliceerd in juni 2026, geschreven om de operationele impact van PQC uit te leggen in plaats van de wiskundige aspecten ervan.
• Op roosters gebaseerde sleutels en handtekeningen zijn ongeveer 6 tot 10 keer groter dan klassieke equivalenten voor publieke sleutels, en 10 tot 100 keer groter voor handtekeningen; SLH-DSA-handtekeningen zijn tot 700 keer groter dan ECDSA-handtekeningen.
• Die toename in omvang doorbreekt de aannames die in oudere protocollen waren ingebouwd: IKEv2 had een nieuwe "Intermediate Exchange" (RFC 9242, gebruikt door RFC 9370) nodig, specifiek om PQC-sleuteluitwisselingsberichten te fragmenteren die niet langer in het oorspronkelijke ontwerp pasten.
• Hybride PQ/T-schema's, die een klassiek en een post-kwantumalgoritme combineren, zijn de aanbevolen oplossing: de migratie van de sleuteluitwisseling is grotendeels op zichzelf staand, maar de migratie van de digitale handtekening raakt certificaten, certificeringsinstanties, hardwaremodules en vertrouwensankers in het hele ecosysteem.
• Het hergebruik van sleutels voor hybride en single-algoritme certificaten maakt stripping-aanvallen mogelijk. RFC 9958 stelt expliciet dat hybride sleutels nieuw gegenereerd moeten worden en nooit hergebruikt mogen worden van een bestaande single-algoritme sleutel.

Wat RFC 9958 nu eigenlijk is

RFC 9958, “Post-Quantum Cryptography for Engineers,” is een informatiedocument van de PQUIP-werkgroep (Post-Quantum Use In Protocols) van de IETF, gepubliceerd in juni 2026. Het is geen specificatie die tot standaarden behoort en definieert geen protocol. Het is een referentiedocument, geschreven door auteurs van Nokia, DigiCert en Entrust, bedoeld voor ingenieurs die werken aan cryptografische bibliotheken, netwerkbeveiliging en infrastructuur en die moeten begrijpen wat er verandert wanneer een systeem overstapt op PQC, afgezien van het simpelweg vervangen van de ene algoritme-identificatie door de andere.

Het kernargument van het document is dat de PQC-migratie geen één-op-één vervanging van algoritmen is. Sleuteluitwisseling, die van oudsher werd afgehandeld door algoritmen uit de Diffie-Hellman-familie, en digitale handtekeningen, die van oudsher werden gebruikt door RSA of ECDSA, veranderen beide fundamenteel van vorm onder PQC. Protocollen die zijn gebouwd op basis van de oude structuren vereisen daadwerkelijke technische aanpassingen, en niet slechts een configuratievlag, om de nieuwe structuur te ondersteunen.

De realiteit van de sleutel- en handtekeningafmetingen: een reality check.

Dit is het getal dat de meeste ingenieurs onderschatten totdat ze het in een tabel zien staan.

Algoritme	Publieke sleutel	Cijfertekst / handtekening	Klassiek equivalent
X25519 (klassieke KEM)	32 bytes	32 bytes	-
ML-KEM-768	1,184 bytes	1,088 bytes	~37 keer groter dan X25519
ML-KEM-1024	1,568 bytes	1,568 bytes	~49 keer groter dan X25519
ECDSA-P256 (klassieke signatuur)	64 bytes	64 bytes	-
ML-DSA-65	1,952 bytes	3,309 bytes	~52 keer groter dan ECDSA-P256
ML-DSA-87	2,592 bytes	4,627 bytes	~72 keer groter dan ECDSA-P256
SLH-DSA-SHA2-128s	32 bytes	7,856 bytes	~123 keer groter dan ECDSA-P256
SLH-DSA-SHA2-256f	64 bytes	49,856 bytes	~779 keer groter dan ECDSA-P256

RFC 9958 beschrijft dat op roosters gebaseerde sleutels en handtekeningen ongeveer 6 tot 10 keer zo groot worden voor publieke sleutels en 10 tot 100 keer zo groot voor handtekeningen in vergelijking met klassieke schema's. Dit wordt beschouwd als de beste beschikbare afweging voor algemeen gebruik. SLH-DSA valt echter ver buiten dit bereik, en dat is precies de reden waarom het een noodoplossing is voor beperkt gebruik in plaats van een algemene standaard.

Ontdek hoe HSM-as-a-Service ML-KEM-sleuteluitwisselingspilots ondersteunt zonder dat er een hardware-aankoopcyclus nodig is.

Waarom deze groottes protocollen verstoren: fragmentatie, time-outs, opgeblazen keten

Dergelijke toenames in omvang zijn niet alleen een ongemak voor de bandbreedte. RFC 9958 beschrijft specifieke faalmodi op protocolniveau waarmee engineers rekening moeten houden.

• UDP-fragmentatie in IKEv2: De oorspronkelijke IKE_SA_INIT-uitwisseling kan geen fragmentatie op IKE-niveau gebruiken, waardoor PQC-sleutelmateriaal niet geschikt was. RFC 9242 introduceerde een "tussenliggende uitwisseling" specifiek zodat RFC 9370 PQC-sleuteluitwisseling na de initiële handshake kon uitvoeren, waar fragmentatie wel mogelijk is.
• Pakketverlies en time-outs: Grotere sleuteluitwisselingsberichten beslaan meer netwerkpakketten. In een netwerk met pakketverlies verhoogt dit de totale kans op het verlies van ten minste één pakket tijdens de uitwisseling, wat de handshake-latentie verhoogt en kan leiden tot time-outs bij herverzending die niet voorkwamen bij klassieke sleutelgroottes.
• PKI-ketenoverbelasting: Een certificaatketen van vier certificaten, ondertekend met ML-DSA-87 in plaats van ECDSA, bevat ongeveer 70 keer meer handtekeninggegevens per certificaat. Vermenigvuldig dat met een volledige keten en de TLS-handshakes, OCSP-reacties en certificaatarchieven nemen aanzienlijk toe, met gevolgen voor het gedrag van de middlebox en het geheugen van apparaten met beperkte resources.
• Beperkte apparaten: IoT- en embedded systemen die al geoptimaliseerd waren voor klassieke sleutelformaten, kampen met een langere handshake-latentie, een hoger energieverbruik en de noodzaak voor fragmentatielogica waarvoor veel systemen oorspronkelijk niet ontworpen waren.

Hybride PQ/T-regelingen: de brug, niet de bestemming.

RFC 9958 beveelt hybride post-kwantum- en traditionele (PQ/T) schema's aan als praktische overbrugging tijdens de migratie, omdat noch de klassieke algoritmen, noch de nieuwere PQC-algoritmen op zichzelf volledig betrouwbaar zijn: klassieke algoritmen zullen uiteindelijk bezwijken voor een cryptografisch relevante kwantumcomputer, terwijl PQC-algoritmen nieuwer zijn en minder getest zijn op implementatiefouten en onbekende cryptanalytische zwakheden.

In de huidige standaardisatie komen twee hybride sleuteluitwisselingspatronen voor. Een gecombineerd schema, gebruikt in TLS 1.3 hybride sleuteluitwisseling, combineert de twee gedeelde geheimen door middel van concatenatie voordat ze de sleutelafleidingsfunctie ingaan. Een trapsgewijs schema, gebruikt in RFC 9370 voor IKEv2, past de sleutelafleidingsfunctie één keer per algoritme in volgorde toe. In beide gevallen blijft de resulterende beveiliging behouden zolang ten minste één componentalgoritme veilig blijft, wat precies de bedoeling is van het gelijktijdig uitvoeren van klassieke en post-kwantumalgoritmen in plaats van direct over te schakelen.

Een waarschuwing uit RFC 9958 verdient het om apart genoemd te worden: hybride sleutels moeten volledig nieuw gegenereerd worden en mogen nooit worden gemaakt door een post-kwantumsleutel te combineren met een bestaande klassieke sleutel die al elders in gebruik is. Het hergebruiken van een klassieke sleutel voor zowel een certificaat met één algoritme als een hybride certificaat maakt een stripping-aanval mogelijk, waarbij een aanvaller de post-kwantumhandtekening van ondertekende gegevens verwijdert en de rest presenteert alsof deze alleen met het klassieke algoritme is ondertekend.

Migratievolgorde: Waarom sleuteluitwisseling voorop staat

RFC 9958 maakt een duidelijk operationeel onderscheid tussen de twee migratietrajecten en is de meest bruikbare richtlijn voor de volgorde van migraties in het document.

PQ, ofwel hybride sleuteluitwisseling, is relatief op zichzelf staand en vereist doorgaans alleen aanpassingen aan de cryptografische bibliotheek, zoals OpenSSL, zonder de bredere certificaat- en vertrouwensinfrastructuur aan te tasten. Dat maakt het een geschikt startpunt: het stelt teams in staat om operationele ervaring op te doen met PQC in een productieomgeving met een relatief kleine impact.

De overstap naar post-kwantum of hybride digitale handtekeningen brengt veel bredere veranderingen in het ecosysteem met zich mee : certificaten, certificeringsinstanties, certificaatbeheerprotocollen, HSM's en vertrouwensankers moeten allemaal synchroon migreren. Door vroegtijdig te beginnen met het prototypen en plannen van de handtekeningmigratie, zelfs terwijl de migratie van de sleuteluitwisseling nog gaande is, kunnen teams deze gevolgen voor het hele ecosysteem in kaart brengen voordat ze de productie belemmeren.

Wat we daadwerkelijk zouden aanbevelen

Start nu met pilots voor hybride sleuteluitwisseling, aangezien de wijziging op bibliotheekniveau beperkt is en de operationele leerervaring waardevol is, ongeacht welk protocol u als eerste aanpakt. Begin parallel daaraan met de veel langzamere planning aan de ondertekeningszijde: inventariseer elke certificeringsinstantie, HSM en vertrouwensanker die uiteindelijk bij een handtekeningmigratie betrokken zal zijn. Deze inventarisatie duurt namelijk langer dan de pilot en moet gelijktijdig, niet sequentieel, worden uitgevoerd om te voorkomen dat de ecosysteembrede wijzigingen waar RFC 9958 voor waarschuwt, een onaangename verrassing in een laat stadium worden. Test onder reële netwerkomstandigheden, niet alleen in een labomgeving, aangezien de effecten van fragmentatie en pakketverlies die RFC 9958 beschrijft, zich alleen manifesteren bij realistische latentie en verlies.

Hoe encryptieconsultancy kan helpen

De volgorde van RFC 9958, met eerst hybride sleuteluitwisseling en vervolgens parallelle planning van het ecosysteem aan de ondertekeningszijde, komt overeen met twee verschillende producten. HSM-as-a-Service is waar de pilot voor sleuteluitwisseling met een lage impactradius, die in deze handleiding wordt aanbevolen, daadwerkelijk wordt uitgevoerd: FIPS-gevalideerd ML-KEM-sleutelbeheer zonder dat er een hardware-aankoopcyclus nodig is. CertSecure Manager verzorgt de bredere migratie aan de ondertekeningszijde en orkestreert de uitrol van hybride en pure PQC-certificaten binnen uw CA-hiërarchie vanuit één beleidsvlak, precies de ecosysteembrede coördinatie die RFC 9958 aanmerkt als de moeilijkere helft van de transitie.

Onze PQC-adviesdiensten passen de in deze handleiding beschreven inventarisatie en volgorde toe op beide sporen tegelijk, zodat de hierboven beschreven effecten van fragmentatie, pakketverlies en ketenvergroting worden ingecalculeerd in plaats van halverwege de uitrol te worden ontdekt.

De migratie zelf vormgeven, niet alleen het algoritme.

De werkelijke bijdrage van RFC 9958 is dat het weigert PQC-migratie te behandelen als een algoritme-uitwisseling. Sleutels en handtekeningen die 6 tot 700 keer groter zijn dan waar protocollen voor ontworpen zijn, creëren problemen met fragmentatie, latentie en ketenvergroting die zich alleen voordoen onder reële netwerkomstandigheden. Het hybride PQ/T-model is er specifiek om tijd te winnen terwijl deze problemen worden opgelost in plaats van dat ze in productie worden ontdekt. ​​Eerst de migratie van de sleuteluitwisseling, en vervolgens de planning van het ecosysteem aan de handtekeningzijde, is de volgorde die RFC 9958 zelf aanbeveelt en die nog steeds als praktische richtlijn geldt voor het migratieplan van vrijwel elke organisatie.

Veelgestelde Vragen / FAQ

Is RFC 9958 een standaard die systemen moeten implementeren?

Nee. Het is een informatieve RFC, geen standaardiseringsspecificatie. Het definieert geen protocol en schrijft geen gedrag voor; het legt de technische uitdagingen van PQC-migratie uit en verwijst naar de standaardiserings-RFC's, zoals RFC 9370 en RFC 9180, die wel specifiek protocolgedrag definiëren.

Waarom zijn PQC-sleutels en -signaturen zoveel groter dan die van klassieke sleutels en signaturen?

Ze maken gebruik van andere wiskundige aannames over de moeilijkheidsgraad, zoals roosterproblemen of hashfunctiebeveiliging in plaats van integerfactorisatie of discrete logaritmen op elliptische krommen. Deze problemen vereisen grotere structuren om een ​​vergelijkbaar beveiligingsniveau te bereiken. Het is een inherent compromis van de onderliggende wiskunde, geen inefficiëntie in de implementatie.

Waarom adviseert RFC 9958 om te beginnen met sleuteluitwisseling in plaats van met handtekeningen?

De migratie van de sleuteluitwisseling beperkt zich grotendeels tot een wijziging in de cryptografische bibliotheek, terwijl de migratie van de digitale handtekening betrekking heeft op certificaten, certificeringsinstanties, HSM's en vertrouwensankers in het hele ecosysteem. Door te beginnen met de meer beperkte wijziging kunnen teams operationele ervaring opdoen voordat ze de bredere migratie van de digitale handtekening aanpakken.

Kan een hybride sleutel een bestaande klassieke sleutel hergebruiken?

Nee. RFC 9958 stelt expliciet dat hybride sleutels nieuw gegenereerd moeten worden. Het hergebruiken van een klassieke sleutel die ook voorkomt in een apart certificaat met één algoritme, creëert een risico op een stripping-aanval, waarbij een aanvaller het post-quantum-component verwijdert en de gegevens presenteert alsof ze alleen door het klassieke algoritme zijn gevalideerd.

Wat is de praktische impact van grotere sleutels op IKEv2 VPN-verbindingen?

De oorspronkelijke IKE_SA_INIT-uitwisseling kon geen grote sleuteluitwisselingsberichten fragmenteren, waardoor PQC-sleutelmateriaal niet in het oorspronkelijke ontwerp van het protocol paste. RFC 9242 en RFC 9370 lossen dit op door de PQC-sleuteluitwisseling naar een latere, fragmenteerbare uitwisseling te verplaatsen, maar dit vereiste een aanpassing op protocolniveau, niet alleen een grotere buffer.