I mars 2025 gjorde NIST noe uvanlig: byrået valgte en femte algoritme til den amerikanske post-kvante-standarden, nesten et helt år etter at de tre første standardene ble ferdigstilt. Algoritmen heter HQC, og den er ikke ment å erstatte favoritten ML-KEM. Den er en reserve, valgt spesifikt fordi den bygger på helt andre matematiske prinsipper. For utviklere, sikkerhetsarkitekter og alle som planlegger overgangen til kvantesikker kryptering i Norge og Norden, reiser det et konkret spørsmål: når gir det mening å bruke ML-KEM, når gir HQC mening, og hva koster forskjellen i praksis?
Denne artikkelen går gjennom begge algoritmene i detalj: nøkkelstørrelser, ytelse, matematisk grunnlag, standardiseringsstatus og hvordan norske og nordiske virksomheter bør planlegge migreringen. Alle tall er hentet fra NIST, offisielle spesifikasjonsdokumenter og uavhengige benchmarks, med kildehenvisning gjennom hele teksten.
Kvantetrusselen: hvorfor tidslinjen haster allerede nå
Ingen kvantedatamaskin i dag er stor nok til å knekke RSA-2048 eller ECC i praksis. Det er nettopp derfor mange virksomheter skyver problemet foran seg. Men trusselen som får sikkerhetsmiljøet til å handle nå, kalles «harvest now, decrypt later»: en angriper kan avlytte og lagre kryptert trafikk i dag, uten å kunne lese den, og vente til en tilstrekkelig kraftig kvantedatamaskin foreligger for å dekryptere alt i ettertid. For data som må forbli hemmelig i ti, femten eller tjue år, som helsejournaler, forsvarshemmeligheter eller langsiktige finansavtaler, er denne risikoen reell allerede i dag, uavhengig av når selve kvantedatamaskinen dukker opp.
Det er også grunnen til at både NSM og EUs cybersikkerhetsbyrå ENISA har begynt å publisere konkrete tidsfrister for migrering, i stedet for å overlate det til den enkelte virksomhet å bestemme tempoet selv. Kvantetrusselen er med andre ord ikke et fremtidsscenario for kryptografer å bekymre seg om om ti år. Den er en planleggingsoppgave som allerede står på agendaen til Nasjonal sikkerhetsmyndighet, EU-kommisjonen og finansnæringens egne bransjeorganisasjoner i 2026.
Hva er en Key Encapsulation Mechanism (KEM)?
En KEM løser det samme problemet som Diffie-Hellman-nøkkelutveksling har løst siden 1976: to parter som aldri har møttes skal bli enige om en hemmelig nøkkel over en usikret linje. Forskjellen er at en KEM er bygget for et etter-kvante-scenario der en angriper med en tilstrekkelig stor kvantedatamaskin kan knekke klassisk offentlig-nøkkel-kryptografi ved hjelp av Shors algoritme. RSA og elliptisk kurve-kryptografi (ECC), som i dag sikrer nesten all TLS-trafikk, faller begge for dette angrepet i teorien, selv om ingen kvantedatamaskin i dag er stor nok til å utføre det.
En KEM fungerer i tre steg: nøkkelgenerering, innkapsling (encapsulation) og utpakking (decapsulation). Avsenderen bruker mottakerens offentlige nøkkel til å generere en hemmelig delt nøkkel og en chiffertekst. Mottakeren bruker sin private nøkkel til å utlede den samme hemmelige nøkkelen fra chifferteksten. Den delte nøkkelen brukes deretter til symmetrisk kryptering, akkurat som i dagens TLS-oppsett. Det som skiller post-kvante-KEM-er fra klassisk nøkkelutveksling, er det matematiske problemet de hviler på: strukturerte gitter for ML-KEM, feilrettende koder for HQC.
ML-KEM (FIPS 203): Hovedalgoritmen forklart
ML-KEM, tidligere kjent som CRYSTALS-Kyber, ble den 13. august 2024 offisielt publisert som FIPS 203, «Module-Lattice-Based Key-Encapsulation Mechanism Standard». Navnet forteller det meste: sikkerheten hviler på modul-gitter, konkret på vanskeligheten av Module-Learning-With-Errors-problemet (Module-LWE) og det relaterte Module-SIS-problemet. Dette er strukturerte gitterproblemer, valgt fordi de gir svært kompakte nøkler sammenlignet med generiske gitterkonstruksjoner. Kyber vant selv frem i NISTs flerårige konkurranse allerede i juli 2022, og fikk dermed to ekstra år med offentlig kryptoanalyse før den endelige standarden ble publisert, noe som ga forskningsmiljøet tid til å teste algoritmen grundig før den ble låst fast.
Standarden definerer tre parametersett: ML-KEM-512, ML-KEM-768 og ML-KEM-1024, som tilsvarer omtrent 128-, 192- og 256-bit klassisk sikkerhet (grovt sammenlignbart med AES-128, AES-192 og AES-256). NIST anbefaler ML-KEM-768 som standardvalg for de fleste applikasjoner, ettersom det gir god sikkerhetsmargin uten unødvendig overhead. Google Chrome aktiverte hybrid X25519+Kyber-768-nøkkelutveksling som standard fra og med Chrome 124 i april 2024, lenge før FIPS 203 ble ferdigstilt, og har siden migrert til den endelige ML-KEM-768-spesifikasjonen. Et viktig poeng er at ML-KEM så godt som alltid rulles ut i hybridmodus: den post-kvante-sikre nøkkelen kombineres med en klassisk elliptisk kurve, slik at forbindelsen forblir minst like sikker som i dag selv om det skulle vise seg en svakhet i den nye algoritmen.
HQC: Den nye reservealgoritmen
HQC står for Hamming Quasi-Cyclic, og er en kodebasert kryptosystem-familie som bruker kvasi-sykliske koder i Hamming-metrikk. Konstruksjonen har røtter tilbake til McEliece-kryptosystemet fra 1978, en av de eldste kandidatene til post-kvante-kryptografi som fortsatt står uknekket etter mer enn 45 år med kryptoanalyse. NIST valgte HQC den 11. mars 2025 som den femte algoritmen i sin post-kvante-portefølje, med en eksplisitt begrunnelse: byrået ønsket en reservealgoritme bygget på et helt annet matematisk fundament enn de gitterbaserte standardene.
Ifølge NIST vil HQC fungere som backup for ML-KEM, altså «hovedalgoritmen for generell kryptering». Tanken er enkel: hvis noen finner et gjennombrudd i kryptoanalyse av strukturerte gitter, noe forskningsmiljøet aktivt studerer (blant annet i «A Lattice Attack on CRYSTALS-Kyber», publisert av IACR), skal HQC stå klar som en fullstendig uavhengig erstatning. Prisen for denne forsikringen er betydelig større nøkler og lavere ytelse, noe vi går gjennom i detalj under.
IACR-artikkelen om gitterangrep beskriver ikke et praktisk brudd på ML-KEM. Den beskriver teoretiske svekkelser i angrepskostnaden mot spesifikke varianter av gitterproblemet, av den typen kryptografer forventer og aktivt leter etter for å teste standardenes sikkerhetsmarginer. Nettopp denne kontinuerlige kryptoanalysen er grunnen til at NIST valgte å ha en fullstendig uavhengig backup klar, i stedet for å stole blindt på at ett matematisk fundament forblir sikkert i flere tiår fremover. HQC-spesifikasjonen selv er offentlig tilgjengelig og oppdateres jevnlig av forfatterne bak algoritmen, senest i august 2025.
Matematisk grunnlag: Gitter mot kodebasert kryptografi
Forskjellen mellom ML-KEM og HQC handler i bunn og grunn om hvilket matematisk problem en angriper må løse for å knekke nøkkelen. ML-KEM baserer seg på gitterproblemer: gitt et høydimensjonalt gitter forstyrret med støy, finn den korteste vektoren eller løs et system med tilnærmet lineære ligninger. Dette er svært studert innen post-kvante-forskning, men gitterkryptografi er relativt ung sammenlignet med kodebasert kryptografi. Strukturerte gitter (som modul-gitter) gir kompakthet, men den samme strukturen kan i teorien gi angripere et ekstra angrepsflate som generiske gitter ikke har.
HQC baserer seg på et helt annet problem: dekoding av tilfeldige lineære koder i Hamming-metrikk, altså å finne det nærmeste kodeordet gitt en forstyrret vektor. Dette problemet er NP-hardt i sin generelle form og har vært gjenstand for kryptoanalyse siden 1970-tallet uten at noen har funnet en effektiv kvantealgoritme for å løse det. Nettopp denne lange historien er grunnen til at NIST anser kodebasert kryptografi som en verdifull, uavhengig sikkerhetsmargin. Når NIST skriver at HQC gir «diversity in the types of mathematical problems» i standardporteføljen, er det denne uavhengigheten de sikrer.
Spesifikasjonstabell: ML-KEM mot HQC side om side
Tabellen under viser offisielle nøkkel- og chiffertekststørrelser for begge algoritmefamiliene på tvers av sikkerhetsnivåer, hentet fra FIPS 203-spesifikasjonen og Open Quantum Safe-prosjektets liboqs-referanseimplementasjon for HQC, kryssjekket mot den offisielle HQC-spesifikasjonen.
| Egenskap | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 | HQC-128 | HQC-192 | HQC-256 |
|---|---|---|---|---|---|---|
| Standard | FIPS 203 | FIPS 203 | FIPS 203 | Utkast, NIST-valgt | Utkast, NIST-valgt | Utkast, NIST-valgt |
| Matematisk grunnlag | Modul-gitter | Modul-gitter | Modul-gitter | Kvasi-syklisk kode | Kvasi-syklisk kode | Kvasi-syklisk kode |
| Sikkerhetsnivå (NIST-kategori) | 1 (~AES-128) | 3 (~AES-192) | 5 (~AES-256) | 1 (~AES-128) | 3 (~AES-192) | 5 (~AES-256) |
| Offentlig nøkkel | 800 byte | 1 184 byte | 1 568 byte | 2 241 byte | 4 514 byte | 7 237 byte |
| Privat nøkkel | 1 632 byte | 2 400 byte | 3 168 byte | 2 321 byte | 4 602 byte | 7 333 byte |
| Chiffertekst | 768 byte | 1 088 byte | 1 568 byte | 4 433 byte | 8 978 byte | 14 421 byte |
| Delt hemmelighet | 32 byte | 32 byte | 32 byte | 32 byte | 32 byte | 32 byte |
| Total nøkkel + chiffertekst | ~2,4 KB | ~3,5 KB | ~4,7 KB | ~6,7 KB | ~13,5 KB | ~21,7 KB |
| Rolle i NIST-porteføljen | Hovedvalg | Anbefalt standard | Høy sikkerhet | Reserve | Reserve | Reserve |
| Produksjonsklar i store TLS-stakker | Ja | Ja | Delvis | Nei | Nei | Nei |
Det mest slående tallet i tabellen er chiffertekststørrelsen. Ved sammenlignbart sikkerhetsnivå er en HQC-chiffertekst mellom 5,8 og 9,2 ganger større enn ML-KEMs. Ved høyeste sikkerhetsnivå snakker vi om 14 421 byte mot 1 568 byte, en forskjell som får konsekvenser for alt fra TCP-pakkefragmentering til båndbredde på tregere mobilnett.
For arkitekter som designer TLS-terminering, API-gatewayer eller VPN-løsninger er dette mer enn et akademisk sammenligningspunkt. En chiffertekst over den vanlige MTU-grensen på 1 500 byte for Ethernet betyr at pakken må fragmenteres, noe som øker sannsynligheten for tap og retransmisjon på ustabile forbindelser. ML-KEM-1024s chiffertekst på 1 568 byte ligger allerede rett over denne grensen, mens samtlige HQC-varianter ligger godt over den. Dette er én av de tekniske grunnene til at ML-KEM-768, med en ciffertekst på 1 088 byte, ofte anbefales som praktisk standardvalg fremfor det høyeste sikkerhetsnivået, selv i systemer som i utgangspunktet ønsker maksimal sikkerhetsmargin.
Ytelsesbenchmarks: Hastighet i praksis
Nøkkelstørrelse forteller bare halve historien. Den andre halvparten er hvor lang tid nøkkelgenerering, innkapsling og utpakking tar. Her er tallene tydelige og kommer fra tre uavhengige kilder: en ytelsesdokumentasjon fra 365architect for ML-KEM, en offisiell NIST-presentasjon fra HQC-teamet (Gaborit et al.) på PQC 2022-workshopen, og en 2026-benchmark publisert på arXiv som sammenligner begge standardene direkte på moderne maskinvare.
| Algoritme | Nøkkelgenerering | Innkapsling | Utpakking | Total håndtrykktid (relativ) |
|---|---|---|---|---|
| ML-KEM-512 | 45 µs | ~55 µs | ~82 µs | 182 µs |
| ML-KEM-768 | 78 µs | ~85 µs | ~118 µs | 281 µs |
| ML-KEM-1024 | 120 µs | ~135 µs | ~178 µs | 433 µs |
| HQC-128 | ~29 µs (87 kilosykluser) | ~68 µs (204 kilosykluser) | ~121 µs (362 kilosykluser) | Betydelig høyere enn ML-KEM-512 |
| HQC-192 | ~68 µs (204 kilosykluser) | ~155 µs (465 kilosykluser) | ~252 µs (755 kilosykluser) | Betydelig høyere enn ML-KEM-768 |
| HQC-256 | ~136 µs (409 kilosykluser) | ~301 µs (904 kilosykluser) | ~502 µs (1 505 kilosykluser) | Betydelig høyere enn ML-KEM-1024 |
| RSA-2048 (referanse) | 5 200 µs | – | – | 10 150 µs |
| ECDH P-256 (referanse) | 52 µs | – | – | 202 µs |
NIST-presentasjonen fra Gaborit et al. oppgir HQC-tallene i kilosykluser på referansemaskinvare snarere enn mikrosekunder direkte. Vi har omregnet til omtrentlige mikrosekundverdier basert på en typisk klokkefrekvens på 3 GHz for lesbarhetens skyld, men de opprinnelige kildetallene i kilosykluser er de autoritative. Konklusjonen holder uansett: ML-KEM-768 gjør et fullstendig håndtrykk raskere enn ECDH P-256, mens HQC-192 bruker vesentlig lengre tid per operasjon, særlig i utpakkingsfasen der HQC må dekode feilrettende koder.
Til sammenligning viser arXiv-benchmarken fra 2026 at ML-KEM kan nå «sub-millisekund»-ytelse selv ved høyeste parametersett på vanlig skrivebordsmaskinvare, med gjennomstrømning i størrelsesorden hundretusener av innkapslinger per sekund på moderne CPU-kjerner. Begge algoritmer er langt raskere enn RSA-2048, men ML-KEM slår HQC tydelig på rå hastighet ved samme sikkerhetsnivå.
Nøkkelstørrelser og båndbreddekostnad i TLS
For en vanlig nettleser som besøker en nettside, er ikke mikrosekunder det som merkes mest. Det er byte som må over ledningen før siden lastes. Cloudflare rullet ut post-kvante-nøkkelutveksling over hele sitt globale nettverk i 2023, først med det midlertidige X25519Kyber768Draft00-oppsettet, siden med den endelige FIPS 203 ML-KEM-768-standarden. Selskapet rapporterer at overheaden på rundt 2,3 KB per håndtrykk ikke ga målbar forsinkelse på bredbånd, og under 5 millisekunder ekstra på begrensede mobilnett.
Sett i det lyset blir HQCs kostnad tydeligere. Et HQC-192-håndtrykk legger til over 13 KB i nøkkel- og chiffertekstdata, mot rundt 3,5 KB for ML-KEM-768. På fibernett i Oslo eller Stockholm merkes forskjellen knapt. På et svakt 3G/4G-signal i Nord-Norge eller på Grønland, der pakketap og retransmisjon allerede er en utfordring, kan den ekstra båndbredden bety flere ekstra rundturer og merkbart tregere sidelasting. Dette er en direkte, målbar «kostnad» ved å velge HQC fremfor ML-KEM i produksjon i dag, selv om HQC ennå ikke er tiltenkt bred bruk før algoritmen er ferdig standardisert.
Implementasjonsstøtte: biblioteker og verktøy for utviklere
For utviklere som skal ta i bruk disse algoritmene, handler det sjelden om å skrive gitter- eller kodebasert matematikk fra bunnen av. Det handler om hvilke biblioteker som allerede støtter dem. ML-KEM er i dag integrert i OpenSSL 3.2 og nyere, BoringSSL (Googles fork brukt i Chrome), wolfSSL og AWS’ egen s2n-tls, samt i det språkuavhengige referanseprosjektet Open Quantum Safe (liboqs), som også er stedet de fleste utviklere først møter HQC i praksis. liboqs eksponerer begge algoritmefamiliene gjennom et enhetlig API, noe som gjør det mulig å teste HQC i et forskningsmiljø uten å vente på at store TLS-biblioteker legger til produksjonsstøtte.
Node.js- og Python-utviklere har i dag enklest tilgang til ML-KEM gjennom bindinger som eksponerer OpenSSL- eller BoringSSL-implementasjonene, mens HQC fortsatt stort sett er begrenset til liboqs-bindinger og forskningskode. Dette gapet i modenhet er nok en indikator på hvor langt fra hverandre de to algoritmene står i utrullingsløpet: ML-KEM er en biblioteksavhengighet du kan legge til i dag, HQC er noe du kan eksperimentere med i et sandkassemiljø.
Standardiseringsstatus og tidslinje
ML-KEM er ferdig standardisert. FIPS 203 ble publisert 13. august 2024, sammen med FIPS 204 (ML-DSA, signaturer) og FIPS 205 (SLH-DSA, hash-baserte signaturer). Disse tre er nå føderale amerikanske standarder på linje med AES (FIPS 197) og SHA-2 (FIPS 180-4), og kan brukes i produksjonssystemer i dag.
HQC er derimot fortsatt underveis. NIST valgte algoritmen 11. mars 2025, og har antydet en tidslinje der et utkast til FIPS-standard kan komme i løpet av 2026, med endelig ferdigstillelse anslått til rundt 2027. Frem til det skjer, er HQC ikke egnet for produksjonssystemer som krever FIPS-samsvar, og NIST selv fraråder organisasjoner å hastverke seg inn i uferdige PQC-implementasjoner.
| Milepæl | ML-KEM | HQC |
|---|---|---|
| Opprinnelig NIST-utvelgelse | Juli 2022 (som CRYSTALS-Kyber) | Mars 2025 (femte algoritme) |
| Endelig FIPS-standard | 13. august 2024 (FIPS 203) | Ikke ferdigstilt |
| Forventet utkast til FIPS | Allerede publisert | Anslått i løpet av 2026 |
| Forventet endelig standard | Ferdig | Anslått rundt 2027 |
| Egnet for produksjon i dag | Ja, med hybridmodus | Nei, kun testing/evaluering |
Fem reelle eksempler på hvor ML-KEM allerede er i bruk
ML-KEM er ikke lenger et forskningsprosjekt. Her er fem konkrete driftsmiljøer der algoritmen kjører i dag, hentet fra offentlig dokumentasjon fra selskapene selv:
- Google Chrome: Hybrid X25519+Kyber-768 ble standard fra Chrome 124 (april 2024). Per februar 2026 utfører Chrome hybrid post-kvante-nøkkelutveksling på hver eneste TLS 1.3-tilkobling til servere som støtter det, ifølge dokumentasjon fra H33 som følger utrullingen. Dette betyr i praksis at millioner av norske og nordiske nettlesere allerede gjennomfører post-kvante-sikre håndtrykk hver eneste dag, uten at brukeren merker noe.
- Cloudflare: Post-kvante-nøkkelutveksling er rullet ut over hele Cloudflares globale edge-nettverk siden 2023, nå på den endelige ML-KEM-768-spesifikasjonen etter overgang fra utkastversjonen X25519Kyber768Draft00. Cloudflare drifter et betydelig antall norske og nordiske nettsteder gjennom sitt CDN, noe som gjør denne utrullingen direkte relevant for lokal infrastruktur.
- AWS: ML-KEM-støtte er lagt til i AWS KMS, AWS Certificate Manager og selskapets egen TLS-stack s2n-tls, med ML-KEM-768 hybridmodus tilgjengelig for produksjonsarbeidslaster. AWS har egne europeiske datasentre som brukes av flere norske offentlige og private aktører, noe som gjør denne støtten relevant for lokal databehandling under norsk og europeisk regelverk.
- Signal: Hver ny Signal-økt inkluderer nå en Kyber-1024-innkapsling ved siden av den klassiske X25519-utvekslingen, som gir hybrid post-kvante-beskyttelse for meldingsapplikasjonens dobbel-ratchet-protokoll. Dette er trolig den mest sikkerhetskritiske av de fem, ettersom appen brukes av journalister, aktivister og myndighetspersoner som er nettopp den typen mål «harvest now, decrypt later»-strategien retter seg mot.
- Norsk finansnæring: Finans Norge publiserte i mars 2026 «Veikart for en kvantesikker finansnæring», som anbefaler bruk av etablerte, standardiserte kryptografiske løsninger og bygging av et kryptografisk inventar som grunnlag for migreringsplanlegging i norske banker og finansinstitusjoner. Dette er foreløpig en bransjeanbefaling, ikke et regulatorisk krav fra Finanstilsynet eller Norges Bank, men den setter en tydelig retning for sektoren.
Derfor bør Norge og Norden bry seg nå
Nasjonal sikkerhetsmyndighet (NSM) har hatt en dedikert veileder om kvantemigrasjon siden oktober 2023, sist oppdatert i 2025-2026. Veilederen legger opp til fem steg: vurder hvor kritisk kvantebeskyttelse er for din virksomhet, kartlegg dagens bruk av kryptografi, identifiser hvilke nye standarder som passer systemene, planlegg utskiftingen, og gjennomfør migreringen trinnvis. NSM anbefaler eksplisitt hybridløsninger, altså ECDH kombinert med ML-KEM for nøkkelutveksling og ECDSA kombinert med ML-DSA for signaturer, som et første steg mot full kvantesikkerhet. I sine kryptografiske anbefalinger fra mars 2025 skriver NSM eksplisitt at virksomheter bør «forberede seg på fremveksten av kvantedatamaskiner: lage og gjennomføre en plan for en vellykket migrering til kvanteresistent kryptografi».
På EU-nivå har ENISA lagt frem en tidslinje for overgangen: innen utgangen av 2026 skal alle medlemsland ha definerte veikart for post-kvante-migrering, innen 21. desember 2030 skal høyrisikosektorer som kritisk infrastruktur og finans ha migrert, og innen 31. desember 2035 skal migreringen være fullført for alle risikonivåer. Norge, som er tett koblet til EUs regelverk gjennom EØS, følger et lignende mønster gjennom NSMs anbefalinger og Finans Norges bransjeveikart. For norske og nordiske virksomheter betyr dette konkret: kartleggingsfasen bør være i gang nå, og planen for høyrisikosystemer bør være klar godt før 2030. Verken Finanstilsynet eller Norges Bank har foreløpig publisert egne, separate PQC-migreringskrav utover det som følger av NSMs generelle anbefalinger og EU-regelverket, men det er rimelig å forvente at sektorspesifikke krav kommer etter hvert som 2030-fristen nærmer seg.
Migrasjonsguide: Slik forbereder du systemene dine
Uansett om du planlegger for ML-KEM i dag eller HQC som fremtidig reserve, følger en fornuftig migrering det samme mønsteret som NSM og ENISA anbefaler.
Steg 1-3: Kartlegging og prioritering
- Lag et fullstendig kryptografisk inventar: hvilke systemer bruker RSA eller ECC til nøkkelutveksling, hvor lagres langtidssensitive data, og hvilke tredjepartstjenester er avhengige av klassisk kryptografi.
- Prioriter etter «harvest now, decrypt later»-risiko. Data som må forbli hemmelig i ti år eller mer (helsedata, forretningshemmeligheter, myndighetsdokumenter) bør migreres først, siden en angriper kan lagre kryptert trafikk i dag for å dekryptere den når en kvantedatamaskin foreligger.
- Kartlegg leverandørenes støtte for hybrid PQC. Sjekk om TLS-biblioteket, lastbalansereren og CDN-en allerede støtter ML-KEM i hybridmodus.
Steg 4-7: Implementering
- Aktiver hybrid nøkkelutveksling (klassisk + ML-KEM-768) i TLS 1.3-konfigurasjonen der biblioteket støtter det. Dette gir kvantebeskyttelse uten å svekke klassisk sikkerhet dersom en svakhet i ML-KEM skulle oppdages.
- Test ytelseskonsekvenser i eget nettverksmiljø, spesielt for mobile brukere og IoT-enheter med begrenset båndbredde.
- Hold HQC utenfor produksjon inntil FIPS-standarden er ferdigstilt, men følg med på utviklingen slik at organisasjonen har en plan B klar.
- Dokumenter kryptografisk smidighet i arkitekturen: systemer bør kunne bytte algoritme uten full ombygging, slik Finans Norges veikart anbefaler.
Et eksempel på hybrid TLS-konfigurasjon i OpenSSL 3.x, der gruppen kombinerer klassisk X25519 med ML-KEM-768, kan se slik ut:
openssl s_server -groups X25519MLKEM768 -cert server.crt -key server.key -tls1_3Denne kommandoen setter opp en TLS 1.3-server som forhandler en hybrid nøkkel bestående av både den klassiske X25519-kurven og ML-KEM-768. Dersom klienten ikke støtter hybridmodus, faller forbindelsen tilbake til ren klassisk kryptografi, noe som sikrer bakoverkompatibilitet under overgangsperioden.
Steg 8: Overvåking og videre planlegging
Migrering til hybrid PQC er ikke et engangsprosjekt som avsluttes når konfigurasjonen er satt. Sett opp overvåking som logger hvilken nøkkelutvekslingsmetode klienter faktisk forhandler frem, slik at dere kan følge andelen av trafikken som allerede er kvantesikret over tid, på samme måte som Cloudflare og store nettlesere rapporterer offentlig. Hold også et øye med NIST og NSMs offentlige kanaler for oppdateringer om HQC-standardiseringen, slik at organisasjonen har et realistisk bilde av når en eventuell HQC-backup faktisk kan tas i bruk i produksjon. Sist, men ikke minst: bygg inn kryptografisk smidighet som et arkitekturprinsipp, ikke bare et migreringsprosjekt, slik at neste algoritmebytte blir en konfigurasjonsendring snarere enn en omskriving av kodebasen.
Kostnaden ved å velge feil algoritme
Ingen av algoritmene har en direkte kronekostnad slik en SaaS-lisens har, men begge har en reell driftskostnad i form av CPU-sykluser og båndbredde, som igjen påvirker skyregninger og brukeropplevelse. En lastbalanserer som håndterer TLS-terminering for millioner av tilkoblinger daglig, betaler denne kostnaden i form av flere CPU-kjerner allokert til kryptografiske operasjoner og mer utgående båndbredde per forbindelse, begge deler ting som til syvende og sist havner på en skyregning eller krever mer maskinvare i eget datasenter. Tabellen under oppsummerer den relative ressurskostnaden per håndtrykk, beregnet ut fra tallene i benchmark-tabellene over.
| Ressurs | ML-KEM-768 | HQC-192 | Relativ forskjell |
|---|---|---|---|
| Data over nettverket per håndtrykk | ~3,5 KB | ~13,5 KB | HQC bruker ~3,9x mer båndbredde |
| CPU-tid for utpakking (server) | ~118 µs | ~252 µs | HQC bruker ~2,1x mer CPU-tid |
| Ekstra TCP-rundturer på treg 3G-linje | Sjelden nødvendig | Kan kreve én ekstra rundtur | Merkbar forsinkelse for mobile brukere |
| Skalering ved millioner av forbindelser/dag | Lav marginalkostnad | Vesentlig høyere marginalkostnad | Relevant for CDN- og edge-drift i stor skala |
For en tjeneste som håndterer millioner av TLS-håndtrykk daglig, slik store nordiske nettbanker og strømleverandører gjør, er forskjellen mellom 3,5 KB og 13,5 KB per forbindelse ikke bare et akademisk tall. Multiplisert med volum blir det målbar båndbredde- og CPU-belastning på infrastrukturen. Dette er en av grunnene til at NIST har posisjonert HQC som en reserve snarere enn et likestilt alternativ: kostnaden skal bæres kun hvis den blir nødvendig.
Fordeler og ulemper: ML-KEM mot HQC
Ingen av algoritmene er objektivt «best» i alle sammenhenger. Valget avhenger av om systemet trenger produksjonsklar teknologi i dag, eller om det handler om å bygge langsiktig arkitektonisk beredskap. Oppsummeringen under samler funnene fra tabellene og benchmarkene over i en kortfattet fordeler-og-ulemper-liste for hver algoritme.
ML-KEM: fordeler
- Ferdig standardisert som FIPS 203 siden august 2024, klar for produksjon.
- Kompakte nøkler og chiffertekster (768-1 568 byte), lav båndbreddekostnad.
- Rask ytelse: håndtrykk på under en millisekund, raskere enn ECDH P-256 ved ML-KEM-768.
- Bred produksjonsstøtte i Chrome, Cloudflare, AWS og Signal allerede i dag.
ML-KEM: ulemper
- Baserer seg på strukturerte gitter, en relativt ung gren av kryptografi sammenlignet med kodebaserte systemer.
- Utgjør et enkelt matematisk fundament: et fremtidig gjennombrudd mot gitterproblemer ville ramme både ML-KEM og ML-DSA samtidig.
HQC: fordeler
- Bygger på kodebasert kryptografi med over 45 år med kryptoanalyse uten praktisk gjennombrudd.
- Gir reell matematisk diversitet i NIST-porteføljen, en forsikring mot fremtidige gitterangrep.
- Godt egnet som arkitektonisk «plan B» for organisasjoner med svært langsiktige sikkerhetsbehov.
HQC: ulemper
- Ikke ferdig standardisert, endelig FIPS-standard er ikke ventet før rundt 2027.
- Chiffertekster mellom 5,8 og 9,2 ganger større enn ML-KEM ved sammenlignbart sikkerhetsnivå.
- Vesentlig tregere utpakking, spesielt merkbart på belastede servere med høyt tilkoblingsvolum.
- Ingen bred produksjonsstøtte ennå i store nettlesere, CDN-er eller skytjenester.
Andre kandidater NIST vurderte som HQC-alternativer
HQC var ikke den eneste kodebaserte kandidaten NIST evaluerte til reservealgoritm-rollen. BIKE (Bit Flipping Key Encapsulation) var en direkte konkurrent gjennom hele fjerde runde av standardiseringsprosessen, også den bygget på kodebasert kryptografi, men med en annen dekodingsalgoritme og en liten restrisiko for dekodingsfeil som HQC ikke har i samme grad. Classic McEliece, den eldste og mest konservative kodebaserte kandidaten, sto også i vurdering, men falt ut delvis på grunn av svært store offentlige nøkler, i størrelsesorden hundretalls kilobyte, som gjør algoritmen upraktisk for de fleste TLS-scenarioer selv om den regnes som ekstremt godt utprøvd.
At NIST til slutt valgte HQC fremfor BIKE, handlet i stor grad om en kombinasjon av ytelse og en ryddigere sikkerhetsanalyse uten kjent restrisiko for dekodingsfeil. For utviklere er poenget uansett det samme: HQC representerer NISTs offisielle svar på spørsmålet «hvilken kodebasert algoritme skal stå klar som reserve», og de andre kandidatene lever videre som forskningsprosjekter og i enkelte nisjeapplikasjoner, men ikke som del av den offisielle standardporteføljen.
Fem bruksområder og hvilken algoritme som passer
Valget mellom algoritmer avhenger sjelden av teknologien alene. Det avhenger av hvor lenge dataene må forbli hemmelige, hvor mye båndbredde systemet har å avse, og hvor modent samsvarskravet er. Under følger fem konkrete kategorier og hvilken tilnærming som passer best for hver av dem i dag.
- Offentlige nettsider og nettbanker: ML-KEM-768 i hybridmodus med klassisk ECDH. Ferdig standardisert, lav overhead, allerede støttet av moderne nettlesere.
- Meldingsapplikasjoner med langtidshemmelighold: ML-KEM-1024 for høyeste sikkerhetsnivå, slik Signal allerede har implementert med Kyber-1024.
- IoT og innebygde enheter med begrenset båndbredde: ML-KEM-512 gir lavest overhead av alle post-kvante-alternativene, viktig når hver kilobyte koster batteritid.
- Arkivering av data med 20+ års hemmeligholdskrav: Vurder å forberede en dobbel implementasjon som kan bytte til HQC når standarden er ferdig, som en ekstra sikkerhetsmargin utover ML-KEM alene.
- Forskning, testmiljøer og kryptoagile plattformer: HQC kan implementeres allerede nå i ikke-produksjonsmiljøer for å bygge kompetanse og teste kryptografisk smidighet før standarden er ferdig.
Vanlige misforståelser om ML-KEM og HQC
Den vanligste misforståelsen er at HQCs utvelgelse betyr at ML-KEM er usikker eller på vei ut. Det stemmer ikke. NIST har vært eksplisitt på at ML-KEM forblir hovedalgoritmen, og HQC er ment som en beredskapsløsning, ikke en erstatning. En annen vanlig feil er å anta at «post-kvante» betyr «erstatt all klassisk kryptografi umiddelbart». Både NSM og ENISA anbefaler tvert imot hybridmodus, altså å kjøre klassisk og post-kvante-kryptografi side om side, nettopp fordi de nye algoritmene er yngre og mindre gjennomprøvd enn RSA og ECC. Til sist bør det presiseres at verken ML-KEM eller HQC beskytter mot kvante-angrep på digitale signaturer, det krever egne standarder som ML-DSA eller SLH-DSA.
En fjerde misforståelse er å tro at større nøkler automatisk betyr sterkere sikkerhet. HQCs nøkler er langt større enn ML-KEMs, men det betyr ikke at HQC gir høyere sikkerhetsnivå ved samme parametersett, kun at den underliggende matematiske konstruksjonen krever mer data for å oppnå samme sikkerhetsmargin. Og en femte, ofte oversett detalj: å aktivere hybrid PQC i TLS-konfigurasjonen løser bare nøkkelutvekslingsdelen av kvantesikkerheten. Sertifikater, signaturer og andre kryptografiske komponenter i samme system må vurderes og migreres separat, typisk til ML-DSA eller SLH-DSA, for at hele kjeden skal være kvantesikker.
Verdikt: Hvilken bør du velge?
For nesten alle praktiske formål i dag er svaret enkelt: bruk ML-KEM-768 i hybridmodus med klassisk nøkkelutveksling. Algoritmen er ferdig standardisert, raskere enn ECDH P-256 i totalt håndtrykk, og allerede i drift hos Chrome, Cloudflare, AWS og Signal. Tallene i denne artikkelen viser hvorfor: en chiffertekst på 1 088 byte og et håndtrykk på 281 mikrosekunder slår enkelt og greit HQC-192s 8 978 byte og betydelig lengre utpakkingstid, uten at sikkerhetsnivået er lavere.
HQC har likevel sin plass, ikke som en konkurrent i dag, men som en forsikringspolise for morgendagen. Organisasjoner med svært langsiktige sikkerhetsbehov, eller de som følger NSMs anbefaling om kryptografisk smidighet tett, bør begynne å planlegge for en fremtidig HQC-implementasjon parallelt med at ML-KEM rulles ut nå. Når FIPS-standarden for HQC er ferdig, trolig i 2026 eller 2027, vil valget ikke lenger være enten-eller, men et spørsmål om når man legger til det andre laget i en allerede hybrid arkitektur.
For norske og nordiske organisasjoner er den konkrete anbefalingen denne: start kartleggingen i tråd med NSMs femstegsmodell allerede nå, aktiver hybrid ML-KEM-768 på systemer som støtter det innen utgangen av 2026 for å ligge i forkant av ENISAs tidslinje, og hold HQC på radaren som et element i den langsiktige kryptografiske smidighetsplanen snarere enn noe som krever handling i dag. Den som venter til 2029 med å begynne, vil oppdage at kartlegging alene, ifølge både NSM og Finans Norges veikart, ofte tar lengre tid enn selve den tekniske implementeringen.
Ofte stilte spørsmål
Er ML-KEM det samme som Kyber?
Ja. ML-KEM er navnet NIST ga til CRYSTALS-Kyber da algoritmen ble standardisert som FIPS 203 i august 2024. Navnet «Module-Lattice-Based Key-Encapsulation Mechanism» beskriver det matematiske grunnlaget direkte.
Kan jeg bruke HQC i produksjon i dag?
Ikke anbefalt. HQC er valgt av NIST, men FIPS-standarden er ikke ferdigstilt. Referanseimplementasjoner finnes i biblioteker som Open Quantum Safes liboqs for testing og evaluering, men produksjonssystemer bør vente på den endelige standarden, ventet rundt 2026-2027.
Hvorfor trenger vi to KEM-standarder i det hele tatt?
Fordi ingen ønsker å sette all sikkerhet på én matematisk hypotese. Dersom det skulle vise seg at strukturerte gitter er sårbare for et angrep ingen har forutsett, gir HQCs kodebaserte fundament et fullstendig uavhengig sikkerhetsnett. NIST beskriver dette selv som mål om diversitet i porteføljen.
Påvirker post-kvante-kryptering nettsidehastigheten merkbart?
For ML-KEM: knapt merkbart. Cloudflare rapporterer ingen målbar forsinkelse på bredbånd og under 5 millisekunder ekstra på mobilnett. For HQC, som ikke er i bred bruk ennå, er overheaden vesentlig større og kan bli merkbar på svake mobilforbindelser.
Hva bør norske virksomheter gjøre først?
Følg NSMs femstegs kvantemigrasjonsveileder: vurder kritikalitet, kartlegg dagens kryptografibruk, identifiser passende nye standarder, planlegg utskifting, og gjennomfør trinnvis. Start med systemer som håndterer langtidssensitive data.
Er RSA og ECC usikre allerede i dag?
Nei, ingen kjent kvantedatamaskin er stor nok til å knekke RSA-2048 eller P-256 i praksis. Risikoen ligger i «harvest now, decrypt later»: en angriper kan lagre kryptert trafikk i dag og dekryptere den når en tilstrekkelig stor kvantedatamaskin foreligger, noe som gjør migrering til hybrid PQC relevant nå for data med lang levetid.
Hva er forskjellen på ML-KEM og ML-DSA?
ML-KEM (FIPS 203) er en nøkkelinnkapslingsmekanisme brukt til å etablere en delt hemmelig nøkkel, mens ML-DSA (FIPS 204) er en digital signaturalgoritme brukt til å bekrefte autentisitet og integritet. De løser ulike problemer og brukes ofte sammen i samme protokoll, for eksempel TLS.
Vil HQC noen gang bli raskere enn ML-KEM?
Trolig ikke vesentlig. Ytelsesforskjellen skyldes den grunnleggende matematiske strukturen: kodebasert dekoding krever mer regnearbeid enn gitteroperasjoner ved sammenlignbar sikkerhet. Implementasjonsoptimalisering kan lukke noe av gapet, men den strukturelle forskjellen i nøkkelstørrelse vil trolig bestå.
Må jeg velge én av dem, eller kan jeg bruke begge samtidig?
I fremtiden er tanken nettopp at kritiske systemer kan kombinere begge, en modell noen kryptografer kaller «dobbel-hybrid»: klassisk kryptografi pluss ML-KEM pluss HQC i samme håndtrykk. Dette gir maksimal robusthet mot både kvanteangrep og eventuelle fremtidige svakheter i én av de to post-kvante-familiene, men til en betydelig kostnad i båndbredde og kompleksitet. I dag er dette først og fremst relevant for forskning og svært høyrisikosystemer, ikke standard nettrafikk.
Hvor kan jeg teste ML-KEM og HQC selv?
Open Quantum Safes liboqs-bibliotek er det enkleste stedet å starte, med referanseimplementasjoner av begge algoritmefamiliene og et enhetlig API på tvers av programmeringsspråk. OpenSSL 3.2 og nyere støtter ML-KEM direkte via kommandolinjeverktøyet, som vist i eksempelet i migrasjonsguiden over. For HQC må de fleste utviklere foreløpig gå via liboqs eller referanseimplementasjonen publisert på det offisielle HQC-nettstedet, ettersom algoritmen ennå ikke er integrert i de store TLS-bibliotekene.
