Post-Kwantum Cryptografie (PQC) vs Klassieke Cryptografie: Volledige Gids voor Hybride Transformatie 2025
Post-Kwantum Cryptografie (PQC) vs Klassieke Cryptografie — Volledige Gids voor een Hybride Transformatie 2025
Voor: Beveiligings-/Platform-/Datateams, PM's, Architecten, Regelgeving/Compliance │ Gebaseerd op: Jaar 2025
- Introductie: Het Kwantumtijdperk, Wat Verandert Er?
- De Kern van Klassieke Cryptografie (Symmetrisch, Asymmetrisch, Hash)
- Inzicht in de Kwantumdreiging (Shor, Grover, HNDL)
- De Post-Kwantum Cryptografie (PQC) Familie (KEM, Handtekeningen, Belangrijkste Algoritmes)
- PQC vs. Klassieke Cryptografie: Praktische Vergelijking (Prestaties, Sleutelgrootte, Operaties)
- Hybride Transformatie Strategie (TLS, VPN, E-mail, Codesignering)
- Operaties en Governance (Sleutelbeheer, Audit, Crypto Agility)
- Prestatie-/Kostenmodellering (Bandbreedte, Latentie, Apparaatbeperkingen)
- 30-60-90 Dagen Transformatie Roadmap
- Checklist/Beslissingsmatrix
- FAQ
- Conclusie: Co-existentie, Combinatie, Prioriteit aan Operatie
1) Introductie: Het Kwantumtijdperk, Wat Verandert Er?
De inlog, betalingen, messengers en software-updates die we dagelijks gebruiken, zijn afhankelijk van cryptografische technologie. Tot nu toe was **klassieke cryptografie** (RSA, ECC, AES, SHA-2/3) de basis van vertrouwen, maar naarmate **kwantumcomputing** de praktische fase nadert, worden sommige asymmetrische cryptografieën (met name RSA/ECC) structureel bedreigd. Het alternatief is **Post-Kwantum Cryptografie (Post-Quantum Cryptography, PQC)**. De kernvraag is niet “wanneer veranderen?” maar **“wat, op welke manier en veilig transformeren”**.
Kernpunt: Volledige vervanging is niet realistisch; de *hybride* benadering is de praktische oplossing. Er is een strategie nodig om de huidige veiligheid en volwassenheid van klassieke cryptografie te behouden, terwijl PQC parallel wordt ingezet om “toekomstige veiligheid” te garanderen.
2) De Kern van Klassieke Cryptografie
2.1 Symmetrische-sleutelcryptografie (AES, enz.)
- Gebruik: Versleuteling van grote hoeveelheden data. Snel en goed geoptimaliseerd voor hardware.
- Operaties: Sleuteluitwisseling wordt apart opgelost met asymmetrische cryptografie (bijv. RSA/ECDH).
- Kwantuminvloed: Grover's algoritme verzwakt in theorie de veiligheidssterkte met de helft → Dit kan worden opgevangen door de sleutellengte te vergroten (bijv. AES-256).
2.2 Asymmetrische-sleutelcryptografie (RSA/ECC)
- Gebruik: Fundament van sleuteluitwisseling, digitale handtekeningen en certificaatinfrastructuur (PKI).
- Sterke punten: Decennialange validatie, brede implementatie en interoperabiliteit.
- Kwantuminvloed: Kan in principe worden gekraakt door Shor's algoritme (uitgaande van een voldoende grote kwantumcomputer).
2.3 Hash/Handtekening (Hash-schema's, HMAC, RSA/ECDSA/EdDSA)
- Hash is gebaseerd op integriteit en handtekening. De **hash zelf** is relatief robuust tegen kwantumaanvallen, maar vereist een grotere lengte.
- Handtekening is essentieel voor certificaten/codesignering en digitale documenten. In het kwantumtijdperk is de overgang naar **PQC-handtekeningen** belangrijk.
3) Inzicht in de Kwantumdreiging
3.1 Shor's Algoritme
Een kwantumalgoritme dat efficiënt de priemfactorisatie van gehele getallen en de discrete logaritme kan oplossen. Kan de fundamentele aanname van computationele moeilijkheid van RSA en ECC ondermijnen. Dit vereist een "voldoende grote, foutcorrigerende" kwantumcomputer.
3.2 Grover's Algoritme
Versnelt zoeken (op vierkantswortelniveau). Modellen laten zien dat het de *effectieve veiligheidssterkte* van symmetrische sleutels/hashes met ongeveer de helft vermindert. De tegenmaatregel is relatief eenvoudig: **de sleutellengte vergroten** (bijv. AES-256, SHA-384/512).
3.3 "Harvest-Now, Decrypt-Later (HNDL)" Risico
Een aanvalsscenario waarbij verkeer nu wordt opgeslagen en in de toekomst wordt ontsleuteld met een kwantumcomputer. Dit is bijzonder dodelijk voor langetermijngeheimen (overheid, medische gegevens, R&D, volgende generatie standaarden, klantgegevens, enz.). De **kosten van het uitstellen van de transformatie** zijn mogelijk niet zichtbaar, maar het werkelijke risico bouwt zich op.
Kernpunt: Als de *bewaarperiode* van de gegevens die nu geheim moeten zijn, langer is dan het punt van kwantumtransformatie, is het rationeel om ze **onmiddellijk** te beschermen met PQC (of een hybride aanpak).
4) De Post-Kwantum Cryptografie (PQC) Familie
PQC is gebaseerd op wiskundige problemen die structureel sterk zijn tegen kwantumaanvallen. De belangrijkste categorieën zijn:
4.1 Gebaseerd op Rooster (Lattice-based)
- KEM (Key Encapsulation Mechanism): Bijv. Kyber-familie — Kandidaat voor de vervanging van TLS-sleuteluitwisseling.
- Handtekening: Bijv. Dilithium-familie — Kandidaat voor de vervanging van codesignering/documenthandtekeningen.
- Kenmerken: Redelijk snel, maar de grootte van sleutels/handtekeningen kan groter zijn dan bij klassieke cryptografie.
4.2 Handtekeningen Gebaseerd op Hash
- Bijv. SPHINCS+-familie — Een conservatieve en theoretisch eenvoudige benadering.
- Kenmerken: Grote afweging tussen handtekening-/verificatiesnelheid en -grootte. Wordt beschouwd als een gunstige optie voor langetermijnverificatie.
4.3 Gebaseerd op Code
- Bijv. Classic McEliece-familie — Het nadeel is de zeer grote openbare sleutel, maar het heeft een traditie van klassieke veiligheid.
4.4 Overige (Multivariaat, Isogenie, enz.)
- Van sommige van deze families zijn al kwetsbaarheden gevonden, waardoor ze niet langer tot de belangrijkste kandidaten behoren.
In de praktijk moet je zowel de **voortgang van de standaardisatie** (bijv. KEM-/handtekeningkandidaten) als de **volwassenheid van de bibliotheken** (taal-/platformpoort, hardwareversnelling, mitigatie van side-channel aanvallen) in de gaten houden.
5) PQC vs. Klassieke Cryptografie — Praktische Vergelijking
| Item | Klassieke Cryptografie | Post-Kwantum Cryptografie (PQC) |
|---|---|---|
| Veiligheidsaanname | Priemfactorisatie/discrete logaritme (asymmetrisch), sterke blok/hash (symmetrisch) | Gebaseerd op roosters, codes, hashes, enz., kwantum-robuuste aannames |
| Kwantuminvloed | RSA/ECC kwetsbaar voor Shor, AES kan worden afgezwakt door sleutellengte te vergroten | Ontwerp is kwantum-resistent (let op ontwerpkwetsbaarheden) |
| Sleutel-/handtekeninggrootte | Klein (vooral ECC) | Over het algemeen groot (invloed op bandbreedte/opslag) |
| Prestaties | Volwassen en uitstekend geoptimaliseerd | Kan snel zijn, afhankelijk van het algoritme, of verificatie kan zwaar zijn |
| Ecosysteem/Compatibiliteit | Breed (standaarden/hardware/tools) | Snel groeiend (standaarden/bibliotheken in ontwikkeling) |
| Operationeel risico | Volwassen, maar side-channel/implementatiebugs blijven bestaan | Gevoelig voor nieuwe kwetsbaarheden/side-channels, *crypto-agility* is essentieel |
Conclusie: Op korte termijn is de *hybride* benadering het veiligst. Hiermee combineer je de brede compatibiliteit van klassieke cryptografie met de toekomstige veiligheid van PQC.
6) Hybride Transformatie Strategie (Gids per Protocol)
6.1 TLS (HTTPS/QUIC)
- Hybride KEM: Gelijktijdige sleuteluitwisseling met klassieke (ECDH/X25519, enz.) + PQC (Kyber-familie) algoritmes.
- Onderhandelen wanneer zowel client als server dit ondersteunen. Gefaseerde uitrol (canary → uitbreiding).
- Voor certificaten, overweeg een **hybride handtekening** (bijv. ECDSA + Dilithium) of een dubbele keten.
6.2 E-mail (S/MIME·PGP)
- Pas **PQC-handtekeningen** prioritair toe op documenten/e-mails voor langetermijnbewaring.
- De vorm van een *dubbele handtekening* is realistisch voor interoperabiliteit.
6.3 VPN/IPsec/SSH
- Combineer PQC KEM in de sleuteluitwisselingsfase. Start een proefimplementatie in de grensgebieden.
- Update firmware/bibliotheken in lijn met de vervangingscyclus van de apparatuur.
6.4 Codesignering/Software-updates
- **Verdubbel het handtekeningalgoritme** om de langetermijnverificatiemogelijkheid te waarborgen.
- Ontwerp versies en beleid om conflicten met de legacy bootchain te voorkomen.
6.5 Dataversleuteling (Opslag/Verzending)
- Voor symmetrische versleuteling, houd je aan sterke parameters zoals AES-256.
- Garandeer kwantumveiligheid in het sleutelbeheer-/uitwisselingsgebied via een hybride aanpak.
Kern: Behoud de **KEM-DEM** (Key Encapsulation + Symmetrische Versleuteling) structuur, maar *verander de KEM in een hybride*, om de impact te minimaliseren.
7) Operaties en Governance — Bouw "Crypto-Agility"
7.1 Levensduur en Vervangingsbeleid van Sleutels
- Gebruik klassieke handtekeningen/sleuteluitwisselingen met een *verkorte levensduur*; verleng deze geleidelijk wanneer PQC parallel wordt toegepast.
- Versnel de implementatie van PQC-handtekeningen voor logs/documenten die langetermijnverificatie vereisen.
7.2 Side-Channel/Implementatieveiligheid
- Vanwege de sleutel-/handtekeninggrootte en de operationele patronen van PQC, let op de risico's van lekken op basis van **timing, cache en stroomverbruik**.
- Gebruik constante tijdimplementaties, maskeren, kwaliteitsverificatie van willekeurige getallen en hardware security modules (HSM/TPM/TEE).
7.3 Audit/Traceerbaarheid
- Leg de **wijzigingsgeschiedenis** van algoritmes, sleutellengtes, versies en beleid vast.
- Log de succes-/faalpercentages van de hybride benadering en de onderhandelingsresultaten (handshake).
7.4 Beheer van Regelgeving/Standaarden en Leveranciers
- Monitor de voortgang van standaarden en reflecteer de beloften van leveranciers in **SLA's/contracten**.
- Elimineer vroege compatibiliteitsrisico's met interoperabiliteitstesten.
8) Prestatie-/Kostenmodellering
8.1 Sleutel-/Handtekeninggrootte → Bandbreedte-/Opslagkosten
- De grootte van de openbare sleutel, handtekening en encapsulatie in PQC kan toenemen, wat de groottebelasting van de *handshake* en de *certificaatketen* verhoogt.
- Dit kan worden verzacht met CDN/edge-cache, compressie en vereenvoudiging van de keten.
8.2 Operationele Latentie
- De KEM-/handtekeningverificatie kan een knelpunt worden op servers. **Profileer** om hotspots te identificeren.
- Compenseer met threadpools, asynchrone handshakes, lichte parameters en hardwareversnelling.
8.3 Edge/Mobiel/Embedded
- Houd rekening met geheugen-/flashbeperkingen en de grootte van de firmware-OTA.
- In omgevingen met een laag stroomverbruik zijn de kosten van handtekeningverificatie gevoelig — wees voorzichtig bij de selectie van parameters.
9) 30-60-90 Dagen Transformatie Roadmap
Eerste 30 Dagen (Diagnose/Voorbereiding)
- **Assetinventarisatie**: Lijst van cryptografiegebruikspunten (TLS, VPN, e-mail, codesignering, opslagversleuteling...).
- **Dataclassificatie**: Langetermijngeheimen/kortetermijngeheimen/openbaar. Beoordeling van het HNDL-risico.
- **Conceptbeleid**: Hybride principes, sleutelleven, audit-items, fallback-regels bij storing.
- **PoC**: Experimenteer met hybride TLS KEM (canary) en verdubbeling van handtekeningen.
60 Dagen (Uitbreiding/Standaardisatie)
- Verbreed het toepassingsgebied van de hybride aanpak naar VPN/e-mail/codesignering.
- Monitoring-dashboard: Handshake-succespercentage, latentie, trend in sleutel-/handtekeninggrootte.
- Interoperabiliteitstesten met leveranciers/partners, opzetten van een CISO-rapportagesysteem.
90 Dagen (Operationalisatie)
- Implementeer het **crypto-agility** framework in de gehele productie (vlaggen/beleidslading/nood-rollback).
- Driemaandelijkse risicobeoordeling: Standaardveranderingen, kwetsbaarheidsissues, kosten-/prestatietrends.
- Distributie van trainingen/gidsen: Onboarding van de hele organisatie (ontwikkeling, operaties, beveiliging, juridisch).
10) Checklist/Beslissingsmatrix
| Vraag | Ja/Nee | Aanbevolen Actie |
|---|---|---|
| Heeft u langetermijngeheimen (bewaring van 5-10 jaar of meer)? | Ja | Implementeer hybride onmiddellijk (HNDL-preventie) |
| Is de TLS-handshake een prestatieknelpunt? | Ja | Vereenvoudig KEM-parameters/keten, versnelling |
| Is langetermijnverificatie van handtekeningen vereist? | Ja | Verdubbel PQC-handtekeningen, versterk het bewaarbeleid |
| Is er een groot aantal edge-/mobiele apparaten? | Ja | Optimaliseer firmwaregrootte en verificatiekosten |
| Is de afhankelijkheid van leveranciers/partners groot? | Ja | Interoperabiliteitstesten en opname van clausules in SLA |
| Heeft u een crypto-agility framework? | Nee | Bouw een systeem voor hot-swap/versiebeheer en rollback van beleid |
Tip: Beschouw “Hybride Prioriteit” als het standaard operationele model en hergebruik het als een gemeenschappelijke module in de hele organisatie.
11) FAQ
Q1. Is het nodig om alles nu onmiddellijk naar PQC te veranderen?
Nee. De realistische weg is **hybride**. U combineert de volwassenheid van klassieke cryptografie met de toekomstige veiligheid van PQC, en breidt geleidelijk uit naarmate de standaarden/ecosystemen volwassener worden.
Q2. Is symmetrische cryptografie (AES) veilig?
Er is invloed van Grover, maar dit kan worden opgevangen door de sleutellengte te vergroten. Gebruik AES-256 en sterke hashes (SHA-384/512, enz.).
Q3. Waar moet ik mee beginnen?
Begin met langetermijngeheime datapad- en authenticatie-/handtekeningschema's. De implementatie van hybride TLS KEM en handtekeningverdubbeling heeft een grote impact.
Q4. Ik maak me zorgen over de prestaties.
Dit kan worden gecompenseerd door handshake-optimalisatie, parameterselectie, cache/versnelling. De toename van de bandbreedte kan worden verzacht door ketenvereenvoudiging en compressie.
Q5. Side-channels zouden gevaarlijker zijn?
Dat klopt. Kies standaard voor constante tijdimplementaties, willekeurige getalkwaliteit en hardwarebeveiliging. Volg de beveiligingsrichtlijnen van de standaardbibliotheken.
12) Conclusie: Co-existentie, Combinatie, Prioriteit aan Operatie
- Wat nu nodig is, is geen angst, maar een *systematische transformatie*.
- Combineer de stabiliteit van klassieke cryptografie met de toekomstige veiligheid van PQC in een **hybride** aanpak.
- Door de inventarisatie → hybride PoC → crypto-agility-opbouw te doorlopen, kun je de HNDL-risico's realistisch verminderen.
Onmiddellijk toepassen: Start deze week een TLS KEM hybride canary en een PoC voor codesignering. Volgende week kun je het bereik uitbreiden met een pilot voor e-mail-/documenthandtekeningen.
