Norge og resten av Norden går inn i migreringsfasen for post-kvante kryptografi, og de fleste tekniske team har allerede hørt om ML-KEM, algoritmen NIST valgte som FIPS 203-standard. Færre kjenner til FrodoKEM, en konkurrent fra samme NIST-prosess som Tysklands BSI fortsatt anbefaler som et konservativt tilleggslag. De to løser samme oppgave, nøkkelutveksling som skal tåle en fremtidig kvantedatamaskin, men de bygger på helt ulike matematiske antakelser. Denne artikkelen går gjennom nøkkelstørrelser, ytelsestall, båndbreddekostnad og reelle driftssettinger, slik at du kan velge riktig verktøy for din arkitektur i 2026.
Kvantetrusselen og hvorfor valget haster nå
Grunnen til at norske sikkerhetsteam i det hele tatt diskuterer FrodoKEM og ML-KEM i 2026 handler om et konsept kjent som “harvest now, decrypt later”. En angriper trenger ikke en fungerende kvantedatamaskin i dag for å true dataene dine. Det holder at noen lagrer kryptert trafikk nå, og dekrypterer den så snart en kryptografisk relevant kvantedatamaskin finnes, kanskje om ti eller femten år. For data som må forbli hemmelig lenge, bankoppgjør, forsvarskommunikasjon, pasientjournaler, medisinsk forskning, er den trusselen reell allerede i dag, selv om selve maskinen ikke er bygget ennå.
Det gjør nøkkelutveksling til det mest tidskritiske elementet i hele post-kvante-migreringen. En angriper som avlytter og lagrer dagens TLS-trafikk, trenger kun å knekke nøkkelutvekslingsalgoritmen, ikke selve krypteringen, for å få tilgang til innholdet i ettertid. Det er derfor ML-KEM og FrodoKEM, ikke symmetrisk kryptering som AES, står øverst på de fleste migreringsplaner akkurat nå.
Det er bakgrunnen for at NIST startet sin post-kvante-konkurranse i 2016, kåret Kyber som vinner i 2022, og publiserte den endelige standarden FIPS 203 i august 2024. ML-KEM og FrodoKEM representerer to ulike svar på samme spørsmål: hvordan bytter to parter en hemmelig nøkkel over et usikret nettverk, på en måte som holder selv mot en angriper med en kvantedatamaskin til rådighet. Begge er såkalte nøkkelinnkapslingsmekanismer (KEM), en moderne erstatning for den klassiske Diffie-Hellman-nøkkelutvekslingen som RSA og elliptisk kurve-kryptografi har brukt i tiår. Forskjellen mellom dem ligger ikke i hva de skal gjøre, men i hvordan de matematisk sett løser det.
Hva er ML-KEM og FrodoKEM?
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) er den offisielle etterfølgeren til Kyber, algoritmen som vant NIST sin post-kvante-konkurranse i 2022. Siden august 2024 er den standardisert som FIPS 203, med tre parametersett: ML-KEM-512, ML-KEM-768 og ML-KEM-1024. Den bygger på Module Learning With Errors (Module-LWE), et problem hentet fra strukturerte gitter representert som polynomringer. Strukturen gjør nøklene kompakte og regneoperasjonene raske, noe som er hovedgrunnen til at NIST valgte den som hovedstandard.
I praksis betyr dette at ML-KEM kan settes rett inn i eksisterende protokoller uten å endre hvordan de er bygget opp. TLS 1.3, IKEv2 og SSH forventer alle at en nøkkelutveksling tar et par kilobyte og et par titalls mikrosekunder, og ML-KEM passer rett inn i det mønsteret klassisk Diffie-Hellman og elliptisk kurve-kryptografi allerede har satt. Det er en viktig grunn til at utrullingen har gått så raskt de siste to årene, sammenlignet med andre post-kvante-kandidater som krever større endringer i protokollenes grunnstruktur.
FrodoKEM tar en annen vei. Den bygger på ren, ustrukturert Learning With Errors (LWE), og bruker store matriser i stedet for kompakte polynomer. Det gjør den langt tregere og langt mer plasskrevende, men det fjerner også den algebraiske strukturen som i teorien kan gjøre strukturerte gitterproblemer sårbare for fremtidige angrep man ennå ikke kjenner til. FrodoKEM var finalist i NIST sin prosess, men ble ikke valgt til den endelige standarden. Den lever videre som en anerkjent, konservativ reserveløsning dokumentert på det offisielle FrodoKEM-prosjektets nettside, og er under standardisering hos ISO. For lesere som vil se hvordan ML-KEMs egne parametersett står mot hverandre, har vi tidligere dekket ML-KEM-512 vs 768 vs 1024 i detalj.
Nøkkelstørrelser og spesifikasjoner: tallene side om side
Den klareste forskjellen mellom de to familiene handler ikke om sikkerhetsnivå, men om hvor mye data som må sendes for å etablere en delt hemmelighet. Open Quantum Safe sitt liboqs-prosjekt dokumenterer de eksakte byte-tallene for begge algoritmefamiliene, og NIST har publisert tilsvarende tall i sitt arbeidsmøtemateriale om post-kvante-migrering. Tabellen under viser alle seks FrodoKEM-varianter (AES og SHAKE har identisk størrelse, bare ulik intern tilfeldighetsgenerator) sammen med ML-KEMs tre nivåer og en klassisk X25519-referanse.
| Skjema | NIST-sikkerhetsnivå | Offentlig nøkkel | Hemmelig nøkkel | Chiffertekst | Delt hemmelighet |
|---|---|---|---|---|---|
| ML-KEM-512 | 1 | 800 B | 1 632 B | 768 B | 32 B |
| ML-KEM-768 | 3 | 1 184 B | 2 400 B | 1 088 B | 32 B |
| ML-KEM-1024 | 5 | 1 568 B | 3 168 B | 1 568 B | 32 B |
| FrodoKEM-640-AES | 1 | 9 616 B | 19 888 B | 9 752 B | 16 B |
| FrodoKEM-640-SHAKE | 1 | 9 616 B | 19 888 B | 9 752 B | 16 B |
| FrodoKEM-976-AES | 3 | 15 632 B | 31 296 B | 15 792 B | 24 B |
| FrodoKEM-976-SHAKE | 3 | 15 632 B | 31 296 B | 15 792 B | 24 B |
| FrodoKEM-1344-AES | 5 | 21 520 B | 43 088 B | 21 696 B | 32 B |
| FrodoKEM-1344-SHAKE | 5 | 21 520 B | 43 088 B | 21 696 B | 32 B |
| X25519 (klassisk referanse) | Ikke kvantesikker | 32 B | 32 B | 32 B | 32 B |
Legg merke til at ML-KEM-1024, det høyeste sikkerhetsnivået i ML-KEM-familien, fortsatt har en offentlig nøkkel på bare 1 568 byte. FrodoKEM-640, det laveste sikkerhetsnivået i Frodo-familien, krever 9 616 byte for samme komponent. Det er over seks ganger mer data for et lavere sikkerhetsnivå enn ML-KEMs toppnivå. Dette mønsteret gjentar seg konsekvent gjennom hele tabellen, og det er den enkeltstående faktoren som i praksis avgjør hvor de to algoritmene kan brukes.
Den hemmelige nøkkelen forteller samme historie enda tydeligere. ML-KEM-1024 lagrer 3 168 byte lokalt. FrodoKEM-1344 lagrer 43 088 byte, over tretten ganger mer, for samme formål. For en enkelt server er ikke dette noe problem i seg selv, lagringsplass er billig. Problemet oppstår når nøklene skal genereres og håndteres i stor skala, for eksempel i en tjeneste som roterer nøkler ofte av sikkerhetshensyn, eller i en innebygd enhet med begrenset minne. Der blir FrodoKEMs fotavtrykk en reell designbegrensning, ikke bare et tall i en tabell.
Sikkerhetsgrunnlag: strukturerte mot ustrukturerte gitter
Module-LWE forklart enkelt
ML-KEM representerer nøkler og chiffertekster som polynomer i en ring, og lener seg på strukturen i modulgitter for å holde beregningene raske. Denne strukturen er grundig analysert av det kryptografiske forskningsmiljøet, og ingen praktisk klassisk eller kvantemekanisk angrep er kjent. Likevel innfører strukturen en algebraisk form som i prinsippet gir angripere mer å jobbe med enn et helt tilfeldig problem ville gjort. BSI beskriver denne avveiningen presist i sin tekniske retningslinje TR-02102-1: ML-KEM er effektiv nettopp fordi den bruker struktur, men strukturen er samtidig den teoretiske bekymringen enkelte kryptografer peker på.
Ren LWE og hvorfor FrodoKEM er tregere
FrodoKEM dropper polynomstrukturen helt og regner direkte på store matriser over et modulus. Det gir et problem som er nærmere det opprinnelige LWE-problemet slik det ble formulert av Oded Regev i 2005, uten ekstra algebraisk struktur å utnytte. BSI omtaler FrodoKEM som den mer konservative metoden nettopp av denne grunnen. Prisen er regnekraft: matriseoperasjoner skalerer dårligere enn polynomoperasjoner, og det er hovedårsaken til at FrodoKEM er betydelig tregere enn ML-KEM på alle sikkerhetsnivåer. Ingen av algoritmene regnes som brutt i dag. Forskjellen handler om hvor mye uforutsett algebraisk struktur man er villig til å stole på over de neste tiårene.
AES- eller SHAKE-varianten: hvilken bør du velge?
Innenfor FrodoKEM-familien finnes et eget valg som ikke påvirker sikkerheten, men som påvirker ytelsen på konkret maskinvare. FrodoKEM-640, 976 og 1344 kommer hver i en AES-variant og en SHAKE-variant, med nøyaktig samme offentlig nøkkel-, hemmelig nøkkel- og chiffertekststørrelse i begge tilfeller. Forskjellen ligger i hvilken funksjon som genererer den pseudotilfeldige matrisen internt. AES-varianten bruker AES i tellermodus, og drar full nytte av AES-NI-instruksjoner på moderne Intel- og AMD-prosessorer. SHAKE-varianten bruker Keccak-baserte SHAKE128 eller SHAKE256, og kan være raskere på plattformer uten AES-maskinvareakselerasjon, eller der SHA-3-familien allerede er optimalisert i annen kode. For de fleste x86-64-servere med moderne prosessorer vil AES-varianten normalt ha et lite fortrinn, men forskjellen er liten sammenlignet med gapet opp mot ML-KEM.
Ytelse i praksis: hvor mye tregere er FrodoKEM?
Eksakte operasjoner-per-sekund-tall varierer med prosessor, kompilator og om AVX2-instruksjoner er aktivert, så vi presenterer tallene som størrelsesordener fremfor absolutte konstanter. Dette er også hvordan Open Quantum Safe selv anbefaler at liboqs-tallene leses. Tre uavhengige kilder peker i samme retning: benchmark-rammeverket i liboqs, NIST sitt arbeidsmøtemateriale om post-kvante-migrering, og IETFs pågående utkast for TLS-hybridgrupper.
| Operasjon eller mål | ML-KEM | FrodoKEM | Kilde |
|---|---|---|---|
| Nøkkelgenerering (moderne x86-64) | Ca. 10–60 µs | Ca. 0,5–8 ms | Open Quantum Safe (liboqs) benchmark-rammeverk |
| Enkapsulering | Ca. 10–60 µs | Ca. 0,5–8 ms | Open Quantum Safe (liboqs) benchmark-rammeverk |
| Dekapsulering | Ca. 10–60 µs | Ca. 0,5–8 ms | Open Quantum Safe (liboqs) benchmark-rammeverk |
| Offentlig nøkkel + chiffertekst, nivå 1 | 1 568 B | 19 336 B | NIST PQC-arbeidsmøtemateriale |
| Offentlig nøkkel + chiffertekst, nivå 3 | 2 272 B | 31 376 B | NIST PQC-arbeidsmøtemateriale |
| Standardisert TLS 1.3-hybridgruppe | X25519MLKEM768 | Ingen standardisert gruppe | IETF TLS-arbeidsgruppens utkast |
Konklusjonen holder uansett hvilken konkret CPU man tester på: FrodoKEM går fra mikrosekunder til millisekunder, altså et sted mellom to og tre størrelsesordener tregere enn ML-KEM. For et enkelt TLS-håndtrykk merker en bruker ingenting. For en lastbalanserer som håndterer titusenvis av nye tilkoblinger i sekundet, er forskjellen mellom mikrosekunder og millisekunder nok til å kreve helt andre kapasitetsplaner.
Tenk på det i praktiske termer. En tjeneste som i dag håndterer 50 000 nye TLS-tilkoblinger i sekundet med klassisk ECDHE, kan bytte til ML-KEM-768 uten å endre kapasitetsplanen nevneverdig, siden operasjonene fortsatt tar titalls mikrosekunder. Samme tjeneste med FrodoKEM-976 ville trengt vesentlig mer CPU-kapasitet bare for å holde tritt med nøkkelutvekslingen, fordi hver operasjon flytter seg fra mikrosekund- til millisekund-skala. Det er grunnen til at Open Quantum Safe konsekvent anbefaler at team som evaluerer FrodoKEM, kjører egne benchmarks på sin faktiske maskinvare før de tar en beslutning, i stedet for å stole på generelle tall fra andres testmiljø.
Båndbredde og overhead: hva betyr dette for TLS og VPN?
Kombinasjonen av offentlig nøkkel og chiffertekst er det som faktisk reiser over nettverket i et KEM-basert håndtrykk. Her blir forskjellen enda tydeligere enn i enkeltfeltene, fordi overheaden legges oppå hverandre på begge sider av forbindelsen.
| Sikkerhetsnivå | ML-KEM (PK + CT) | FrodoKEM (PK + CT) | FrodoKEM-overhead |
|---|---|---|---|
| Nivå 1 (512 / 640) | 1 568 B | 19 336 B | Ca. 12,3x |
| Nivå 3 (768 / 976) | 2 272 B | 31 376 B | Ca. 13,8x |
| Nivå 5 (1024 / 1344) | 3 136 B | 43 152 B | Ca. 13,8x |
For et vanlig TLS-oppsett er ML-KEMs tillegg på 1,6 til 3,1 kB stort sett et ikke-tema, det får plass i et enkelt nettverkspakke uten fragmentering. FrodoKEMs 19 til 43 kB er en helt annen sak. Det presser QUIC sine amplifikasjonsgrenser, det øker risikoen for IP-fragmentering over UDP, og det kan sprenge kontrollplan-budsjettet i VPN-tunneler designet for korte håndtrykk. Mobile nett og IoT-enheter med trange datapakker merker dette raskest. Det er hovedgrunnen til at IETFs TLS-arbeidsgruppe i 2026 har bygget hybridgruppene sine rundt ML-KEM, med navn som X25519MLKEM768, SecP256r1MLKEM768 og SecP384r1MLKEM1024, uten tilsvarende FrodoKEM-grupper i samme utkast.
Et konkret eksempel fra et september 2026-utkast i IETF illustrerer hvor smalt marginene er for et vanlig TLS-håndtrykk. Et foreslått MLKEM512X25519-nøkkelpar sender rundt 832 byte fra klienten og 800 byte fra serveren, altså godt under grensen for ett enkelt IP-pakke på de fleste nett. Flytter man samme regnestykke til FrodoKEM-640, havner man fort over flere pakkers størrelse i begge retninger, noe som kan trigge TCP-fragmentering eller tvinge QUIC til å vente på flere pakkebekreftelser før håndtrykket er ferdig. For tjenester med strenge krav til lav forsinkelse, som sanntidsbank, handelsplattformer eller VoIP, er det en reell brukeropplevelse-kostnad, ikke bare et teoretisk tall.
Hva koster overheaden i skyen?
Byte-overhead blir fort abstrakt, så la oss sette et tall på det. Beregningen under er illustrativ: den bruker de dokumenterte byte-forskjellene fra tabellene over, multiplisert med offentlig publiserte utgående datapriser fra tre skyleverandører. Den representerer ikke faktisk fakturering for TLS-håndtrykk hos noen av leverandørene, men viser størrelsesordenen på kostnaden når man multipliserer en liten overhead per tilkobling med millioner av tilkoblinger. AWS S3 fakturerer utgående internettrafikk fra 0,09 dollar per GB for de første 10 TB i måneden. Google Cloud sitt Premium Tier ligger typisk rundt 0,12 dollar per GB. Cloudflare R2 reklamerer med 0 dollar per GB i utgående trafikk.
| Sikkerhetsnivå | Ekstra data per håndtrykk | Kostnad per million håndtrykk (AWS, $0,09/GB) | Kostnad per million håndtrykk (GCP Premium, $0,12/GB) | Kostnad per million håndtrykk (Cloudflare R2, $0/GB) |
|---|---|---|---|---|
| Nivå 1 | 17 768 B | Ca. $1,60 | Ca. $2,13 | $0 |
| Nivå 3 | 29 104 B | Ca. $2,62 | Ca. $3,49 | $0 |
| Nivå 5 | 40 016 B | Ca. $3,60 | Ca. $4,80 | $0 |
Beløpene ser små ut isolert sett, men de er bare bandbredde-siden av regnestykket. Legg til at FrodoKEM også krever mer CPU-tid per operasjon, og summen blir en reell driftskostnad for enhver tjeneste som håndterer høyt volum av nye tilkoblinger. Dette er en av de konkrete grunnene til at ingen store skyleverandører eller nettlesere har satt FrodoKEM i produksjon som standardvalg, mens ML-KEM allerede ruller ut i stor skala.
Regn gjennom et konkret eksempel. En tjeneste på én million daglige aktive brukere, der hver bruker i snitt etablerer tre nye TLS-sesjoner i døgnet, genererer rundt tre millioner håndtrykk daglig. Med ML-KEM-768 utgjør den ekstra kryptografiske overheaden en størrelsesorden som knapt er målbar i den månedlige skyregningen. Med FrodoKEM-976 begynner den samme overheaden, multiplisert opp mot tre millioner daglige håndtrykk og trettifem dager i måneden, å bli en budsjettpost en infrastrukturansvarlig faktisk må regne på, selv før man legger til den ekstra CPU-tiden. Det er denne typen regnestykke som i praksis avgjør hvorfor høyvolum-tjenester lander på ML-KEM, uavhengig av hvor konservativt FrodoKEMs sikkerhetsgrunnlag er.
NIST-standardisering: hvorfor FIPS 203 ble ML-KEM
NIST publiserte FIPS 203 i august 2024 med ML-KEM som den standardiserte mekanismen for nøkkelinnkapsling, etter en flerårig konkurranseprosess der FrodoKEM var en av finalistene. Valget falt ikke på sikkerhet alene, begge algoritmene regnes som solide, men på effektivitet. BSI oppsummerer NIST sin begrunnelse presist: ML-KEM ble valgt fordi den er vesentlig mer effektiv, ikke fordi FrodoKEM har en kjent svakhet. FrodoKEM forblir relevant som en anerkjent reservedesign, og er under egen standardisering hos ISO parallelt med NIST-prosessen.
Tidslinjen er verdt å ha klar for seg. NIST åpnet konkurransen i 2016 og tok imot over 80 forslag fra forskningsmiljøer verden over. I 2022 kåret NIST Kyber til vinner i KEM-kategorien, sammen med tre signaturalgoritmer. Den endelige standarden tok ytterligere to år å ferdigstille, med navneendringen fra Kyber til ML-KEM underveis for å signalisere at algoritmen nå var låst til en offisiell spesifikasjon. FrodoKEM og tre andre kandidater (BIKE, Classic McEliece og HQC) ble stående som fjerde runde-kandidater, en gruppe NIST fortsatt evaluerer for eventuelle fremtidige, supplerende standarder. Lesere som vil se hvordan en av disse alternative kandidatene står mot ML-KEM finner mer i vår artikkel om ML-KEM mot HQC.
Det er en viktig presisering her: Kyber, forgjengeren til ML-KEM, ble brukt i tidlige produksjonsutrullinger før FIPS 203 var ferdig. Cloudflare kjørte for eksempel X25519Kyber768Draft00 fra september 2023, lenge før den endelige standarden forelå. Å kalle enhver tidlig Kyber-utrulling for en “ML-KEM-utrulling” uten forbehold er teknisk unøyaktig, selv om de to er nært beslektede. Lesere som vil se hvordan de tre ML-KEM-parametersettene presterer mot hverandre finner detaljene i vår egen gjennomgang av ML-KEM-512 mot 768 mot 1024.
BSI og europeiske anbefalinger: den konservative reserveløsningen
Tysklands føderale IT-sikkerhetsmyndighet BSI publiserer den tekniske retningslinjen TR-02102-1, som beskriver FrodoKEM som en LWE-basert metode med ustrukturerte gitter, og som en mer konservativ tilnærming enn ML-KEM. Det er verdt å presisere nøyaktig hva det betyr i praksis: BSI pålegger ikke FrodoKEM som erstatning for ML-KEM. Myndigheten anerkjenner FrodoKEM som et egnet tilleggsvalg, særlig for langtidskonfidensialitet der båndbredde og regnekraft er mindre kritisk enn den teoretiske sikkerhetsmarginen.
En praktisk lesning av BSI sin posisjon ser slik ut: ML-KEM er førstevalget for interoperabel, effektiv drift. FrodoKEM passer som en konservativ reserve eller et forsvar-i-dybden-lag der båndbredde og regnekostnad kan aksepteres. Under migrering anbefales dessuten hybriddrift, der et post-kvante-skjema kombineres med en klassisk mekanisme som X25519 eller P-256, nettopp for at svikt i én antakelse ikke alene skal bryte sikkerheten. Norske og nordiske virksomheter som følger NIS2-kravene bør merke seg denne anbefalingen når de planlegger kryptoagile arkitekturer fremover.
Dette har også en sikkerhetspolitisk side. Både BSI og tilsvarende organer i andre europeiske land har pekt på fordelen av å ikke stå med bare én matematisk antakelse som fundament for hele det digitale tillitsnettet i flere tiår fremover. Skulle det en dag dukke opp et uventet angrep mot strukturerte gitterproblemer, enten klassisk eller kvantebasert, gir et FrodoKEM-lag ved siden av ML-KEM en reell fallback som ikke deler samme sårbarhet. For norske myndigheter og kritisk infrastruktur, som kraftsektoren og finansnæringen, er dette resonnementet en del av den bredere diskusjonen om digital suverenitet og uavhengighet fra enkeltleverandørers kryptografiske valg.
Virkelige implementasjoner: hvem bruker hva i 2026
Forskjellen i produksjonsmodenhet mellom de to algoritmene er like stor som forskjellen i nøkkelstørrelse. ML-KEM og dens forgjenger Kyber har flere navngitte, dokumenterte utrullinger, og listen har vokst jevnt gjennom 2025 og inn i 2026 etter hvert som FIPS 203 har modnet fra en fersk standard til et etablert krav i offentlige anbudsprosesser og interne sikkerhetspolicyer hos store teknologiselskaper:
- Cloudflare kjørte hybrid post-kvante nøkkelutveksling med X25519Kyber768Draft00 fra september 2023, og har siden migrert mot den standardiserte gruppen X25519MLKEM768 på kantnettverket sitt.
- AWS kunngjorde 7. april 2025 at Key Management Service, Certificate Manager og Secrets Manager støtter ML-KEM-basert post-kvante TLS, med planlagt uttak av det eldre Kyber-navnet fra tjenesteendepunktene i løpet av 2026.
- Chrome og andre Chromium-baserte nettlesere forhandler hybrid post-kvante nøkkelutveksling som standard mot servere som støtter det, via en hybridgruppe basert på X25519 og ML-KEM/Kyber.
- Signal bruker PQXDH, en Kyber-basert utvidelse av Signal-protokollens nøkkelavtale, kunngjort 19. september 2023, som et konkret forsvar mot “høst nå, dekrypter senere”-angrep.
- Apples PQ3-protokoll for iMessage kombinerer klassisk og Kyber-basert nøkkeletablering i meldingsprotokollen.
- Ifølge Cloudflares egen post-kvante-rapport hadde Google aktivert post-kvante-beskyttelse på de fleste av sine servere allerede i 2023, med unntak av Google Cloud Platform.
FrodoKEM mangler et tilsvarende register av navngitte produksjonsutrullinger. Den finnes i Open Quantum Safes liboqs-bibliotek, i forsknings- og sammenligningsarbeid, og i enkelte høy-sikkerhetsevalueringer knyttet til standardiseringsprosesser. Ingen større nettleser, skytjeneste eller meldingsapp har satt den som standardvalg. Skal man bruke FrodoKEM i dag, må begge parter eksplisitt konfigurere det, det forhandles ikke automatisk slik ML-KEM i økende grad gjør.
Det er verdt å dvele litt ved hva denne forskjellen faktisk betyr for en norsk IT-avdeling. Når Chrome, Cloudflare og AWS alle har satt ML-KEM i produksjon, betyr det at en vanlig webtjeneste kan få post-kvante-beskyttelse nesten gratis, bare ved å holde TLS-stakken oppdatert og la klient og server forhandle den beste tilgjengelige gruppen selv. Med FrodoKEM finnes ingen slik gratis vei. Enhver bruk krever et bevisst valg, et bibliotek som støtter det eksplisitt, og en motpart som har gjort det samme valget. Det er en vesentlig driftsmessig forskjell, uavhengig av hvor konservativt det matematiske grunnlaget er.
Bruksområder: når bør du velge ML-KEM versus FrodoKEM
Valget avhenger mindre av generell sikkerhetsfølelse og mer av hva systemet faktisk skal tåle, og hvor lenge dataene må forbli hemmelige. Et nyttig tankeeksperiment er å spørre hvor gammel informasjonen fortsatt vil være skadelig om den lekker, et spørsmål sikkerhetsarkitekter i økende grad bygger inn i egne risikovurderinger under navnet “crypto-relevant quantum computer”-horisonten. Her er seks konkrete scenarioer basert på nettopp det spørsmålet:
- Offentlige HTTPS-tjenester og nettbutikker: bruk ML-KEM i hybrid med X25519. Bred nettleserstøtte og lav overhead gjør dette til standardvalget.
- VPN og IPsec på mobilnett: ML-KEM. FrodoKEMs 19 til 43 kB i ekstra håndtrykksdata er problematisk på nett med variabel dekning.
- IoT og innebygde enheter med trang båndbredde: ML-KEM-512, eller i noen tilfeller ren klassisk kryptografi inntil hardwaren støtter post-kvante-operasjoner effektivt. Unngå FrodoKEM her.
- Langtidsarkivering av statshemmeligheter eller forsvarsdata med krav om 20 til 30 års konfidensialitet: vurder FrodoKEM som et tilleggslag ved siden av ML-KEM, i tråd med BSI sin anbefaling om forsvar i dybden.
- Høysikkerhetsarkiver der båndbredde og regnetid er sekundært: en hybrid av klassisk kryptografi, ML-KEM og FrodoKEM gir maksimal algoritmisk diversitet mot ukjente fremtidige svakheter.
- Forskning, testing og algoritmemangfold-evaluering: FrodoKEM er verdifull som referanseimplementasjon nettopp fordi den unngår strukturerte gitter, og brukes aktivt i akademiske sammenligningsstudier.
For de aller fleste norske og nordiske virksomheter, fra bank til offentlig forvaltning, lander svaret på ML-KEM i hybridmodus. FrodoKEM er et verktøy for spesifikke, høyt spesialiserte unntak, ikke en erstatning for hovedstandarden.
Et sjette poeng fortjener egen oppmerksomhet: signatursiden av post-kvante-migreringen følger andre regler enn nøkkelutveksling. ML-KEM og FrodoKEM løser begge nøkkelinnkapsling, mens digitale signaturer trenger egne algoritmer som ML-DSA eller SLH-DSA. Blander man disse sammen i en migreringsplan, risikerer man å optimalisere feil del av stakken. En fullstendig post-kvante-strategi må dekke både nøkkelutveksling og signaturer, og de to velges uavhengig av hverandre basert på egne krav til ytelse og signaturstørrelse, noe vi går gjennom i detalj i ML-DSA versus ECDSA.
Migreringsguide: slik går du fra klassisk til post-kvante KEM
Uansett om målet er ML-KEM alene eller en hybrid med FrodoKEM som tilleggslag, følger migreringen samme grunnleggende rekkefølge. De fleste team som har gjennomført dette i 2025 og 2026 rapporterer at selve kryptoendringen tar kortere tid enn å finne og oppdatere alle stedene gammel krypto er hardkodet inn i eldre systemer. Her er stegene de fleste sikkerhetsteam bør gå gjennom:
- Kartlegg all nåværende kryptografi: TLS-versjoner, nøkkelutvekslingsmetoder og sertifikatkjeder i bruk i dag.
- Velg et bibliotek med dokumentert post-kvante-støtte, for eksempel OpenSSL 3.5 eller nyere, BoringSSL, wolfSSL, eller liboqs for testformål.
- Test hybridmodus i et isolert miljø først. Kjør aldri ren ML-KEM eller ren FrodoKEM alene i produksjon, kombiner alltid med en klassisk mekanisme under overgangsperioden.
- Mål faktisk håndtrykkstørrelse og forsinkelse i testmiljøet ditt, ikke bare de publiserte byte-tallene isolert.
- Sjekk MTU og fragmenteringsgrenser spesielt for UDP-baserte protokoller som QUIC, der FrodoKEMs størrelse er mest problematisk.
- Rull ut til et lite undersett av trafikk først, for eksempel én prosent av nye tilkoblinger, og overvåk feilrater.
- Se spesielt etter eldre klienter og mellomledd uten post-kvante-støtte, disse kan feile stille under forhandling.
- Skaler gradvis mot den standardiserte hybridgruppen, typisk X25519MLKEM768 for TLS 1.3.
- Dokumenter krypto-smidighet, altså evnen til å bytte algoritme raskt, i tilfelle fremtidige funn krever det.
- Vurder FrodoKEM som et eget, eksplisitt konfigurert tilleggslag kun der arkiveringskravene faktisk tilsier det.
For å teste hvilken hybridgruppe en server faktisk forhandler, holder det å bruke OpenSSL sin kommandolinje direkte mot endepunktet:
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -tls1_3Kommandoen viser om serveren faktisk forhandler ML-KEM-hybriden, eller faller tilbake til ren klassisk nøkkelutveksling. Dette bør inngå som en fast sjekk i overvåkingen av enhver tjeneste som migrerer, fordi stille fallback til klassisk kryptografi er den vanligste feilen team gjør under denne typen migrering. Artikkelen om hybrid versus ren ML-KEM i TLS går dypere inn i nøyaktig hvor mye ekstra håndtrykksdata hybridmodus legger til, og hvorfor det likevel er anbefalt under overgangen.
Mange team undervurderer steg seks og syv, nemlig overvåking av gamle klienter. Interne systemer, gamle mobilapper som ikke oppdateres automatisk, og tredjeparts-API-er kan alle henge igjen på TLS-biblioteker uten post-kvante-støtte i flere år etter at hovedtjenesten er migrert. En god migreringsplan logger hvilken gruppe hver tilkobling faktisk forhandlet, slik at man kan se nøyaktig når den siste gjenværende klassiske klienten forsvinner fra trafikken, i stedet for å gjette.
Bibliotekstøtte: hvor implementerer du dette i praksis
Ingen av algoritmene trenger å implementeres fra bunnen av, og det bør man heller ikke gjøre i produksjon. Fire biblioteker dekker de fleste praktiske behov i 2026. OpenSSL fra versjon 3.5 har innebygd støtte for ML-KEM og de standardiserte TLS-hybridgruppene, og er det mest brukte valget for Linux-baserte servere. BoringSSL, Googles fork brukt i Chrome og mange interne Google-tjenester, har kjørt Kyber- og senere ML-KEM-hybrider i produksjon siden 2023. wolfSSL retter seg mot innebygde systemer og IoT, og tilbyr ML-KEM med et vesentlig mindre minneavtrykk enn OpenSSL, noe som er relevant nettopp for enhetene der FrodoKEMs størrelse ville vært en blokkering. Open Quantum Safes liboqs er mindre egnet for direkte produksjonsbruk, men er standardverktøyet for testing, benchmarking og forskning, og er biblioteket de fleste av byte- og ytelsestallene i denne artikkelen er hentet fra.
For team som vil teste FrodoKEM spesifikt, holder det å kompilere liboqs med Frodo-algoritmene aktivert, og deretter kjøre bibliotekets eget benchmark-verktøy mot egen maskinvare:
./speed_kem FrodoKEM-976-AES
./speed_kem ML-KEM-768Å kjøre begge kommandoene på samme maskin, rett etter hverandre, er den mest pålitelige måten å se forskjellen i praksis på, siden resultatet da reflekterer akkurat den CPU-en og den kompilatorkonfigurasjonen tjenesten faktisk skal kjøre på. Generelle tall fra andres testmiljø, inkludert tallene i denne artikkelen, bør alltid behandles som et utgangspunkt for videre testing, ikke som et endelig svar for din egen infrastruktur.
Fordeler og ulemper
Satt opp mot hverandre punkt for punkt, blir mønsteret fra resten av artikkelen enda tydeligere. Tabellen under samler de syv egenskapene som i praksis avgjør hvilken algoritme som passer et gitt system, fra standardiseringsstatus til hva slags oppgaver hver av dem egner seg best til.
| Egenskap | ML-KEM | FrodoKEM |
|---|---|---|
| NIST-status | Standardisert som FIPS 203 | Ikke valgt, men ISO-standardisering pågår |
| Nøkkelstørrelse | 800–1 568 B (offentlig nøkkel) | 9 616–21 520 B (offentlig nøkkel) |
| Ytelse | Mikrosekunder per operasjon | Millisekunder per operasjon |
| Sikkerhetsgrunnlag | Module-LWE (strukturerte gitter) | Ren LWE (ustrukturerte gitter) |
| Produksjonsstøtte | OpenSSL, BoringSSL, wolfSSL, Chrome, Cloudflare, AWS | Hovedsakelig liboqs og forskningsmiljøer |
| Egnet for | TLS, VPN, mobil, IoT, høyvolum-tjenester | Langtidsarkiv, forsvar-i-dybden, konservative krav |
| Svakhet | Avhenger av strukturert gitterproblem | 12–14x større data, langt tregere, lav utbredelse |
Verdikt: hvem vinner sammenligningen?
For nesten alle praktiske formål vinner ML-KEM, og det er ikke en nær avgjørelse. Den er NIST-standardisert i FIPS 203, den har mikrosekund-ytelse, den krever under to kB ekstra i håndtrykksdata selv på høyeste sikkerhetsnivå, og den er allerede satt i produksjon hos Cloudflare, AWS, Chrome og flere store aktører. FrodoKEM taper ikke på sikkerhet i seg selv, ingen praktisk angrep er kjent mot noen av algoritmene, men den taper tungt på alt som gjør en algoritme brukbar i stor skala: 12 til 14 ganger mer data per håndtrykk, to til tre størrelsesordener tregere, og praktisk talt ingen produksjonsstøtte utenfor forskningsmiljøer.
Sett tallene ved siden av hverandre en siste gang. En webtjeneste som bytter fra klassisk ECDHE til ML-KEM-768 legger til rundt 2,3 kB i hvert håndtrykk og mister ingenting merkbart i responstid. Samme tjeneste med FrodoKEM-976 ville lagt til over 30 kB og flyttet nøkkeloperasjonene fra et sted langt under ett millisekund til flere millisekunder, en endring som ville krevd ny kapasitetsplanlegging, ikke bare en versjonsoppdatering. Det er den praktiske kjernen i hvorfor den ene algoritmen er blitt internettets standard og den andre er blitt et nisjeverktøy for spesifikke arkiveringskrav.
FrodoKEM har likevel en reell plass, akkurat ikke som hovedvalg. BSI sin anbefaling om å bruke den som et konservativt tilleggslag for langtidsarkivering er et godt argument i spesifikke, høyt spesialiserte scenarioer der 20 til 30 års konfidensialitet veier tyngre enn ytelse og båndbredde. For det store flertallet av norske og nordiske virksomheter som migrerer TLS, VPN eller API-trafikk til post-kvante kryptografi i 2026, er svaret enkelt: start med ML-KEM i hybridmodus, og vurder FrodoKEM først når et konkret, dokumentert arkiveringskrav tilsier det.
Den korte oppsummeringen for et sikkerhetsteam med begrenset tid: les dette som en sammenligning mellom en ferdig standardisert, bredt støttet løsning med lav kostnad, og en spesialisert forsikring man tegner for et bestemt, avgrenset risikoscenario. De færreste trenger forsikringen i tillegg til hovedløsningen. De som gjør det, vet det som regel allerede, fordi kravet kommer fra en konkret klassifisering av dataene de beskytter, ikke fra en generell følelse av at mer kryptografi alltid er bedre.
Ofte stilte spørsmål
Er ML-KEM og Kyber det samme?
De er nært beslektede, men ikke identiske. Kyber var navnet på NIST-finalisten og den pre-standardiserte versjonen. ML-KEM er den endelige, standardiserte algoritmen i FIPS 203 fra august 2024, med noen mindre justeringer fra de siste Kyber-utkastene.
Hvorfor valgte ikke NIST FrodoKEM som hovedstandard?
Ikke på grunn av en sikkerhetssvakhet. NIST valgte ML-KEM fordi den er vesentlig mer effektiv i nøkkelstørrelse og regnetid, noe som gjør den langt mer praktisk for utbredt bruk i protokoller som TLS.
Er FrodoKEM mindre sikker enn ML-KEM?
Nei, ikke i den forstand at den er bevist svakere. FrodoKEMs ustrukturerte LWE-problem regnes faktisk som et mer konservativt grunnlag av enkelte kryptografer, nettopp fordi det mangler den algebraiske strukturen ML-KEM bruker for å oppnå hastighet.
Kan jeg bruke FrodoKEM i en vanlig nettleser i dag?
Ikke uten videre. Ingen større nettleser forhandler FrodoKEM automatisk. Begge parter i en forbindelse må eksplisitt konfigurere støtte, typisk gjennom et bibliotek som liboqs.
Hva er forskjellen på FrodoKEM-AES og FrodoKEM-SHAKE?
Begge har identisk nøkkel- og chiffertekststørrelse for samme sikkerhetsnivå. Forskjellen ligger i den interne pseudotilfeldige funksjonen: AES-varianten drar nytte av maskinvareakselerert AES-NI, mens SHAKE-varianten kan være raskere på systemer med optimalisert Keccak-implementasjon.
Anbefaler noen myndigheter FrodoKEM?
Tysklands BSI nevner FrodoKEM i sin tekniske retningslinje TR-02102-1 som et egnet konservativt alternativ for langtidsbeskyttelse, ved siden av, ikke i stedet for, ML-KEM.
Hvor mye tregere er FrodoKEM i praksis?
Avhengig av CPU og implementasjon går FrodoKEM fra ML-KEMs mikrosekund-nivå til et sted mellom en halv og åtte millisekunder per operasjon ifølge Open Quantum Safes benchmark-rammeverk, altså to til tre størrelsesordener tregere. Forskjellen øker med sikkerhetsnivået, siden matrisestørrelsen i FrodoKEM vokser raskere enn polynomgraden i ML-KEM når man går fra nivå 1 til nivå 5.
Bør norske virksomheter bry seg om dette nå?
Ja. Med NIS2 og økende krav til kryptoagilitet i både offentlig og privat sektor bør kartlegging av post-kvante-migrering stå på agendaen allerede i 2026. ML-KEM i hybridmodus er et naturlig startpunkt, og metodikken finner du også i vår gjennomgang av kryptografi og digital tillit.
Kan ML-KEM og FrodoKEM brukes sammen i samme system?
Ja, og det er nettopp det BSI foreslår for de mest sensitive arkiveringsbehovene. En hybridkombinasjon av klassisk kryptografi, ML-KEM og FrodoKEM gir tre uavhengige matematiske antakelser å bryte samtidig, på bekostning av vesentlig større håndtrykk og lavere ytelse, noe som gjør det til et verktøy for spesialtilfeller fremfor generell bruk.
