7 post-kvantealgoritmer du bør kende i 2025

Forestil dig, at din krypterede e-mail bliver opsnappet i dag, lagt på is i et datacenter - og knækket som nødder, så snart den første praktisk anvendelige kvantecomputer tænder i morgen. Det lyder som science fiction, men harvest-now-decrypt-later-strategien er allerede virkelighed for avancerede trusselsaktører. 2025 markerer året, hvor regulatorer, leverandører og sikkerhedschefer forventer konkrete svar: Hvad gør I for at være kvanteklar?

På IT Forum Danmark har vi fulgt NIST-kapløbet fra første heat, set IETF skrue på hybride TLS-profiler og hørt CISO’er kæmpe med spørgsmålet: KEM, lattice eller kode - hvad skal vi vælge? Nu er tiden kommet til at skifte fra slides til source code. Derfor guider vi dig igennem «7 post-kvantealgoritmer du bør kende i 2025» - de algoritmer, som sandsynligvis ender i dine VPN-bokse, din PKI og dine firmware-signaturer, før kalenderen rammer 2026.

Artiklen giver dig:

• Den korte version af hvorfor 2025 er et skæringspunkt - fra NIST’s nye FIPS-standarder til EU’s kommende regulativer.
• En praktisk sammenligning af de syv nøglekandidater: ML-KEM, ML-DSA, SLH-DSA, Falcon, Classic McEliece, BIKE og HQC.
• En hands-on plan for at gå fra proof-of-concept til produktionssikker post-kvantekryptografi - uden at knække MTU-grænser eller complianceskemaer.

Spænd sikkerhedsbæltet, hent kaffekoppen, og lad os tage den kvante-tur, der kan redde dine data de næste 30 år.

Hvorfor post-kvantealgoritmer i 2025? Trussel, tidslinje og standarder

Trusselsbilledet er ikke længere akademisk, men en forretningskritisk realitet: statslige aktører og cyberkriminelle høster krypteret trafik i dag (“harvest-now, decrypt-later”) med henblik på at dekryptere, så snart praktiske kvantecomputere er tilgængelige. Selv om eksperter estimerer 7-15 år før en “store-enough” kvantecomputer, ligger mange datas livscyklus - fra personfølsomme journaler til IP-aftaler - langt ud over 2030. Derfor er 2025 blevet det år, hvor bestyrelser kræver strategisk risikostyring og roadmaps til post-kvantekryptografi (PQC).

Lovgivningen skubber på: EU’s NIS2 og DORA kræver dokumenteret krypteringshygiejne og crypto-agility; i USA pålægger OMB M-23-02 alle føderale instanser at have PQC-migrationsplaner klar i 2025. Det betyder, at arkitekter skal kunne udskifte algoritmer uden at ændre protokoller eller forretningslogik. Begreberne KEM (Key Encapsulation Mechanism til nøgleudveksling) og digitale signaturer bliver centrale byggesten, mens hybridisering (klassisk + PQC i samme håndtryk) giver en sikker bro til fremtiden.

NIST sætter standardtempoet: De tre vindere fra tredje runde får formelle FIPS-numre i 2024/25 - FIPS 203 ML-KEM (tidl. CRYSTALS-Kyber), FIPS 204 ML-DSA (Dilithium) og FIPS 205 SLH-DSA (SPHINCS+). Samtidig kører Round 4 for ekstra KEM-diversitet med Classic McEliece, BIKE og HQC. Disse forventes enten at blive supplerende standarder eller anbefalinger, så organisationer kan matche trusselsmodel, nøglestørrelse og ydeevne til konkrete use cases som TLS, VPN eller firmware-signering.

Økosystemet følger trop: IETF-udkastene til TLS 1.3 + X25519 / ML-KEM og X.509 Hybrid Certificates nærmer sig færdiggørelse, mens OpenSSL 3.2, OpenSSH 9.x og Java 17+ allerede leverer eksperimentel PQC-support. ENISA udsender vejledninger om nøgle- og signaturstørrelser, og chip-leverandører demonstrerer hardwareacceleration til Kyber og Dilithium på ARM, RISC-V og HSM-platforme. Samlet gør det 2025 til året, hvor pilotprojekter skal blive drift - med robuste standarder, tydelige regulatoriske krav og et hurtigt modnende værktøjs-landskab.

De 7 algoritmer du bør kende: styrker, svagheder og modenhed

ML-KEM (CRYSTALS-Kyber): gitterbaseret Key-Encapsulation Mechanism, nu publiceret som FIPS 203. Sikkerheden hviler på Learning-With-Errors; angrebsmargen vurderes bred. Offentlig nøgle og ciphertext ligger omkring 1,1 KB (ML-KEM-768), hvilket giver fornuftige pakke-størrelser til TLS 1.3 og QUIC. Implementationer i OpenSSL 3.2 og BoringSSL samt hardware-acceleration fra flere CPU-leverandører. Velegnet til hybrid TLS/X25519, VPN-tunneller og IoT-key-establishment.
ML-DSA (CRYSTALS-Dilithium): søsteralgoritmen til Kyber, nu FIPS 204. Signaturer ~2,7 KB; offentlig nøgle ~1,3 KB (Dilithium-3). Meget hurtig nøgle- og signatur­generering, moderat verifikationshastighed. Bruges allerede i OpenSSH 9.x og kan erstatte RSA/ECDSA i X.509-certifikater, firmware-signering og e-mail.
SLH-DSA (SPHINCS+): hash-baseret signatur som udelukkende hviler på egenskaberne af SHA-2/SHA-3. Signaturer 8-16 KB og verifikation langsommere end Dilithium/Falcon, men giver minimal kryptografisk antagelse. Standardiseret som FIPS 205 og ideel til langtidsarkivering, blockchain-transaktioner og kode-signering, hvor 10+ års dataintegritet vejer tungt.
Falcon: udvalgt til NIST-standardisering (FIPS-20x forventet). Leverer ekstremt små signaturer (~666 B) og nøgler (~897 B) men kræver kompleks flydekomma-kode og sidekanal­beskyttelse. Hurtig verifikation, moderat signering; egner sig til båndbredde-sensitive scenarier som satellitkommunikation og mobile hardware-tokens, hvor CPU’en er kraftig nok til at håndtere de numeriske operationer.

