To NIST-godkjente algoritmer løser det samme problemet på nesten motsatt vis. ML-KEM, bedre kjent under kodenavnet Kyber, ble endelig standard i FIPS 203 i august 2024 og kjører i dag på hundrevis av millioner TLS-tilkoblinger hver dag. Classic McEliece er derimot en matematisk konstruksjon fra 1978 som fortsatt ikke har en fullstendig NIST-standard, men som mange kryptografer regner som den mest konservative post-kvante-løsningen som finnes. Forskjellen mellom dem handler ikke bare om hastighet. Den handler om hvor mye plass en offentlig nøkkel skal ta, og det er her tallene blir nesten absurde: en Classic McEliece-nøkkel kan være 326 ganger større enn en tilsvarende ML-KEM-nøkkel.
For norske og nordiske virksomheter som nå planlegger overgangen til kvantesikker kryptografi, er valget mellom disse to familiene langt fra akademisk. Bank-ID-leverandører, offentlige etater og skyleverandører må bestemme seg for hvilken algoritme som passer til hvilket formål, og svaret er sjelden “den ene vinner alt”. Denne sammenligningen går gjennom nøkkelstørrelser, ytelsesbenchmarker fra flere uavhengige kilder, kostnader ved drift i stor skala, og hvilke organisasjoner som faktisk har tatt algoritmene i bruk i 2025 og 2026.
Begge algoritmene løser det samme grunnleggende problemet: to parter som aldri har møtt hverandre skal bli enige om en hemmelig nøkkel over en usikret linje, uten at en fremtidig kvantedatamaskin kan regne seg bakover til hemmeligheten. Løsningen på det problemet kalles en nøkkelinnkapslingsmekanisme, forkortet KEM, og både ML-KEM og Classic McEliece tilhører denne kategorien. Der de skiller lag, er i hvilken type matematisk hardhet de stoler på, og det valget forplanter seg helt ned til hvor mange byte som må sendes hver eneste gang to systemer skal snakke sammen.
Hva er ML-KEM (Kyber), og hvorfor ble det NIST-standard
ML-KEM står for Module-Lattice-Based Key-Encapsulation Mechanism og bygger på den samme gittermatematikken som gjorde Kyber til vinneren i NIST sin post-kvante-konkurranse. Algoritmen ble formelt standardisert i FIPS 203 i august 2024, og siden den gang har den blitt selve ryggraden i overgangen til kvantesikker internett-trafikk. Grunnen er enkel: ML-KEM gir god sikkerhet uten å blåse opp datamengden i en TLS-håndtrykk, noe som gjør den praktisk å sette inn i eksisterende protokoller uten store endringer i infrastrukturen. NIST valgte Kyber som hovedvinner blant fire ferdigstandardiserte algoritmer nettopp fordi kombinasjonen av liten nøkkelstørrelse, rask beregning og solid sikkerhetsanalyse skilte den fra resten av feltet i konkurransens tredje og fjerde runde.
Algoritmen finnes i tre parametersett. ML-KEM-512 gir sikkerhetsnivå 1, tilsvarende styrken til AES-128. ML-KEM-768 ligger på nivå 3, sammenlignbart med AES-192, og er det settet de fleste nettlesere og skytjenester bruker som standard i dag. ML-KEM-1024 gir nivå 5, på linje med AES-256, og velges gjerne av organisasjoner med ekstra strenge krav, som forsvarssektoren eller langsiktig arkivering. Uansett nivå holder de offentlige nøklene seg mellom 800 og 1.568 byte, noe som er lite nok til at en hel håndtrykk-utveksling knapt merkes på moderne nettverk.
FIPS 203 og de tre sikkerhetsnivåene
Det som gjør ML-KEM spesielt attraktivt for drift i stor skala, er at ytelsen er forutsigbar. Ifølge et 2026-benchmark fra Decent Cybersecurity, som testet flere post-kvante-biblioteker inkludert Bouncy Castle, CIRCL og liboqs på moderne x86-maskinvare, tar nøkkelgenerering for ML-KEM-512 rundt 7,57 mikrosekunder, innkapsling 9,79 mikrosekunder og dekapsling 7,07 mikrosekunder. For ML-KEM-768 er tallene 17,63, 16,06 og 10,97 mikrosekunder. Det er hastigheter som knapt registreres i en vanlig applikasjonslogg, og det forklarer hvorfor så mange store aktører har valgt ML-KEM som sin første post-kvante-algoritme i produksjon.
Referanseimplementasjonen av Kyber, som ML-KEM bygger direkte videre på, viser lignende tall på egen maskinvare: operasjoner målt i titalls mikrosekunder uten AVX2-instruksjoner, og omtrent halvert med AVX2 aktivert. Til sammenligning bruker en klassisk X25519-utveksling gjerne 150 til 200 mikrosekunder på tilsvarende maskinvare, noe som betyr at ML-KEM ofte er like raskt, eller raskere, enn algoritmen den er ment å etterhvert erstatte. Biblioteket liboqs, som brukes som grunnlag for benchmarker i både akademia og industri, plasserer ML-KEM “helt i front” for hastighet blant testede post-kvante-KEM-er, mens kodebaserte alternativer som McEliece systematisk havner lenger bak nettopp på grunn av nøkkelgenereringen.
Hva er Classic McEliece, og hvorfor har koden overlevd 47 år
Classic McEliece bygger på en helt annen gren av matematikken enn ML-KEM. Der Kyber henter sikkerheten sin fra gitterproblemer, baserer McEliece seg på feilrettende koder, en teknikk som opprinnelig ble utviklet for å sende data pålitelig gjennom støyete kanaler. Robert McEliece publiserte selve ideen i 1978, ved California Institute of Technology, lenge før noen snakket om kvantedatamaskiner som en reell trussel. Siden den gang har konstruksjonen blitt angrepet av generasjon etter generasjon av kryptografer uten at kjernen har falt. Det gir McEliece en tillitshistorie som få andre post-kvante-kandidater kan matche, rett og slett fordi den har hatt nesten et halvt århundre til å bli knekt. Til sammenligning har ML-KEM og de andre gitterbaserte kandidatene bare vært gjenstand for intensiv offentlig kryptoanalyse siden slutten av 2010-tallet, en brøkdel av tiden McEliece har vært eksponert for angrep.
Fra 1978-idé til NIST fjerde runde
Til tross for den lange historien er Classic McEliece fortsatt ikke en ferdig FIPS-standard. NIST plasserte den i sin fjerde standardiseringsrunde, og en statusrapport fra byrået i 2025 beskriver algoritmen presist: den har en svært stor offentlig nøkkel og en relativt treg nøkkelgenerering. Det er nettopp denne kombinasjonen, ekstrem konservatisme i sikkerhet mot upraktisk store nøkler, som definerer hele diskusjonen rundt McEliece. Biblioteket liboqs fra Open Quantum Safe-prosjektet lister Classic McEliece som “under vurdering hos ISO”, og den støttes i versjon 0.14.0 av biblioteket sammen med blant annet BIKE, FrodoKEM, HQC og ML-KEM.
Et viktig poeng mange glemmer: Classic McEliece er i praksis patentfri. Kenneth Paterson, en av personene bak NIST-innsendelsen, har erklært offisielt at teamet verken har eller planlegger patenter på konstruksjonen. Tidligere patenter som kunne ha skapt usikkerhet, blant annet det britiske patentet GB2532242, er formelt trukket tilbake ifølge NIST sine offentlige kommentarer. Det betyr at både ML-KEM og Classic McEliece er fritt tilgjengelige å implementere uten lisenskostnader, noe som fjerner én potensiell barriere for adopsjon.
Konstruksjonen har også vist seg overraskende motstandsdyktig mot forsøk på å angripe den med kvantealgoritmer. Mens Shors algoritme knuser RSA og elliptisk kurve-kryptografi fullstendig så snart en tilstrekkelig stor kvantedatamaskin eksisterer, gir den kodebaserte dekodingsantakelsen bak McEliece ingen tilsvarende åpenbar svakhet for kvantealgoritmer. Det er nettopp derfor NIST valgte å holde McEliece i live gjennom flere standardiseringsrunder til tross for at nøkkelstørrelsen er upraktisk for de fleste vanlige bruksområder. Byrået ønsker minst én kodebasert kandidat i den endelige porteføljen, som en forsikring mot at fremtidig forskning skulle svekke tilliten til gitterbaserte metoder som ML-KEM.
Nøkkelstørrelser side om side: full spesifikasjonstabell
Det er i nøkkelstørrelsene den virkelige forskjellen mellom algoritmene kommer til syne. Tabellen under stiller opp de tre offisielle ML-KEM-parametersettene mot tre av de vanligste Classic McEliece-variantene, hentet direkte fra FIPS 203 og Classic McEliece sin egen spesifikasjon.
| Egenskap | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 | McEliece 348864 | McEliece 460896 | McEliece 6688128 |
|---|---|---|---|---|---|---|
| Sikkerhetsnivå (NIST-kategori) | 1 | 3 | 5 | 1 | 3 | 5 |
| Offentlig nøkkel | 800 byte | 1.184 byte | 1.568 byte | 261.120 byte | 524.160 byte | 1.044.992 byte |
| Privat nøkkel | 1.632 byte | 2.400 byte | 3.168 byte | ~6.400 byte | ~13.900 byte | ~14.080 byte |
| Chiffertekst | 768 byte | 1.088 byte | 1.568 byte | 96 byte | 96 byte | 240 byte |
| Delt hemmelighet | 32 byte | 32 byte | 32 byte | 32 byte | 32 byte | 32 byte |
| Nøkkelgenerering (Decent Cybersecurity 2026) | ~7,6 µs | ~17,6 µs | ikke målt | ~35.000 µs | ikke målt | ikke målt |
| Innkapsling | ~9,8 µs | ~16,1 µs | ikke målt | ~13,4 µs | ikke målt | ikke målt |
| Dekapsling | ~7,1 µs | ~11,0 µs | ikke målt | ~126,3 µs | ikke målt | ikke målt |
| Matematisk grunnlag | Modul-gitter | Modul-gitter | Modul-gitter | Goppa-koder | Goppa-koder | Goppa-koder |
| NIST-status (2026) | FIPS 203, endelig | FIPS 203, endelig | FIPS 203, endelig | Fjerde runde | Fjerde runde | Fjerde runde |
| Typisk bruk | TLS, SSH | TLS, SSH, VPN | Signal, arkiv | Statiske nøkler | Statiske nøkler | Langtidsarkiv |
Legg merke til det motsatte mønsteret i chiffertekst-raden. Mens ML-KEM har relativt store chiffertekster og små nøkler, snur McEliece dette på hodet: en enorm offentlig nøkkel, men en chiffertekst på bare 96 til 240 byte, faktisk mindre enn ML-KEM sin. Det er denne asymmetrien som avgjør hvilken algoritme som passer til hvilket bruksmønster, noe vi kommer tilbake til i avsnittet om bruksområder.
Ser man på tallene fra et annet perspektiv, blir kontrasten enda tydeligere. En ML-KEM-1024-nøkkel, det høyeste sikkerhetsnivået i familien, er fortsatt mindre enn en enkelt e-postvedlegg på 2 kilobyte. En McEliece 6688128-nøkkel derimot, veier over én megabyte, nok til å romme en enkel nettside med flere bilder. Det er ikke en liten forskjell i prosent, det er en forskjell i størrelsesorden, og den forplanter seg direkte til alt fra minnebruk på embedded enheter til hvor raskt en mobiltelefon på et svakt 4G-nett i Nord-Norge klarer å fullføre en tilkobling.
Ytelsesbenchmark: nøkkelgenerering, innkapsling og dekapsling
Ingen enkelt benchmark forteller hele historien, så vi har samlet tall fra flere uavhengige kilder for å unngå å basere konklusjonen på ett enkelt måleoppsett. Den første kilden er 2026-sammenligningen fra Decent Cybersecurity, sitert i tabellen over. Der ser vi at McEliece 348864 bruker rundt 35 millisekunder på å generere et nøkkelpar, mens ML-KEM-512 klarer det samme på under 8 mikrosekunder. Det er en forskjell på over 4.000 ganger, og den vokser enda mer for de større McEliece-variantene.
Den andre kilden er en masteroppgave fra Politecnico di Torino som benchmarket PQClean-implementasjoner av flere post-kvante-algoritmer i en samlet batch. Der tok en serie operasjoner med mceliece348864 3,981 sekunder med standardimplementasjonen, og falt til 1,553 sekunder med en optimalisert additiv FFT-multiplikator. For mceliece460896 var tallene 25,781 sekunder uoptimalisert og 3,437 sekunder optimalisert, og for mceliece6688128 hele 57,289 sekunder uoptimalisert mot 9,529 sekunder optimalisert. Dette er batch-tider for flere operasjoner samlet, ikke enkeltoperasjoner, men de viser tydelig at kostnaden ved å generere store McEliece-nøkler vokser raskt med sikkerhetsnivået.
Den tredje kilden er NIST sin egen statusrapport fra fjerde runde i 2025, som uttrykkelig beskriver McEliece som å ha “svært stor offentlig nøkkelstørrelse og relativt treg nøkkelgenerering”, en vurdering som stemmer godt overens med de målte tallene fra både Decent Cybersecurity og Politecnico di Torino. En fjerde kilde, KpqClean-studien som rangerer NIST-kandidater og deres derivater etter ytelse, plasserer Kyber- og ML-KEM-variantene konsekvent blant de raskeste KEM-ene som er testet, mens McEliece-variantene havner nederst på grunn av den tunge nøkkelgenereringen.
En femte kilde ser på ML-KEM alene, men er verdt å ta med fordi den viser hvor mye målemetodikk faktisk påvirker tallene. Den japanske standardiseringsorganisasjonen CRYPTREC publiserte i 2025 egne tall for ML-KEM: 0,020 millisekunder for nøkkelgenerering, 0,014 millisekunder for innkapsling og 0,023 millisekunder for dekapsling ved ML-KEM-512, med tilsvarende 0,031, 0,020 og 0,032 millisekunder for ML-KEM-768. Det er lavere enn Decent Cybersecurity sine tall, men peker i samme retning. Enda mer interessant er et 2025-notat fra en NIST-presentasjon om post-kvante-tjenester i skyen, som fant at et fullstendig ML-KEM-768-håndtrykk var mellom åtte og ti ganger raskere enn en tradisjonell ECDH-utveksling med kurven P-256, målt på en c6i.xlarge-instans hos AWS. For organisasjoner som drifter i stor skala, betyr det at overgangen til ML-KEM ikke bare handler om å bli kvantesikker. Den kan faktisk redusere CPU-belastningen sammenlignet med enkelte klassiske alternativer.
# Sjekk hvilke post-kvante nøkkelutvekslinger en TLS-server tilbyr
openssl s_client -groups X25519MLKEM768 -connect eksempel.no:443
# List tilgjengelige KEM-algoritmer i liboqs (inkluderer begge familier)
python3 -c "import oqs; print(oqs.get_enabled_kem_mechanisms())"Verdt å merke seg er at innkapsling og dekapsling, altså operasjonene som skjer for hver enkelt melding etter at nøkkelen finnes, er langt jevnere mellom de to familiene enn nøkkelgenerering. McEliece 348864 innkapsler faktisk raskere enn ML-KEM-768 i Decent Cybersecurity-testen, 13,4 mot 16,1 mikrosekunder. Det underbygger hvorfor McEliece egner seg best når nøkkelen genereres én gang og deretter brukes tusenvis av ganger, mens den store engangskostnaden ved nøkkelgenerering fordeles over lang tid.
Sikkerhetsantakelser: gittermatematikk mot kodeteori
Sikkerheten til ML-KEM hviler på at det er beregningsmessig umulig å finne korte vektorer i høydimensjonale gitter, et problem som har vært studert intensivt siden 1990-tallet, men som fortsatt er relativt ungt sammenlignet med klassiske talleoriproblemer som heltallsfaktorisering. Gittermatematikk har vist seg robust mot både klassiske og kjente kvantealgoritmer, og NIST valgte da også Kyber som hovedkandidat nettopp fordi kombinasjonen av sikkerhetsmargin og ytelse var best i klassen blant de innsendte forslagene.
Classic McEliece bygger derimot på vanskeligheten ved å dekode en tilfeldig lineær kode, spesifikt binære Goppa-koder. Det som gjør denne antakelsen spesielt tiltalende for konservative miljøer, er alderen. Konstruksjonen har stått imot kryptoanalyse siden 1978 uten at noen har funnet en praktisk måte å bryte den grunnleggende dekodingsantakelsen på, verken med klassiske datamaskiner eller med kjente kvantealgoritmer som Shors og Grovers algoritme. Grovers algoritme gir riktignok en kvadratisk hastighetsøkning mot generelle søkeproblemer, noe som i teorien halverer sikkerhetsmarginen til de underliggende kodene, men det er en langt mildere effekt enn den totale kollapsen Shors algoritme forårsaker mot RSA og elliptisk kurve-kryptografi. Det er nettopp denne forskjellen i hvordan de to matematiske problemene reagerer på kvanteangrep, som gjør at kodebasert kryptografi regnes som en av de tryggeste kategoriene i hele post-kvante-feltet. For organisasjoner som frykter at gittermatematikken kan vise seg sårbar for angrep vi ennå ikke har oppdaget, gir McEliece en form for forsikring. Selv om gitterbaserte metoder en dag skulle svikte, ville McEliece stå igjen som et uavhengig sikkerhetsanker bygget på helt andre matematiske forutsetninger.
Denne typen kryptografisk mangfold, altså å ha flere algoritmer basert på ulike matematiske problemer i bruk samtidig, er blitt en uttalt strategi i sikkerhetsmiljøet etter at flere tidligere post-kvante-kandidater falt underveis i NIST-prosessen. SIKE, et gitteruavhengig alternativ basert på isogenier mellom elliptiske kurver, ble brutt med en vanlig bærbar PC i 2022 etter å ha kommet langt i konkurransen. Den hendelsen minnet hele fagmiljøet om at selv grundig gjennomgåtte konstruksjoner kan ha svakheter ingen har funnet ennå, og den er en viktig del av begrunnelsen for hvorfor NIST fortsatt investerer tid i å ferdigstille en kodebasert løsning som Classic McEliece, selv om ytelsen aldri kommer til å konkurrere med gitterbaserte alternativer som ML-KEM.
Hva koster forskjellen i praksis? Båndbredde og drift
Nøkkelstørrelse er ikke bare et teoretisk tall. Den påvirker direkte hvor mye data som må sendes over nettet, og dermed hva et selskap betaler for utgående trafikk hos en skyleverandør. AWS sin offentlige prisliste opererer med 0,09 dollar per GB for standard internett-egress i US East, etter de første 100 GB gratis hver måned. Cloudflare går motsatt vei og tilbyr ubegrenset båndbredde uten GB-avgift på CDN-trafikk, Workers og R2-lagring på alle planer, inkludert gratisplanen. Denne forskjellen i prismodell påvirker regnestykket, men selve nøkkelstørrelsen forblir konstant uansett hvilken leverandør man bruker.
| Scenario (AWS-egress, 0,09 USD/GB) | ML-KEM-512 | McEliece 348864 | ML-KEM-1024 | McEliece 6688128 |
|---|---|---|---|---|
| Datamengde per offentlig nøkkel | 800 byte | 261.120 byte | 1.568 byte | 1.044.992 byte |
| Total data ved 1 million overføringer | 0,8 GB | 261,1 GB | 1,6 GB | 1.045 GB |
| Beregnet AWS-egresskostnad | ~0,07 USD | ~23,50 USD | ~0,14 USD | ~94,05 USD |
| Kostnadsforhold | 1x | ~326x | 1x | ~666x |
Tallene over er beregnet ut fra de offisielle nøkkelstørrelsene og AWS sin publiserte prisliste, og de illustrerer hvorfor ingen store nettlesere eller CDN-er sender en fersk McEliece-nøkkel for hver enkelt TLS-tilkobling. I praksis brukes McEliece nesten aldri på denne måten. Nøkkelen genereres én gang, distribueres via et sertifikat, en fastvareoppdatering eller et fysisk medium, og gjenbrukes deretter i lang tid. Det er nettopp derfor begge sammenligningens ytterpunkter, engangskostnad mot gjenbruk, blir så avgjørende for hvilken algoritme som gir mening i et gitt system.
Regnestykket ser annerledes ut når man snur det om. Hvis et system genererer én McEliece-nøkkel og deretter bruker den i for eksempel fem år uten fornyelse, fordeles den ene store overføringskostnaden på svært mange sesjoner, og merkostnaden per faktisk bruk blir minimal. Det er nøyaktig denne bruksmodellen som gjør McEliece attraktiv for blant annet fastvaresignering, der en enhet får én rotnøkkel lagret permanent i produksjon, eller for arkivsystemer der nøkkelen genereres én gang og deretter beskytter data i tiår fremover. Problemet oppstår bare når noen prøver å presse McEliece inn i et mønster den ikke er bygget for, som en vanlig TLS-håndtrykk der en ny nøkkel i prinsippet skal genereres eller sendes for hver eneste tilkobling.
Virkelige eksempler: hvem bruker hva i dag
ML-KEM har på under to år gått fra standard til allestedsnærværende. Google Chrome aktiverte hybrid X25519+Kyber768-nøkkelutveksling som standard fra Chrome 124 i april 2024, og har siden bygget videre på dette med full ML-KEM-støtte. Cloudflare rullet ut post-kvante-nøkkelutveksling på hele kantnettverket sitt allerede i 2023, først med den midlertidige gruppen X25519Kyber768Draft00, og gikk senere over til den ferdigstandardiserte ML-KEM-768 etter at FIPS 203 ble endelig. AWS har lagt ML-KEM-støtte inn i KMS, Certificate Manager og s2n-tls-biblioteket sitt gjennom 2025.
Signal gikk enda lenger og bygde Kyber-1024 direkte inn i nøkkelutvekslingsprotokollen sin, omdøpt til PQXDH, allerede i september 2023, ifølge Signals egen kunngjøring. Hver ny samtale i appen får dermed hybrid beskyttelse mot både klassiske og kvantebaserte angrep. OpenSSH støttet hybrid Kyber-basert nøkkelutveksling fra versjon 9.0, og fra OpenSSH 10.0 i april 2025 ble mlkem768x25519-sha256 satt som standardvalg for alle nye tilkoblinger. For en dypere sammenligning av hvordan ML-KEM måler seg mot andre kandidater, kan du se vår gjennomgang av ML-KEM mot HQC og ML-KEM mot NTRU.
Classic McEliece har en helt annen adopsjonsprofil. Algoritmen er tilgjengelig i liboqs fra Open Quantum Safe-prosjektet og støttes i forskningsbaserte implementasjoner som Bernsteins libmceliece, sist oppdatert oktober 2024. Den brukes i akademiske testbenker, blant annet ved Politecnico di Torino, og inngår i KpqClean-benchmarksuiten som følger med biblioteker som Bouncy Castle og CIRCL. Algoritmen står også oppført som “under ISO-vurdering”, noe som tyder på at flere organisasjoner som deltar i standardiseringsarbeidet allerede piloterer den internt. Det finnes derimot ingen offentlig kjente, navngitte produksjonssystemer i stor skala som bruker McEliece for TLS eller SSH i dag, noe som understreker at algoritmen fortsatt lever mest i forskning, biblioteker og spesialiserte nisjebruk fremfor i vanlig internett-trafikk.
Listen over ML-KEM-brukere fortsetter å vokse. Firefox aktiverte hybrid ML-KEM-gruppen X25519MLKEM768 som standard i løpet av 2025, og både OpenSSL 3.5 og BoringSSL leverer nå ML-KEM-512, ML-KEM-768 og ML-KEM-1024 som navngitte grupper rett ut av boksen. Microsoft Azure har lagt til støtte for hybrid TLS med ML-KEM i sine tjenester, og følger dermed samme mønster som AWS og Cloudflare. Til sammen betyr dette at en vanlig utvikler i Norge eller Norden i praksis allerede møter ML-KEM daglig, uten nødvendigvis å vite det, hver gang de besøker et nettsted som kjører gjennom Cloudflare eller åpner en nyere versjon av Chrome eller Firefox.
Hvor mange bruker post-kvante-kryptografi i dag
Adopsjonstallene for hybrid post-kvante-nøkkelutveksling har beveget seg overraskende raskt. En langsgående måling av reelle TLS-håndtrykk på åpne internett viser at andelen domener som forhandlet en hybrid post-kvante-gruppe som standard, lå på 31,26 prosent i juli 2025. Innen november 2025 hadde andelen steget til 47,37 prosent, og i mars 2026 lå den på 49,22 prosent. På under ett år har altså post-kvante-beskyttelse gått fra å være et pilotprosjekt hos et fåtall aktører til å dekke nesten halvparten av målt trafikk på nettet.
Denne veksten henger tett sammen med at TLS 1.3 i praksis er den eneste protokollen som fører an i overgangen. TLS 1.2 mangler en definert vei til post-kvante-støtte, og ligger fast på null i adopsjon av slik kryptografi, ifølge en migreringsrapport fra 2025. En IETF-utkast om post-kvante-kryptografi for (D)TLS anbefaler dessuten uttrykkelig at systemer som er sårbare for “høst nå, dekrypter senere”-angrep, altså at noen lagrer kryptert trafikk i dag for å dekryptere den når en kvantedatamaskin en dag finnes, må gå over til TLS 1.3 med PQC-støtte. Det inkluderer tilbaketrekking av gamle sertifikater og overgang til post-kvante-sikre sertifiseringsinstanser, noe som er spesielt relevant for norske banker og offentlige etater som håndterer data med lang konfidensialitetstid.
Migrasjonsguide: slik velger og innfører du riktig algoritme
En overgang til post-kvante-kryptografi krever mer planlegging enn å bytte ut ett bibliotek. De fleste selskaper som har gjort dette i 2025 og 2026, følger en variant av samme rekkefølge, uavhengig av om de ender opp med ML-KEM alene, Classic McEliece til spesialformål, eller en kombinasjon av begge. Her er en praktisk rekkefølge for organisasjoner som vurderer ML-KEM, Classic McEliece, eller begge deler til ulike formål.
- Kartlegg hvilke systemer som håndterer sensitive data med lang levetid. Data som må forbli hemmelig i 10-20 år er mest utsatt for “høst nå, dekrypter senere”-angrep.
- Skill mellom handshake-bruk (TLS, SSH, VPN) og statisk nøkkelbruk (arkivering, fastvaresignering, langtidslagrede sertifikater). Dette avgjør om ML-KEM eller McEliece passer best.
- For handshake-bruk: oppgrader TLS-stakken til en versjon som støtter ML-KEM, for eksempel OpenSSL 3.5 eller nyere, og aktiver hybridgrupper som X25519MLKEM768.
- For SSH: oppgrader til OpenSSH 9.0 eller nyere, og bekreft at mlkem768x25519-sha256 er aktivert som standard fra versjon 10.0.
- For statisk nøkkelbruk med ekstreme sikkerhetskrav: vurder Classic McEliece via liboqs, men budsjetter for økt lagringsplass og lengre nøkkelgenereringstid i driftsplanen.
- Test med hybridmodus først, det vil si klassisk algoritme pluss post-kvante-algoritme sammen, slik at systemet forblir sikkert selv om en av de to skulle vise seg sårbar.
- Mål faktisk ytelsespåvirkning i eget miljø. Bruk tallene fra denne artikkelen som utgangspunkt, men bekreft med egne benchmarker på egen maskinvare.
- Oppdater sertifikatkjeder og PKI-infrastruktur gradvis, og planlegg for at eldre klienter uten PQC-støtte fortsatt må kunne koble til i en overgangsperiode.
- Dokumenter valget i risikovurderingen, spesielt for virksomheter som er underlagt NIS2 eller tilsvarende regulering i Norge og EU.
For team som allerede kjører hybridløsninger, er det verdt å lese vår gjennomgang av hybrid mot ren ML-KEM i TLS, som går i dybden på hvor mye ekstra data hybridmodus faktisk legger til i et håndtrykk sammenlignet med kun å bruke ML-KEM alene.
De vanligste fallgruvene under en slik migrering handler sjelden om selve kryptografien. De fleste problemer oppstår i randsonene: lastbalanserere som ikke videresender de nye TLS-gruppene korrekt, gamle klientbiblioteker som feiler stille når de møter et ukjent handshake-format, eller overvåkingssystemer som ikke er oppdatert til å gjenkjenne de nye cipher-navnene og dermed rapporterer falske feil. Et godt råd er å rulle ut ML-KEM-støtte gradvis, gjerne først på interne tjenester eller et lite utvalg produksjonstrafikk, og følge nøye med på feilrater før man aktiverer det som standard for alle brukere. Cloudflare og Google fulgte begge en slik gradvis tilnærming da de innførte hybrid post-kvante-støtte, og erfaringene deres er en del av grunnen til at adopsjonen på det åpne internett har gått så raskt uten store driftsforstyrrelser.
Bruksområder: når bør du velge ML-KEM, og når Classic McEliece
Valget mellom de to algoritmene avhenger nesten utelukkende av hvor ofte nøkkelen skal genereres og sendes, og hvor lenge den skal leve før den byttes ut. Et nyttig tommelfingerregel er å spørre seg hvor mange ganger nøkkelen realistisk sett vil bli generert eller overført i løpet av systemets levetid. Er svaret “tusenvis eller millioner av ganger”, peker alt mot ML-KEM. Er svaret “én gang, kanskje aldri på nytt”, åpner det for at Classic McEliece kan være verdt den ekstra lagringsplassen. Under følger sju konkrete anbefalinger basert på egenskapene vi har gått gjennom.
| Bruksområde | Anbefalt algoritme | Begrunnelse |
|---|---|---|
| TLS-håndtrykk for nettsteder og API-er | ML-KEM-768 | Lav nøkkelstørrelse gjør hyppig, fersk nøkkelutveksling billig og rask |
| SSH-tilkoblinger mot servere | ML-KEM-768 | Standard i OpenSSH 10.0, minimal ekstra båndbredde per økt |
| Meldingsapper med økt-basert kryptering | ML-KEM-1024 | Signal bruker Kyber-1024 for høyeste sikkerhetsmargin per samtale |
| Langtidsarkivering av dokumenter (10-30 år) | Classic McEliece | Nøkkelen genereres én gang, ekstrem konservativ sikkerhetsmargin over tid |
| Fastvaresignering i maskinvare (skrives sjelden om) | Classic McEliece | Stor nøkkel er akseptabel når den lagres permanent i enheten |
| Høyfrekvente mikrotjenester internt i skyen | ML-KEM-512 | Laveste beregningskostnad når volumet av tilkoblinger er høyt |
| Nasjonale digitale ID-løsninger med lang levetid | Hybrid ML-KEM + klassisk, vurder McEliece for rotnøkler | Kombinerer rask drift med et uavhengig matematisk sikkerhetsanker |
Merk at digitale signaturer er et annet problem enn nøkkelutveksling, og krever egne algoritmer som ML-DSA eller SPHINCS+. Se gjerne vår sammenligning av Falcon mot Dilithium hvis systemet ditt også trenger post-kvante-signaturer i tillegg til nøkkelutveksling.
Fordeler og ulemper
Etter å ha gått gjennom nøkkelstørrelser, ytelse, sikkerhetsantakelser og faktisk bruk i produksjon, er det verdt å samle trådene i en ren oversikt over styrker og svakheter for hver algoritme. Ingen av listene under skal leses som en fasit for alle situasjoner, men de oppsummerer hvor de to virkelig skiller lag.
ML-KEM: fordeler og ulemper
- Fordel: Små nøkler og chiffertekster (800-1.568 byte) egner seg perfekt for hyppige handshakes
- Fordel: Ferdig FIPS 203-standard siden august 2024, bred verktøystøtte i OpenSSL, BoringSSL og s2n-tls
- Fordel: Målt i mikrosekunder for alle operasjoner, minimal CPU-belastning selv i stor skala
- Ulempe: Gittermatematikk er yngre studert enn kodeteori, med kortere kryptoanalytisk historie
- Ulempe: Krever hybridmodus med klassisk algoritme for maksimal føre-var-sikkerhet i mange regelverk
Classic McEliece: fordeler og ulemper
- Fordel: 47 år med offentlig kryptoanalyse uten praktiske brudd på kjernekonstruksjonen
- Fordel: Svært liten chiffertekst (96-240 byte), ideelt når nøkkelen kan gjenbrukes over tid
- Fordel: Patentfri og royalty-fri, bekreftet gjennom offisielle NIST-erklæringer
- Ulempe: Offentlig nøkkel på 261.120 til over 1 million byte, upraktisk for hyppig overføring
- Ulempe: Fortsatt ikke ferdig FIPS-standardisert, sitter i NIST sin fjerde runde per 2025
- Ulempe: Nøkkelgenerering målt i titalls millisekunder, langt tregere enn ML-KEM
Hva betyr dette for Norge og Norden
Norske og nordiske virksomheter som er omfattet av NIS2-direktivet, står midt i en periode der kvanteforberedt kryptografi går fra anbefaling til forventning. Banker, offentlige etater og kritisk infrastruktur må vise at de har en plan for å håndtere trusselen fra fremtidige kvantedatamaskiner, og for de fleste av disse systemene vil ML-KEM være det naturlige førstevalget nettopp fordi det allerede er innebygd i nettleserne, SSH-klientene og skytjenestene som brukes daglig. Overgangen krever i mange tilfeller ikke mer enn en oppdatering av TLS-biblioteker og en bekreftelse på at hybridgrupper som X25519MLKEM768 er aktivert.
Classic McEliece får en mer spesialisert rolle i denne sammenhengen. Sektorer som arkiverer helsedata, rettsdokumenter eller identitetsopplysninger i flere tiår, kan ha nytte av McEliece som et sekundært sikkerhetslag nettopp fordi konstruksjonen bygger på en helt annen matematisk antakelse enn den gitterbaserte tilnærmingen som dominerer resten av internett. For rotnøkler i nasjonale ID-løsninger som skal stå urørt i lang tid, kan den ekstra lagringskostnaden være en akseptabel pris for en ekstra sikkerhetsmargin. Se også vår gjennomgang av ML-KEM mot RSA for hvordan andelen kvantesikker trafikk har utviklet seg globalt.
Digitaliseringsdirektoratet og tilsvarende etater i Sverige, Danmark og Finland har i økende grad omtalt kvanteforberedt kryptografi som del av den generelle IT-sikkerhetsberedskapen, i tråd med kravene i NIS2. For de fleste nordiske virksomheter er ikke spørsmålet lenger om overgangen skal skje, men i hvilken rekkefølge systemene skal oppgraderes. En fornuftig start er å kartlegge alt som i dag bruker RSA eller ren elliptisk kurve-kryptografi til nøkkelutveksling, siden det er disse systemene som er mest utsatt hvis kryptert trafikk fanges opp og lagres i påvente av en fremtidig kvantedatamaskin.
Verdikt: hvem vinner sammenligningen
Det finnes ingen absolutt vinner her, og det er selve poenget. For alt som ligner en vanlig internett-tilkobling, TLS, SSH, VPN eller meldingsapper, er ML-KEM det klare valget. Nøkler på under 1.600 byte, operasjoner målt i mikrosekunder, og en ferdig FIPS 203-standard gjør algoritmen praktisk overlegen for enhver situasjon der en ny nøkkel forhandles for hver økt. Tallene taler for seg selv: 326 ganger mindre nøkkel enn McEliece 348864, og over 4.000 ganger raskere nøkkelgenerering ifølge Decent Cybersecurity sitt 2026-benchmark.
Men for det smale, viktige segmentet der en nøkkel genereres én gang og deretter lever i årevis, snur bildet seg. Der vinner Classic McEliece på ren sikkerhetshistorikk og en imponerende liten chiffertekst. Konklusjonen for de fleste organisasjoner blir derfor ikke “enten eller”, men et bevisst valg av verktøy til jobben: ML-KEM som arbeidshesten for daglig trafikk, og Classic McEliece som en spesialisert reserveløsning for de få systemene der 47 års kryptoanalytisk tillit veier tyngre enn nøkkelstørrelsen.
Sett i et litt lengre perspektiv illustrerer denne sammenligningen noe viktigere enn bare to algoritmers spesifikasjoner. Overgangen til post-kvante-kryptografi handler ikke om å finne én vinner som løser alt, slik mange forventet da NIST-konkurransen startet. Den handler om å bygge et økosystem der flere matematiske tilnærminger dekker ulike behov, akkurat slik AES og RSA i sin tid utfylte hverandre i klassisk kryptografi. ML-KEM har vunnet kappløpet om å bli standarden for daglig internett-trafikk, mens Classic McEliece venter tålmodig i kulissene til de sjeldne, men kritiske, tilfellene der 47 års motstandsdyktighet er verdt prisen i nøkkelstørrelse.
Ofte stilte spørsmål
Er ML-KEM det samme som Kyber?
Ja. Kyber var kodenavnet under NIST-konkurransen, og ML-KEM er det offisielle navnet etter standardiseringen i FIPS 203 i august 2024. De to navnene brukes fortsatt om hverandre i mange verktøy og biblioteker, og du vil se begge deler i loggfiler, konfigurasjonsfiler og dokumentasjon i lang tid fremover.
Hvorfor er Classic McEliece-nøkler så mye større enn ML-KEM-nøkler?
McEliece bygger på feilrettende koder, der sikkerheten krever en stor matrise for å beskrive koden. ML-KEM bygger på gitterstrukturer som kan representeres langt mer kompakt matematisk, selv ved tilsvarende sikkerhetsnivå.
Kan jeg bruke Classic McEliece i en vanlig nettleser i dag?
Ikke i praksis. Ingen store nettlesere tilbyr McEliece som standard nøkkelutveksling i TLS, blant annet fordi den store offentlige nøkkelen ville gjort hvert nytt håndtrykk unødvendig tregt og dyrt i båndbredde.
Er ML-KEM trygt å bruke alene, uten en klassisk algoritme i tillegg?
Mange organisasjoner, inkludert Cloudflare og Google Chrome, kjører fortsatt hybridmodus der ML-KEM kombineres med X25519. Det gir beskyttelse selv om en svakhet i gittermatematikken skulle oppdages i fremtiden, og er i praksis standardanbefalingen for de fleste produksjonssystemer i 2026.
Når blir Classic McEliece en ferdig FIPS-standard?
Algoritmen befinner seg i NIST sin fjerde standardiseringsrunde per 2025, og det finnes ingen offentlig bekreftet dato for en endelig FIPS-standard ennå.
Koster det noe å implementere Classic McEliece eller ML-KEM?
Nei. Begge algoritmene er patentfrie og royaltyfrie. Teamet bak Classic McEliece har offisielt erklært at de verken har eller planlegger patenter, og eventuelle tidligere patenter i samme fagfelt er trukket tilbake.
Hvilken algoritme bør et lite norsk selskap starte med?
For de aller fleste selskaper holder det å sørge for at nettservere og SSH-klienter støtter ML-KEM gjennom oppdaterte biblioteker som OpenSSL 3.5 eller OpenSSH 10.0. Classic McEliece er relevant kun for spesialiserte behov som langtidsarkivering, og de fleste mindre virksomheter vil aldri trenge å implementere den direkte selv.
Påvirker valget av algoritme ytelsen til sluttbrukeren merkbart?
For ML-KEM er svaret nei, operasjonene tar mikrosekunder og merkes ikke i vanlig nettlesing. For Classic McEliece kan nøkkelgenereringen ta titalls millisekunder eller mer, noe som er uproblematisk når den skjer sjelden, men uegnet for hyppig bruk. I begge tilfeller er selve innkapslingen og dekapslingen, altså det som skjer for hver melding etter at nøkkelen finnes, rask nok til å være umerkbar for en vanlig bruker.
