Tre år etter at NIST gjorde ML-KEM til den offisielle standarden for kvantesikker nøkkelutveksling, sitter mange utviklere fortsatt fast på samme spørsmål: hvilket av de tre parametersettene bør man faktisk velge? ML-KEM-512, ML-KEM-768 og ML-KEM-1024 er alle godkjent i FIPS 203, men de gir svært ulike avveininger mellom nøkkelstørrelse, hastighet og sikkerhetsmargin. Denne artikkelen går gjennom tallene fra CRYPTREC, akademiske 2026-benchmarker og faktisk produksjonsbruk hos Chrome, Cloudflare, OpenSSH og AWS, slik at valget blir enklere å ta.
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) er etterfølgeren til CRYSTALS-Kyber, og ble endelig standardisert av det amerikanske National Institute of Standards and Technology i august 2024 gjennom FIPS 203. Algoritmen finnes i tre varianter, og navnene forteller ikke bare om nøkkelstørrelse, men om hvilket trusselnivå de er bygget for å tåle. Vi sammenligner byte for byte, millisekund for millisekund, og ser på hva forskjellen faktisk koster når trafikken skaleres opp til milliarder av håndtrykk.
Hva er ML-KEM, og hvorfor finnes det i tre varianter?
ML-KEM bygger på et matematisk problem kalt Module Learning With Errors (Module-LWE), som anses som vanskelig å løse selv for en kvantedatamaskin med tilstrekkelig kapasitet. I motsetning til RSA og elliptisk kurve-kryptografi, som begge kan brytes av Shors algoritme på en stor nok kvantemaskin, hviler ML-KEM sin sikkerhet på gitterproblemer som foreløpig ikke har noen kjent kvanteangrep med praktisk effekt.
De tre parametersettene, ML-KEM-512, ML-KEM-768 og ML-KEM-1024, deler samme underliggende konstruksjon, men justerer modul-dimensjonen k og støyparametrene for å oppnå ulike sikkerhetsnivåer. NIST plasserer dem i sikkerhetskategori 1, 3 og 5, som grovt tilsvarer motstandsdyktigheten til AES-128, AES-192 og AES-256 mot brute force-angrep. Dette er ikke tilfeldig navngivning: NIST selv skriver at “in order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024” (på norsk: i rekkefølge med økende sikkerhetsstyrke og synkende ytelse er disse ML-KEM-512, ML-KEM-768 og ML-KEM-1024), ifølge NISTs offisielle publikasjon om standarden.
Det praktiske spørsmålet handler sjelden om hvilken variant som er “sikrest” i isolasjon. Alle tre er godkjent for produksjonsbruk og har ingen kjente praktiske svakheter. Spørsmålet er heller hvilken variant som gir riktig balanse mellom sikkerhetsmargin og kostnaden i båndbredde, prosessortid og batterilevetid for din spesifikke arbeidsmengde. En IoT-sensor med begrenset radiobåndbredde har helt andre krav enn en nasjonal sikkerhetsinfrastruktur som skal beskytte klassifisert informasjon i flere tiår.
Veien til FIPS 203: Fra Kyber til statlig standard
ML-KEM startet livet som CRYSTALS-Kyber, en av flere kandidater i NISTs post-kvante-konkurranse som ble lansert i 2016. Konkurransen samlet inn forslag fra kryptografimiljøer over hele verden, og gikk gjennom flere runder med offentlig kryptoanalyse der forskere aktivt forsøkte å bryte hver kandidat. Kyber overlevde alle rundene og ble i juli 2022 kåret som NISTs valgte algoritme for generell nøkkelinnkapsling, sammen med tre signaturalgoritmer som senere ble til ML-DSA, SLH-DSA og etter hvert Falcon-baserte FN-DSA.
Fra utvalg til ferdig standard tok det ytterligere to år. NIST brukte perioden til å gjøre mindre justeringer i den offisielle spesifikasjonen sammenlignet med den opprinnelige Kyber-innsendelsen, blant annet i hvordan hashfunksjoner brukes internt i algoritmen. Det er grunnen til at tidlige eksperimentelle implementasjoner med navn som “Kyber768” eller “X25519Kyber768Draft00” ikke er byte-for-byte kompatible med den endelige ML-KEM-standarden. Navnebyttet fra Kyber til ML-KEM markerer nettopp dette skillet: ML-KEM er den juridisk og teknisk bindende versjonen publisert i FIPS 203 i august 2024, mens Kyber-navnet i dag helst bør reserveres for den opprinnelige konkurranseinnsendelsen og tidlige utkast.
Denne historien er ikke bare en fotnote. Den forklarer hvorfor så mange store aktører ventet med bred utrulling til 2024 og 2025, selv om Kyber i praksis hadde vært tilgjengelig i eksperimentell form i flere år før det. Å vente på den endelige, standardiserte versjonen reduserte risikoen for at produksjonssystemer måtte bytte ut en hel kryptografisk primitiv i etterkant, noe som ville vært en langt mer kostbar migrering enn den gradvise hybrid-utrullingen vi ser i dag.
Nøkkelstørrelser og tekniske spesifikasjoner side om side
Den mest håndfaste forskjellen mellom de tre parametersettene er byte-størrelsen på nøkler og chiffertekst. Disse tallene er hentet direkte fra FIPS 203-spesifikasjonen og er identiske uansett hvilken implementasjon eller programmeringsspråk man bruker, siden de er en del av selve standarden. PostQuantum.com oppsummerer det slik: “ML-KEM comes with three parameter sets (ML-KEM-512, 768, 1024) targeting different security levels (~AES-128, AES-192, AES-256 respectively)” (ML-KEM leveres med tre parametersett som retter seg mot ulike sikkerhetsnivåer, tilsvarende omtrent AES-128, AES-192 og AES-256), ifølge PostQuantum.coms gjennomgang av NISTs PQC-standarder.
| Egenskap | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 |
|---|---|---|---|
| NIST-sikkerhetskategori | Kategori 1 | Kategori 3 | Kategori 5 |
| Tilsvarende klassisk styrke | AES-128 | AES-192 | AES-256 |
| Offentlig nøkkel | 800 byte | 1 184 byte | 1 568 byte |
| Chiffertekst | 768 byte | 1 088 byte | 1 568 byte |
| Privat/dekapsuleringsnøkkel | 1 632 byte | 2 400 byte | 3 168 byte |
| Delt hemmelighet | 32 byte | 32 byte | 32 byte |
| Offentlig nøkkel + chiffertekst | 1 568 byte | 2 272 byte | 3 136 byte |
| Modul-dimensjon (k) | 2 | 3 | 4 |
| Polynomgrad (n) | 256 | 256 | 256 |
| Modulverdi (q) | 3 329 | 3 329 | 3 329 |
| Standard | FIPS 203 | FIPS 203 | FIPS 203 |
| Typisk hybrid TLS-gruppe | Sjelden brukt i TLS | X25519MLKEM768 | Brukt i høysikkerhetsscenarier |
Legg merke til at nøkkelstørrelsen vokser raskere enn sikkerhetsnivået. Den offentlige nøkkelen i ML-KEM-1024 er 96 prosent større enn i ML-KEM-512, mens chifferteksten er 104 prosent større. Dette er kjernen i avveiningen: du betaler nesten dobbelt så mye i data for å gå fra laveste til høyeste sikkerhetsnivå, men det gir ikke en dobling av faktisk sikkerhetsmargin i praktisk forstand. IETF-arbeidsgruppen som skriver TLS-utkastet for ML-KEM, dokumenterer de eksakte tallene slik: “ML-KEM-768 has encapsulation keys of size 1184 bytes, expanded decapsulation keys of 2400 bytes, decapsulation key seeds of size 64 bytes, ciphertext size of 1088 bytes, and shared secrets of size 32 bytes” (ML-KEM-768 har innkapslingsnøkler på 1184 byte, utvidede dekapsuleringsnøkler på 2400 byte, nøkkelfrø på 64 byte, chiffertekst på 1088 byte og delte hemmeligheter på 32 byte), ifølge IETFs utkast for ML-KEM i TLS.
Ytelsesbenchmarker fra tre uavhengige kilder
Fordi ML-KEM er implementert i mange språk og på mange plattformer, finnes det ikke ett enkelt “riktig” hastighetstall. Vi har samlet resultater fra tre separate benchmarker gjort på forskjellig maskinvare og med ulik programvarestack, nettopp for å vise hvor mye metodikk påvirker resultatet. Tallene under viser tid for nøkkelgenerering, innkapsling og dekapsulering, altså de tre operasjonene som utgjør en fullstendig nøkkelutveksling.
| Kilde | Parametersett | Nøkkelgenerering | Innkapsling | Dekapsulering |
|---|---|---|---|---|
| CRYPTREC-rapport (2025) | ML-KEM-512 | 20 ms | 14 ms | 23 ms |
| CRYPTREC-rapport (2025) | ML-KEM-768 | 31 ms | 20 ms | 32 ms |
| CRYPTREC-rapport (2025) | ML-KEM-1024 | 47 ms | 28 ms | 43 ms |
| Python-implementasjon, Intel i7-9750H | ML-KEM-768 | 3,31 ms | 4,48 ms | 6,14 ms |
| Akademisk ARM-benchmark (2026) | ML-KEM-512 | 9,94 ms | 11,79 ms | 14,53 ms |
Den akademiske ARM-benchmarken fra 2026 målte også komplett nøkkelutveksling (alle tre operasjoner samlet, inkludert overhead på testplattformen) og fant 36,3 ms for ML-KEM-512, 56,6 ms for ML-KEM-768 og 85,7 ms for ML-KEM-1024. Det gir et klart mønster: hver økning i sikkerhetsnivå koster mellom 50 og 60 prosent mer regnetid, uavhengig av hvilken plattform man måler på. Forskjellen mellom CRYPTREC-tallene (målt i hele millisekunder) og Python-implementasjonen på Intel i7-brikken (under 10 ms for samme operasjon) illustrerer også hvor mye selve implementasjonen og prosessorarkitekturen påvirker resultatet. En nativ, optimalisert implementasjon på moderne x86- eller ARM-maskinvare kjører disse operasjonene på mikrosekunder, ikke millisekunder, mens en ren Python-referanseimplementasjon uten maskinvareakselerasjon kan bruke over 30 sekunder på tusen runder.
Konklusjonen fra alle tre kildene peker samme vei: den relative kostnadsøkningen fra 512 til 768 til 1024 er konsistent, selv om de absolutte tallene varierer sterkt med maskinvare og implementasjon. Det betyr at man trygt kan bruke forholdstallene (omtrent 1,5x per nivå) som tommelfingerregel, selv om man ikke kjenner de eksakte millisekundtallene for sin egen serverpark.
Sidekanalangrep: Hastighet er ikke det eneste som teller
Millisekundtallene over forteller bare halve historien om hvor “trygg” en implementasjon faktisk er. Selv om selve matematikken bak ML-KEM regnes som solid, har flere forskningsmiljøer i 2024 og 2025 publisert sidekanalangrep mot konkrete implementasjoner, altså angrep som utnytter informasjon som lekker gjennom strømforbruk, timing eller cache-oppførsel under utregningen, ikke svakheter i selve algoritmen. Dette gjelder alle tre parametersettene likt, siden de deler samme underliggende struktur og bare skiller seg i dimensjonene på matrisene som brukes.
Praktisk betyr dette at valget mellom ML-KEM-512, 768 og 1024 er mindre viktig for den reelle sikkerheten enn om implementasjonen kjører i konstant tid og er beskyttet mot maskering av mellomliggende verdier. Et bibliotek som er dårlig herdet mot sidekanalangrep, kan i verste fall gjøre selv ML-KEM-1024 sårbart for et lokalt angrep, mens en godt herdet implementasjon av ML-KEM-512 kan være fullt ut forsvarlig for de fleste trusselmodeller. Dette er også en av grunnene til at NIST og bransjen generelt anbefaler å bruke etablerte, mye reviderte biblioteker som liboqs, BoringSSL eller OpenSSLs innebygde PQC-støtte, fremfor å skrive egne implementasjoner av gitterregningen fra bunnen av.
For utviklere som vurderer parametersett spesifikt med tanke på maskinvare med begrenset fysisk sikring, som smartkort eller innebygde enheter som en angriper kan få fysisk tilgang til, er det verdt å vite at større parametersett generelt krever flere minneoperasjoner og dermed gir et større “angrepsvindu” for strømanalyse, selv om dette ikke er en direkte lineær sammenheng. Dette er ytterligere ett argument for å velge ML-KEM-512 i strengt ressursbegrensede og fysisk eksponerte miljøer, kombinert med en implementasjon som er spesifikt herdet mot slike angrep.
Hva koster forskjellen i skyen? Båndbredde, KMS og compute
De fleste diskusjoner om ML-KEM stopper ved millisekunder og byte. Men for et selskap som håndterer TLS-håndtrykk i stor skala, er det den faktiske skyregningen som avgjør beslutningen. Vi har regnet ut kostnaden ved å kombinere byte-tallene fra FIPS 203 med AWS sine offentlig publiserte priser for datatrafikk, Lambda-kompilering og KMS-forespørsler. Dette er redaksjonens egne beregninger basert på AWS sine listepriser, ikke tall AWS selv har publisert som ferdig sammenligning.
| Parametersett | Ekstra data per håndtrykk | Nettverkskostnad per mrd. håndtrykk* | Beregnet compute-kostnad per mill. operasjoner** | AWS KMS per 10 000 forespørsler |
|---|---|---|---|---|
| ML-KEM-512 | 1 568 byte | 141,12 USD | ~0,08 USD | 0,15 USD (flat, uavhengig av algoritme) |
| ML-KEM-768 | 2 272 byte | 204,48 USD | ~0,12 USD | 0,15 USD (flat, uavhengig av algoritme) |
| ML-KEM-1024 | 3 136 byte | 282,24 USD | ~0,18 USD | 0,15 USD (flat, uavhengig av algoritme) |
*Beregnet med AWS’ standard pris for utgående datatrafikk på 0,09 USD per GB (første prisnivå). **Beregnet med AWS Lambda-prisen på 0,0000166667 USD per GB-sekund, basert på en 128 MB-funksjon og handshake-tidene fra den akademiske 2026-benchmarken over.
Det som overrasker mange, er hvor liten prosessorkostnaden faktisk er sammenlignet med båndbredden. Forskjellen i ren regnekraft mellom ML-KEM-512 og ML-KEM-1024 utgjør brøkdeler av en cent selv ved en million operasjoner. Båndbreddekostnaden er derimot reell når man snakker om milliarder av tilkoblinger: differansen mellom det billigste og det dyreste parametersettet er over 140 dollar per milliard håndtrykk, bare i utgående datatrafikk. For en aktør som Cloudflare, som håndterer et enormt volum av TLS-tilkoblinger daglig, er dette en av grunnene til at ML-KEM-768 har blitt bransjens praktiske standardvalg snarere enn det mer sikkerhetsmaksimerte ML-KEM-1024. AWS KMS, derimot, priser asymmetriske forespørsler likt uansett hvilket parametersett som brukes internt, så kostnadsforskjellen der er null fra kundens ståsted.
TLS 1.3-håndtrykk: Hvor mye tyngre blir tilkoblingen?
Når ML-KEM legges til et TLS 1.3-håndtrykk, skjer det som regel i en hybridkonfigurasjon sammen med en klassisk kurve som X25519, ikke som en ren erstatning. Dette er en bevisst overgangsstrategi: hvis det skulle finnes en ukjent svakhet i gittermatematikken, faller forbindelsen tilbake på den klassiske sikkerheten til X25519, og omvendt hvis en fremtidig kvantedatamaskin bryter X25519.
Den praktiske konsekvensen er at nøkkeldelen av ClientHello- og ServerHello-meldingene vokser betydelig. Med ML-KEM-768 legges det til rundt 2 272 byte kombinert offentlig nøkkel og chiffertekst over de to meldingene, sammenlignet med de 32 byte en ren X25519-utveksling krever alene. Det er over 70 ganger mer data i selve nøkkelutvekslingen, men i praksis utgjør det fortsatt bare noen få ekstra IP-pakker på de fleste nettverk, og forskjellen forsvinner i støyen for de fleste brukere med normal bredbånds- eller mobilforbindelse. For svært begrensede oppkoblinger, som satellittlenker eller IoT-enheter på LPWAN-nett, kan derimot disse ekstra byte-ene bety en reell forskjell i batteriforbruk og responstid, noe som forklarer hvorfor ML-KEM-512 fortsatt har en klar nisje i innebygde systemer.
Et viktig skille her er mellom nøkkelutveksling og autentisering. ML-KEM løser bare halve problemet: den beskytter selve nøkkeldelen av håndtrykket mot en fremtidig kvantedatamaskin som lagrer trafikk i dag for å dekryptere senere (“harvest now, decrypt later”). Sertifikatene som brukes til å autentisere serveren, bruker fortsatt som regel RSA eller ECDSA, som i seg selv er sårbare for kvanteangrep. En fullstendig kvantesikker TLS-stack krever derfor også en signaturalgoritme som ML-DSA eller SLH-DSA i tillegg til ML-KEM, noe som er et eget migreringsspørsmål utover det denne artikkelen dekker.
Hvem bruker hvilket parametersett i praksis?
Teori er én ting, men produksjonsbruk hos store aktører sier mye om hvor bransjen faktisk har landet. Her er fem konkrete, dokumenterte eksempler på hvordan ML-KEM er rullet ut i 2024–2026.
- Google Chrome / BoringSSL: Google annonserte overgangen fra den tidligere utkastversjonen X25519Kyber768Draft00 til den standardiserte gruppen X25519MLKEM768 i september 2024, og gjorde den til standard fra Chrome 131 i november 2024, ifølge Googles sikkerhetsblogg.
- Cloudflare: Dokumenterer X25519MLKEM768 som sin anbefalte hybride nøkkelutvekslingsgruppe for TLS, ifølge Cloudflares egen dokumentasjon om post-kvante kryptografi.
- OpenSSH: La til støtte for mlkem768x25519-sha256 i versjon 9.9, og gjorde det til standardalgoritme for nøkkelutveksling i OpenSSH 10.0, som ble utgitt i april 2025, ifølge OpenSSHs offisielle versjonsnotater.
- AWS KMS: Lister X25519MLKEM768 som eksempel på en hybrid post-kvante-algoritme som støttes i tjenestens dokumentasjon.
- NIST FIPS 203: Selve standardiseringen i august 2024 er i seg selv den viktigste “produksjonshendelsen”: den utløste en bølge av migreringsprosjekter i offentlig sektor og finanssektoren globalt, drevet blant annet av krav i den amerikanske Commercial National Security Algorithm Suite 2.0.
Verdt å nevne: Signal (i protokollen PQXDH) og Apple iMessage (i PQ3) har begge innført kvantesikker nøkkelutveksling basert på Kyber-familien av algoritmer. Ingen av selskapene har imidlertid offentliggjort nøyaktig hvilket standardisert ML-KEM-parametersett de bruker i dagens versjon, så disse to bør ikke tas som bekreftede eksempler på ML-KEM-768 spesifikt, i motsetning til de fem punktene over. Det mønsteret som likevel er tydelig på tvers av alle bekreftede eksempler, er at ML-KEM-768 er det parametersettet som dominerer i offentlig internett-infrastruktur i dag. Verken 512 eller 1024 har foreløpig noen tilsvarende store, navngitte produksjonseksempler i webtrafikk.
Sikkerhetsnivåer forklart: Hva betyr kategori 1, 3 og 5 i praksis?
NISTs sikkerhetskategorier er ikke en lineær skala fra “svak” til “sterk”. De er definert relativt til hvor mye regnekraft som kreves for å bryte en referansealgoritme. Kategori 1 krever minst like mye arbeid som å brute-force AES-128, kategori 3 tilsvarer AES-192, og kategori 5 tilsvarer AES-256. Siden AES-128 i seg selv regnes som praktisk talt ubrytelig med dagens og overskuelig fremtidig teknologi (også mot kvantedatamaskiner, som via Grovers algoritme bare halverer effektiv nøkkellengde), betyr det at selv ML-KEM-512 gir en enorm sikkerhetsmargin for de aller fleste bruksområder.
Dette er grunnen til at mange kryptografer argumenterer for at debatten om “hvilket nivå er sikrest” er mindre relevant enn debatten om implementasjonskvalitet, sidekanalangrep og korrekt bruk av hybridmodus. Dokumentasjonen for det åpne kildekode-biblioteket ml-kem beskriver det enkelt: “ML-KEM-512 is the parameter set for security category 1” (ML-KEM-512 er parametersettet for sikkerhetskategori 1), ifølge dokumentasjonen for Rust-biblioteket ml-kem. Det er en presis, teknisk beskrivelse uten verdivurdering, og det er nettopp slik NIST selv ønsker at valget skal tas: basert på hvilket trusselnivå organisasjonen faktisk står overfor, ikke basert på en antakelse om at høyere tall alltid er bedre.
Fordeler og ulemper ved ML-KEM-512
- Fordel: Minst nøkkelstørrelse (800 byte offentlig nøkkel), ideelt for begrenset båndbredde.
- Fordel: Raskest av de tre i alle benchmarker vi har gått gjennom.
- Fordel: Gir fortsatt sikkerhet tilsvarende AES-128, som regnes som svært solid.
- Ulempe: Har ingen store, navngitte produksjonseksempler i offentlig webtrafikk per i dag.
- Ulempe: Oppfyller ikke kravene i strengere rammeverk som CNSA 2.0 for nasjonal sikkerhetsinfrastruktur.
- Ulempe: Mindre sikkerhetsmargin for data som må beskyttes i flere tiår fremover.
Fordeler og ulemper ved ML-KEM-768
- Fordel: Bekreftet standardvalg hos Chrome, Cloudflare, OpenSSH og AWS KMS.
- Fordel: God balanse mellom ytelse og sikkerhetsmargin (AES-192-nivå).
- Fordel: Bredest støtte i biblioteker og verktøy, siden det er mest brukt i praksis.
- Ulempe: Om lag 45 prosent tregere enn ML-KEM-512 i CRYPTREC-tallene.
- Ulempe: Ikke det høyeste sikkerhetsnivået standarden tilbyr, noe enkelte samsvarskrav spesifikt utelukker.
Fordeler og ulemper ved ML-KEM-1024
- Fordel: Høyeste standardiserte sikkerhetsmargin (AES-256-nivå).
- Fordel: Foretrukket for CNSA 2.0-samsvar og data med lang levetid.
- Fordel: Gir størst sikkerhetsmargin mot fremtidige, ennå ukjente forbedringer i gitterangrep.
- Ulempe: Nesten dobbelt så mye data per håndtrykk som ML-KEM-512.
- Ulempe: Tregest i alle tre benchmarkene, opptil 85,7 ms i komplett nøkkelutveksling i 2026-benchmarken.
- Ulempe: Mangler foreløpig store, navngitte forbrukervendte produksjonseksempler tilsvarende ML-KEM-768.
Fem-pluss bruksområder: Hvilket parametersett passer hvor?
Valget avhenger nesten alltid av tre faktorer: hvor lenge dataene må forbli hemmelige, hvor mye båndbredde og regnekraft som er tilgjengelig, og hvilke samsvarskrav organisasjonen er underlagt. Under følger konkrete anbefalinger for vanlige scenarier.
- IoT-enheter og sensorer med LPWAN/satellittforbindelse: ML-KEM-512. Lavest båndbredde- og batteriforbruk, og AES-128-nivå sikkerhet er mer enn tilstrekkelig for de fleste telemetridata med kort levetid.
- Generell nettrafikk og forbruker-TLS (nettbutikker, SaaS-innlogging): ML-KEM-768. Dette er allerede standardvalget hos Chrome, Cloudflare og de fleste store CDN-er, noe som gir best kompatibilitet og mest testet kodevei.
- VPN-gatewayer og fjernaksess for bedrifter: ML-KEM-768 i hybridmodus med X25519, som følger samme mønster som OpenSSHs nye standardvalg fra versjon 10.0.
- Offentlig sektor og forsvarsrelatert infrastruktur underlagt CNSA 2.0-lignende krav: ML-KEM-1024. Her er samsvar og maksimal sikkerhetsmargin viktigere enn de ekstra millisekundene og byte-ene.
- Arkivering av data som må forbli konfidensielt i flere tiår (helsejournaler, rettsdokumenter, forskningsdata): ML-KEM-1024, nettopp fordi “harvest now, decrypt later”-risikoen er størst for langlevd data.
- Innebygde betalingsterminaler og smartkort med strenge minnebegrensninger: ML-KEM-512, der de 800 byte i offentlig nøkkel kan være forskjellen på om løsningen får plass i tilgjengelig minne i det hele tatt.
- Meldingsapper med høye personvernkrav: ML-KEM-768 eller høyere i hybridmodus, etter mønster fra det som er kjent om Signal og Apples tilnærming, selv om de eksakte parametersettene ikke er offentlig bekreftet.
Migreringsguide: Slik går du fra klassisk kryptografi til ML-KEM
Å bytte til ML-KEM er sjelden en engangsjobb der man slår av RSA og slår på post-kvante kryptografi over natten. De fleste vellykkede migreringer følger en gradvis, hybrid tilnærming. Under er en praktisk stegvis fremgangsmåte basert på hvordan Chrome, Cloudflare og OpenSSH selv gjennomførte overgangen.
- Kartlegg hvilke TLS-biblioteker, VPN-løsninger og SSH-klienter som allerede er i bruk, og sjekk versjonsnumrene deres mot støtte for ML-KEM (OpenSSL 3.2 og nyere, BoringSSL, liboqs, og OpenSSH 9.9 og nyere støtter det i dag).
- Velg parametersett basert på bruksområdet ditt, ikke basert på hva som høres “sikrest” ut. Bruk anbefalingene over som utgangspunkt.
- Aktiver hybridmodus først, ikke ren ML-KEM alene. Dette betyr at forbindelsen fortsatt faller tilbake på klassisk sikkerhet dersom noe uventet skulle svekke gittermatematikken.
- Test kompatibilitet med eldre klienter som ikke støtter de nye TLS-gruppene, og sørg for at forhandlingslogikken faller tilbake til ren X25519 eller P-256 der det er nødvendig.
- Mål faktisk håndtrykkstørrelse og latenstid i eget nettverk før og etter, siden effekten varierer mye med geografisk avstand og pakketap.
- Oppdater brannmur- og lastbalanser-konfigurasjon som eventuelt inspiserer eller filtrerer TLS-håndtrykk basert på pakkestørrelse, siden de større ML-KEM-meldingene kan trigge eksisterende størrelsesgrenser.
- Husk at ML-KEM kun løser nøkkelutvekslingen. Server- og klientsertifikater krever separat migrering til post-kvante signaturalgoritmer som ML-DSA for full kvantesikkerhet.
- Sett en konkret dato for når klassisk-only-forbindelser (uten hybrid PQC) skal fases ut, i tråd med organisasjonens samsvarskrav og eventuelle CNSA 2.0-frister.
- Overvåk feilrater og timeout-statistikk i minst to til fire uker etter utrulling, siden noen mellomliggende nettverksbokser historisk sett har hatt problemer med uvanlig store TLS-håndtrykk.
Et konkret eksempel på hvordan dette ser ut i praksis, er hvordan man aktiverer den nye standardgruppen i OpenSSH etter versjon 10.0:
# Sjekk hvilke nøkkelutvekslingsalgoritmer klienten støtter
ssh -Q kex | grep mlkem
# Tving bruk av hybrid ML-KEM-768 + X25519 eksplisitt
ssh -o KexAlgorithms=mlkem768x25519-sha256 bruker@server
# Sjekk hvilken algoritme som faktisk ble forhandlet frem
ssh -vv bruker@server 2>&1 | grep "kex algorithm"Og tilsvarende for å teste en TLS 1.3-server med OpenSSL 3.2 eller nyere, som støtter de standardiserte ML-KEM-gruppene direkte:
# List tilgjengelige grupper (krever OpenSSL 3.2+ med PQC-støtte)
openssl list -kem-algorithms
# Test håndtrykk mot en server med hybrid ML-KEM-768
openssl s_client -groups X25519MLKEM768 -connect example.com:443
# Sammenlign håndtrykkstørrelse med klassisk X25519 alene
openssl s_client -groups X25519 -connect example.com:443Kompatibilitet: Støtter operativsystemet og nettleseren din ML-KEM?
Utrullingen av ML-KEM er ujevn på tvers av plattformer, og det er verdt å sjekke egen infrastruktur før man legger en migreringsplan. På Windows-siden dokumenterer Microsoft hybrid ECDHE/ML-KEM-støtte for TLS 1.3 i Windows 11 versjon 24H2 og nyere, samt Windows Server 2025 og nyere, med gruppenavnet x25519_mlkem768 i Schannel. Funksjonaliteten er tilgjengelig via oppdatering KB5089573 for versjon 24H2 og 25H2, og KB5095091 for 26H1, men Microsoft understreker at den ikke er slått på som standard, ifølge selskapets egen dokumentasjon.
Microsoft Edge byttet fra den eldre Kyber-baserte implementasjonen til den standardiserte ML-KEM-varianten i juli 2025, sammen med støtte for det som kalles hybrid-ML-KEM key-share prediction, en optimalisering som reduserer antall tur-retur-forsendelser i håndtrykket. På browserfronten for øvrig er bildet mer usikkert: det finnes ingen offisielt bekreftet versjonsnummer for når Firefox eller Safari fikk tilsvarende støtte for X25519MLKEM768 i våre kilder, så organisasjoner som er avhengige av disse nettleserne bør teste eksplisitt i eget miljø fremfor å anta støtte basert på Chrome og Edge sin utrulling.
For utviklere på .NET-plattformen tilbyr Microsoft kryptografi-API-er for ML-KEM-512 og ML-KEM-768, dokumentert for Windows 11 Insiders. Det er imidlertid et viktig skille mellom å ha tilgang til selve ML-KEM-algoritmen som byggekloss i koden sin, og å ha en TLS-stack som automatisk forhandler X25519MLKEM768 i nettverkstrafikk. De to tingene utvikler seg ofte i ulikt tempo, og et system kan ha det ene uten det andre.
Vanlige fallgruver ved implementering
Den vanligste feilen er å forveksle ML-KEM med en fullstendig erstatning for eksisterende kryptografi, når det i realiteten kun dekker nøkkelutvekslingsdelen av forbindelsen. Team som ruller ut ML-KEM uten å samtidig planlegge for post-kvante signaturer, sitter igjen med en forbindelse der selve nøkkelen er kvantesikker, men autentiseringen fortsatt er sårbar for et fremtidig kvanteangrep mot sertifikatkjeden.
En annen vanlig fallgruve er å anta at eldre nettverksutstyr håndterer de større pakkestørrelsene uten problemer. Enkelte eldre brannmurer og TLS-terminerende lastbalansere har hardkodede antakelser om maksimal størrelse på ClientHello-meldinger, og kan i verste fall avvise eller fragmentere håndtrykk på uventede måter når ML-KEM legges til. Dette er nøyaktig den typen kompatibilitetsproblem som testfasen i migreringsguiden over er ment å fange opp før produksjonssetting.
Til slutt: mange team velger parametersett basert på hva som brukes andre steder, uten å vurdere eget trusselbilde. Å kopiere Cloudflares valg av ML-KEM-768 er som regel et fornuftig standardvalg, men det er ikke automatisk riktig for en aktør med helt andre krav til samsvar, båndbredde eller datalevetid.
Verktøy for å teste egen infrastruktur før produksjonssetting bør inngå som fast del av migreringen. Kommandolinjeverktøy som openssl s_client, testtjenester som lar deg sjekke hvilke grupper en server faktisk tilbyr, og loggeanalyse av faktisk forhandlet gruppe over tid gir et langt bedre bilde av reell utrulling enn å stole på at en konfigurasjonsendring har virket som planlagt. Mange team oppdager først i denne fasen at en eldre lastbalanser eller en mellomliggende proxy stille faller tilbake til klassisk X25519 uten å varsle om det, noe som betyr at trafikken i praksis aldri fikk den kvantesikre beskyttelsen konfigurasjonen skulle gi.
Standardvalget i praksis: Hvorfor pakkeforvaltere defaulter til 768
Det er ikke tilfeldig at så mange verktøy og biblioteker har landet på ML-KEM-768 som forvalgt innstilling. Vedlikeholderne av Python-pakken mlkem beskriver egen designbeslutning direkte: “ML-KEM-768 is used by default in this package” (ML-KEM-768 brukes som standard i denne pakken), ifølge pakkens dokumentasjon på PyPI. Dette gjenspeiler en bredere bransjekonsensus: når et bibliotek eller en tjeneste må velge én innstilling som skal fungere godt for flest mulig brukstilfeller uten at brukeren aktivt må ta stilling, faller valget nesten alltid på det midterste alternativet.
Dette mønsteret gjentar seg på tvers av økosystemet, fra nettleserleverandører til SSH-klienter til skytjenester. Det betyr i praksis at ML-KEM-768 i dag fungerer som den nye “de facto”-standarden for generell bruk, mens 512 og 1024 forblir spesialiserte valg for henholdsvis ressursbegrensede og høysikkerhetsscenarier. For utviklere som ikke har et spesifikt behov som peker mot ytterpunktene, er det sjelden en dårlig idé å følge flertallet.
Hva skjer etter ML-KEM? Veien videre for post-kvante-kryptografi
ML-KEM løser problemet med nøkkelutveksling, men det er bare én brikke i et større puslespill. NIST har allerede standardisert tilhørende signaturalgoritmer: ML-DSA (tidligere Dilithium) for generell bruk, og SLH-DSA (tidligere SPHINCS+) som et hasjbasert alternativ med en annen sikkerhetsprofil dersom det skulle dukke opp uventede svakheter i gitterbaserte konstruksjoner. Falcon er ventet standardisert under navnet FN-DSA og tilbyr betydelig mindre signaturer enn ML-DSA, på bekostning av en mer komplisert implementasjon. Sammen utgjør disse fire algoritmene grunnmuren i det NIST kaller den post-kvante kryptografiske verktøykassen.
NIST har også en pågående fjerde runde med kandidater for nøkkelinnkapsling utover ML-KEM, deriblant HQC, som ble valgt som en reserve basert på et annet matematisk problem enn gitter, i tilfelle det skulle bli funnet et gjennombrudd i gitterbasert kryptoanalyse. Dette er samme forsiktighetsprinsipp som ligger bak hybridmodus i TLS: man ønsker ikke å ha alle sikkerhetsegg i én matematisk kurv, spesielt når feltet fortsatt er relativt ungt sammenlignet med RSA og elliptisk kurve-kryptografi, som har blitt gjennomlyst av kryptografer i flere tiår.
For organisasjoner som allerede har migrert nøkkelutvekslingen til ML-KEM, er det naturlige neste skrittet å begynne planleggingen for signaturmigrering, samt å holde et øye med hvordan CNSA 2.0-tidslinjen og tilsvarende krav i EU og andre jurisdiksjoner utvikler seg fremover mot slutten av tiåret. Kryptografisk smidighet, altså evnen til å bytte algoritme uten å bygge om hele systemarkitekturen, kommer trolig til å bli minst like viktig som selve algoritmevalget i årene som følger.
Dommen: Hvilket parametersett vinner?
Tallene peker mot ett tydelig svar for de fleste: ML-KEM-768. Det er det eneste parametersettet med bekreftet, navngitt produksjonsbruk hos fire uavhengige store aktører (Chrome, Cloudflare, OpenSSH og AWS KMS), det treffer et sikkerhetsnivå (AES-192-ekvivalent) som er mer enn tilstrekkelig for nesten all sivil og kommersiell bruk, og kostnadsøkningen sammenlignet med ML-KEM-512 er beskjeden: rundt 45 prosent tregere i CRYPTREC-tallene og drøyt 700 byte mer per håndtrykk, noe som utgjør under en tidels cent selv ved millioner av operasjoner i skyen.
ML-KEM-512 vinner der båndbredde og batteri er den trange flaskehalsen, typisk i IoT og innebygde systemer med LPWAN-tilkobling. ML-KEM-1024 vinner der samsvarskrav som CNSA 2.0 eller data med flere tiårs levetid gjør at den ekstra sikkerhetsmarginen er ikke-forhandlingsbar, uavhengig av kostnad. For alt annet, altså det store flertallet av nettrafikk, VPN-forbindelser og API-kall, er ML-KEM-768 riktig standardvalg akkurat nå, og det er også der bransjens tyngste aktører allerede har landet.
Det som gjør dette til en relativt uvanlig sammenligning i kryptografiverdenen, er at alle tre “vinner” avhengig av kontekst, i motsetning til rene algoritme-mot-algoritme-sammenligninger der den ene som regel er strengt bedre enn den andre på de fleste mål. Her handler valget om å kjenne eget system godt nok til å vite hvilken av de tre variablene, båndbredde, regnekraft eller sikkerhetsmargin, som faktisk er den begrensende faktoren. For de aller fleste norske og nordiske virksomheter som nå begynner å planlegge egen post-kvante-migrering, er svaret i ni av ti tilfeller det samme: start med ML-KEM-768 i hybridmodus, og avvik bare fra det når en konkret og dokumentert grunn tilsier det.
Ofte stilte spørsmål om ML-KEM-512, 768 og 1024
Er ML-KEM det samme som Kyber?
Ja, i praksis. ML-KEM er den offisielle, standardiserte etterfølgeren til CRYSTALS-Kyber etter at NIST finaliserte FIPS 203 i august 2024. Tidlige implementasjoner som brukte navnet “Kyber768Draft00” er ikke nødvendigvis byte-for-byte kompatible med den ferdige ML-KEM-standarden, så eldre Kyber-basert kode bør oppdateres, ikke bare gis nytt navn.
Kan jeg bruke ML-KEM alene uten en klassisk algoritme?
Teknisk sett ja, men de fleste produksjonsmiljøer, inkludert Chrome, Cloudflare og OpenSSH, kjører ML-KEM i hybridmodus sammen med X25519 eller en annen klassisk kurve. Dette gir et sikkerhetsnett dersom det skulle dukke opp svakheter i den relativt unge gitterbaserte matematikken.
Hvorfor er ML-KEM-1024 ikke standardvalget hvis det er sikrest?
Fordi “sikrest” ikke er det samme som “riktigst” for de fleste bruksområder. ML-KEM-768 gir allerede en sikkerhetsmargin tilsvarende AES-192, som regnes som svært solid, mens ML-KEM-1024 legger til betydelig mer båndbredde- og regnekostnad for en sikkerhetsøkning de fleste organisasjoner ikke trenger.
Påvirker ML-KEM ytelsen til vanlige nettsider merkbart?
For de aller fleste brukere med normal bredbånds- eller mobiltilkobling, nei. De ekstra byte-ene i håndtrykket utgjør typisk mindre enn én ekstra nettverkspakke, og forskjellen er ikke merkbar sammenlignet med annen nettverkslatens. Effekten blir tydeligere på svært trege eller ustabile forbindelser.
Beskytter ML-KEM meg mot at noen leser TLS-trafikken min i dag?
ML-KEM beskytter primært mot fremtidige kvantedatamaskiner som kan dekryptere trafikk som lagres i dag (“harvest now, decrypt later”). Mot dagens klassiske angrep gir det ingen ekstra beskyttelse utover det X25519 eller RSA allerede gir, siden begge fortsatt anses som sikre mot klassiske angrep.
Må jeg også bytte signaturalgoritme, eller er ML-KEM nok?
ML-KEM dekker kun nøkkelutvekslingen. Sertifikater og digitale signaturer krever egne post-kvante-algoritmer som ML-DSA eller SLH-DSA for full kvantesikkerhet i hele forbindelsen, ikke bare i selve nøkkeldelen.
Hvilke biblioteker støtter ML-KEM i dag?
OpenSSL 3.2 og nyere, BoringSSL (brukt av Chrome), liboqs, og programmeringsspråk-spesifikke pakker som ml-kem for Rust og mlkem for Python støtter alle standarden. OpenSSH har hatt støtte siden versjon 9.9, med ML-KEM-768-hybrid som standard fra versjon 10.0.
Er det trygt å bruke ML-KEM-512 for en vanlig nettbutikk?
Sikkerhetsmessig, ja, AES-128-ekvivalent sikkerhet regnes som svært solid. Men siden ML-KEM-768 allerede er bredt utbredt og testet i de store nettleserne og CDN-ene, er det som regel enklere og tryggere å følge bransjestandarden fremfor å optimalisere for de få ekstra byte-ene ML-KEM-512 sparer.
Kan jeg bytte parametersett senere uten å bygge om alt?
Ja, forutsatt at systemet er bygget med kryptografisk smidighet i tankene, altså at algoritme og parametersett er konfigurerbare verdier og ikke hardkodet inn i protokollogikken. De fleste moderne TLS-biblioteker, inkludert OpenSSL og BoringSSL, lar deg bytte hvilken gruppe som forhandles frem uten kodeendringer, kun konfigurasjonsendringer. Det er nettopp derfor hybrid-tilnærmingen med flere støttede grupper samtidig er så mye tryggere enn å hardkode ett enkelt valg permanent.
Hvorfor bruker ikke alle bare det sikreste alternativet uansett kostnad?
Fordi kostnaden ved høyere sikkerhetsnivå ikke bare er økonomisk, den er også operasjonell. Større håndtrykk øker risikoen for kompatibilitetsproblemer med eldre nettverksutstyr, øker latens for brukere på trege forbindelser, og legger mer press på servere som håndterer millioner av samtidige tilkoblinger. For de fleste trusselmodeller gir ML-KEM-768 allerede en sikkerhetsmargin som er mer enn tilstrekkelig, og da er den ekstra kostnaden ved ML-KEM-1024 en dårlig avveining sammenlignet med nytten.