Classic McEliece: kodebaseret KEM med 40-års kryptanalytisk track-record. Offentlig nøgle 250-500 KB; ciphertext ~128 B; privat nøgle lille. Trods klodsede nøgler vurderes den som “højeste betroede” blandt Round-4-kandidater. TLS-sessioner rammes af MTU-fragmentering, men løsningen er attraktiv til store serversystemer, postlager-kryptering og statiske PKI-roller hvor nøglen caches.
BIKE: bit-flipping-baseret kodefamilie med kompakte offentlige nøgler (~3 KB) og hurtig encapsulation/decapsulation; kandidatur hænger på nye analysespor om sjældne strukturelle angreb. IETF’s PQC-TLS-hybrider har eksperimentel support, og BIKE er let at integrere i embedded VPN-gateways eller M2M-links.
HQC: en afbalanceret kodebaseret KEM (nøgler ~7 KB, ciphertext ~7 KB, meget hurtig softwareydelse). Den deler trusselsmodel med BIKE men med andre parameter­valg, hvilket giver institutioner mulighed for crypto-diversitet. Begge afventer NIST’s endelige Round-4-beslutning (forventet 2025), men er allerede pakket i OpenSSL-forks og liboqs, så du kan lave PoC’er nu. Vælg McEliece til “arkiv-sikkerhed”, BIKE til lav latenstid og HQC hvis du ønsker mellemvejen - og husk altid at parre dem med enten ML-DSA, Falcon eller SLH-DSA, så både konfidensialitet og autenticitet følger dig ind i den kvante­modne æra.

Fra PoC til drift: arkitektur, performance og migreringsplan

At komme fra Proof-of-Concept til driftsklar post-kvantearkitektur begynder med en kryptografisk kortlægning: Identificér alle data-klasser med levetid > 5 år (fx kundejournaler, firmware-opdateringer, PKI-rodcertifikater) og par dem med de protokoller, der beskytter dem. Ud fra kortlægningen etableres en crypto-agility-politik, som kræver modulære crypto-abstraktioner, versions-tags i protokol­handshakes og automatiseret rotation af nøgler/certifikater. Dernæst vælges KEM+signatur-par til hvert use-case: TLS 1.3 får typisk hybrid X25519 + ML-KEM-768 (fremtidssikring uden performancechok), mens X.509-rodcertifikater signeres med ML-DSA-60xx og fallback SLH-DSA-128f for “hedging”. Sæt klare grænseværdier for nøgle- og signaturstørrelser; ML-KEM-768 public key ≈ 1 kB, men Classic McEliece kan nå 250 kB - test MTU-fragmentering (særligt i UDP-baserede protokoller) og mål handshake-latency på højlatenstlinks. I implementeringsfasen er sidekanaler (cache-timing i gitter­algebra), determinisme vs. randomisering i signatur­algoritmer samt korrekt seeding af DRBG’er hyppige faldgruber; brug derfor constant-time biblioteker, f.eks. OpenSSL 3.3+ med enable-kyber-x25519 build-flag, eller pq-clean-baserede bindings i Java 17 og .NET 8. HSM-leverandører som Utimaco, Thales og Nitrokey tilbyder allerede beta-firmware med ML-KEM/ML-DSA; planlæg firmware-rulles ud samtidig med applikations­opgraderinger for at undgå split-brain scenarier.

Byg en test- og pilot­pipeline hvor klienter/servicelag kører dual-stack (klassisk + PQ) i staging, indsamler handshake_success_rate-metrics og måler CPU/cycle-kost. Hav en rollback-plan: versionér cert-profiler i metadatakey-value-par, og oprethold SHA-256-signerede fallback-certifikater i CRL/OCSP. Aktivér detaljeret telemetri (TLS content-type 0xFE primitiv-logning) og syslog-baseret overvågning for at spotte MTU-drop eller HSM-fejl. Integrér nøgle-/cert-livscyklus i eksisterende KMS og dokumentér valideringsspor til NIS2, DORA og ISO 27001 bilag. Nedenfor følger en pragmatisk 6-12 måneders tjekliste:

• Måned 1-2: Data-klassificering, threat-model og crypto-policy.
• Måned 3-4: Lab-PoC med hybrid TLS og PQ-signerede docker-images.
• Måned 5-6: HSM-firmware­opgradering, CI/CD-integration og sidekanal-audit.
• Måned 7-8: Pilot i ikke-kritisk miljø (intern VPN, test-PKI), MTU/latency-målinger.
• Måned 9-10: Rollout til eksterne tjenester, aktiver logging & alerting dashboards.
• Måned 11: Compliance-review, backup/rollback-test, nøgle-rotation-dry-run.
• Måned 12: Overdragelse til drift, opdateret risikoregister og ledelsesrapport.