Da NIST publiserte FIPS 203 den 13. august 2024, fikk verden endelig en offisiell standard for post-kvante nøkkelinnkapsling: ML-KEM, bedre kjent under utviklingsnavnet Kyber. Men lenge før den datoen hadde OpenSSH allerede tatt et helt annet valg. I april 2022, tre måneder før NIST i det hele tatt kunngjorde hvilken algoritme som vant konkurransen, gjorde OpenSSH 9.0 en variant av NTRU Prime kalt sntrup761 til standard nøkkelutveksling for millioner av servere. To konkurrerende gitterbaserte krypteringsfamilier, to helt ulike veier til produksjon.
Nå, i 2026, har brikkene falt på plass. ML-KEM er NIST-standardisert og kjørt i Chrome, Cloudflare og de fleste skytjenester. NTRU Prime lever videre i eldre SSH-installasjoner, men er selv i ferd med å bli faset ut til fordel for ML-KEM. Denne artikkelen går gjennom tallene, kildekoden og de faktiske utrullingene som avgjør hvilken av de to du bør bruke i 2026, og hvorfor svaret ikke lenger er like åpent som det var i 2022.
Bakgrunnen for hele diskusjonen er det som gjerne kalles “harvest now, decrypt later”: en angriper som lagrer kryptert trafikk i dag, kan i teorien dekryptere den senere med en tilstrekkelig kraftig kvantedatamaskin. Klassiske nøkkelutvekslinger som RSA og elliptisk kurve-kryptografi (som X25519 og P-256) knekkes i teorien av Shors algoritme dersom en slik maskin bygges. Både ML-KEM og NTRU/NTRU Prime er designet for å motstå akkurat dette scenarioet, men de har tatt svært forskjellige veier fra forskningspapir til produksjonskode, og det er den reisen denne sammenligningen handler om.
Hva er ML-KEM og NTRU/NTRU Prime?
Begge algoritmene løser det samme problemet: hvordan to parter kan bli enige om en delt hemmelighet over et usikret nettverk, uten at en fremtidig kvantedatamaskin kan knekke utvekslingen i ettertid. Begge bygger på gitterbasert kryptografi (lattice-based cryptography), men de bruker forskjellige matematiske strukturer under panseret. Begge kalles formelt for KEM-er, key-encapsulation mechanisms, et litt annet konsept enn tradisjonell nøkkelutveksling som Diffie-Hellman. I en KEM genererer den ene parten et nøkkelpar, den andre bruker den offentlige nøkkelen til å “kapsle inn” en tilfeldig hemmelighet i en chiffertekst, og den første parten “pakker ut” chifferteksten med sin private nøkkel for å komme frem til samme hemmelighet. Det er denne innkapslings- og utpakkingsprosessen ytelsestallene lenger ned i artikkelen faktisk måler.
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) er etterfølgeren til Kyber, gitteralgoritmen NIST valgte som vinner i sin post-kvante-konkurranse i juli 2022. ML-KEM bygger på et problem kalt Module Learning With Errors (Module-LWE), og ble endelig standardisert som FIPS 203 13. august 2024, ifølge NIST selv. Algoritmen finnes i tre parametersett: ML-KEM-512, ML-KEM-768 og ML-KEM-1024, med økende sikkerhetsnivå og nøkkelstørrelse.
NTRU, og undervarianten NTRU Prime, er eldre konstruksjoner som bygger på et annet gitterproblem knyttet til polynomringer. NTRU ble faktisk vurdert av NIST som en av finalistene i tredje runde av konkurransen, men ble ikke valgt som endelig standard. NTRU Prime, en variant designet av blant andre Daniel J. Bernstein for å fjerne visse strukturelle egenskaper ved klassisk NTRU, ble aldri sendt inn til NIST i det hele tatt. Likevel er det nettopp NTRU Prime-varianten sntrup761 som i praksis er den mest utbredte post-kvante-KEM-en i verden i dag, fordi OpenSSH valgte den lenge før ML-KEM var klar.
Forskjellen mellom de underliggende matematiske problemene er verdt å forstå, siden den forklarer mye av ytelsesgapet lenger ned i artikkelen. Module-LWE, som ML-KEM bruker, jobber med strukturerte matriser av polynomer der usikkerheten kommer fra tilsatt “støy” i lineære ligninger, noe som lar seg regne ut med enkle addisjons- og multiplikasjonsoperasjoner som er lette å vektorisere på moderne CPU-er. NTRU sitt problem, kjent som “kortest vektor i et NTRU-gitter”, krever i stedet å invertere polynomer i en ring modulo et primtall, en operasjon som er tyngre å implementere effektivt, spesielt under nøkkelgenerering. Begge er ansett som robuste av kryptografimiljøet, men den ene lar seg regne raskere ut i praksis, som benchmark-tallene lenger ned viser.
Standardiseringsstatus: FIPS 203 mot ingen NIST-standard
Den viktigste forskjellen mellom de to er ikke matematikken, men papirarbeidet. ML-KEM har en offisiell amerikansk føderal standard (FIPS 203) bak seg, publisert av NIST 13. august 2024. Det betyr at ML-KEM kan brukes i alt fra amerikanske myndighetssystemer til finansregulerte miljøer som krever FIPS-sertifiserte moduler.
Klassisk NTRU var en av finalistene i tredje og siste runde av NIST sin flerårige post-kvante-konkurranse, sammen med Kyber. I juli 2022 kunngjorde NIST at Kyber var valgt som den primære gitterbaserte KEM-standarden. Kyber ble deretter videreutviklet til den endelige FIPS 203-spesifikasjonen, ferdigstilt 13. august 2024, samme dag som signaturstandardene FIPS 204 og FIPS 205 ble publisert. NTRU var altså med helt til finalen, men tapte til slutt mot en konkurrent bygget på et beslektet, men beregningsmessig enklere matematisk problem.
NTRU Prime har ingen tilsvarende status. Verken sntrup761 eller de klassiske NTRU-variantene som ntruhps2048677 og ntruhrss701 er valgt som NIST-standarder. Klassisk NTRU var med i tredje runde av NIST-konkurransen, men tapte mot Kyber (nå ML-KEM). NTRU Prime ble aldri en gang sendt inn til NIST-prosessen. Det betyr at organisasjoner med krav om FIPS-samsvar i praksis ikke kan bruke NTRU Prime som eneste kryptografiske grunnlag, uansett hvor godt algoritmen presterer teknisk.
Dette er et paradoks verdt å dvele ved: den mest brukte post-kvante-KEM-en i verden akkurat nå, sntrup761 i OpenSSH, er ikke en gang en kandidat i den offisielle standardiseringsprosessen. Den ble et de facto-standard gjennom utbredt bruk, ikke gjennom komitévedtak. Det sier noe viktig om forskjellen mellom akademisk standardisering og praktisk utrulling: en algoritme kan bli allestedsnærværende lenge før den har noe offisielt stempel, rett og slett fordi noen måtte løse et reelt sikkerhetsproblem før standarden var klar. NTRU Prime sin posisjon minner om hvordan enkelte de facto-webstandarder spredte seg gjennom nettlesere lenge før W3C formaliserte dem, bare at konsekvensene her handler om kryptografisk sikkerhet i stedet for webdesign.
Nøkkelstørrelser og ytelse: full sammenligningstabell
Tallene under er hentet fra offisielle spesifikasjoner: NIST FIPS 203 og RFC 9935 for ML-KEM, NTRU Prime-spesifikasjonen samt Open Quantum Safe-biblioteket for de øvrige NTRU-variantene, og RFC 9941 for de kombinerte hybridstørrelsene som faktisk sendes over nettverket i SSH og TLS.
| Algoritme | Offentlig nøkkel | Chiffertekst | NIST-nivå | Standardisert | Reelt sikkerhetsnivå |
|---|---|---|---|---|---|
| ML-KEM-512 | 800 byte | 768 byte | Nivå 1 | Ja (FIPS 203) | ~AES-128 |
| ML-KEM-768 | 1 184 byte | 1 088 byte | Nivå 3 | Ja (FIPS 203) | ~AES-192 |
| ML-KEM-1024 | 1 568 byte | 1 568 byte | Nivå 5 | Ja (FIPS 203) | ~AES-256 |
| NTRU Prime sntrup761 | 1 158 byte | 1 039 byte | Ikke NIST-kategorisert | Nei | ~128-bit klassisk |
| NTRU ntruhps2048677 | 930 byte | 930 byte | Nivå 1 (NIST IR 8413) | Nei (tapte runde 3) | ~AES-128 |
| NTRU ntruhrss701 | 1 138 byte | 1 138 byte | Nivå 1 (NIST IR 8413) | Nei (tapte runde 3) | ~AES-128 |
| X25519 (klassisk, referanse) | 32 byte | 32 byte | Ikke kvantesikker | Ja (RFC 7748) | ~128-bit klassisk |
| X25519 + sntrup761 hybrid (SSH) | 1 190 byte | 1 071 byte | Ikke NIST-kategorisert | Delvis (X25519-delen ja) | ~128-bit + kvantesikker |
| X25519 + ML-KEM-768 hybrid (TLS/SSH) | 1 216 byte | 1 120 byte | Nivå 3 | Ja (FIPS 203 + RFC 7748) | ~AES-192 + kvantesikker |
| X25519 + ML-KEM-1024 hybrid | 1 600 byte | 1 600 byte | Nivå 5 | Ja (FIPS 203 + RFC 7748) | ~AES-256 + kvantesikker |
Legg merke til at ML-KEM-768, det parametersettet nettlesere og CDN-er faktisk bruker, har en offentlig nøkkel på nesten samme størrelse som sntrup761 (1 184 mot 1 158 byte), mens chifferteksten er litt større (1 088 mot 1 039 byte). På ren størrelse er de to altså i samme størrelsesklasse. Forskjellen ligger i beregningshastighet, ikke i pakkestørrelse.
Til sammenligning er en klassisk X25519-nøkkel bare 32 byte, så en hybrid som X25519MLKEM768 legger til rundt 1 184 byte offentlig nøkkel og 1 088 byte chiffertekst sammenlignet med en ren klassisk forbindelse, altså litt over to kilobyte ekstra data per håndtrykk. For de aller fleste nettsteder er dette et neglisjerbart tillegg sammenlignet med resten av en typisk TLS-forbindelse eller en gjennomsnittlig nettside, men det kan bli en reell faktor for svært ressursbegrensede enheter som IoT-utstyr eller innebygde systemer med strenge båndbreddebudsjetter, der hvert ekstra kilobyte teller.
Ytelsesbenchmark: hvor mye raskere er ML-KEM?
Den klareste ytelsesforskjellen kommer fra en sammenligningstabell presentert på IETF sitt CFRG-møte (meeting 125), der NTRU Prime og ML-KEM ble kjørt side om side med AVX2-optimalisert kode på en Intel Core i9-11900K med klokkefrekvens 3,5 GHz. Tallene er oppgitt i tusen CPU-sykler (kcycles) per operasjon.
| Operasjon | NTRU Prime | ML-KEM | Forskjell |
|---|---|---|---|
| Nøkkelgenerering | 610 000 sykler | 21 000 sykler | ML-KEM ca. 29x raskere |
| Innkapsling (encaps) | 80 000 sykler | 22 000 sykler | ML-KEM ca. 3,6x raskere |
| Utpakking (decaps) | 103 000 sykler | 24 000 sykler | ML-KEM ca. 4,3x raskere |
Forskjellen på nøkkelgenerering er slående: ML-KEM er nesten 29 ganger raskere. Det handler om hvordan Module-LWE-strukturen i ML-KEM lar seg implementere med enkel, vektoriserbar polynomaritmetikk, mens NTRU og NTRU Prime krever tyngre operasjoner knyttet til polynom-invertering under nøkkelgenerering. For servere som håndterer tusenvis av nye TLS- eller SSH-forbindelser i sekundet, er dette ikke bare et akademisk poeng. En separat måling fra USENIX Security 2024, der forskere sammenlignet TLS 1.3-håndtrykk med X25519 mot P-256 i en helt annen sammenheng, viste 1 366 forbindelser i sekundet for X25519 mot 1 260 for P-256, som illustrerer hvor mye selv små algoritmevalg betyr for gjennomstrømning på travle servere.
Open Quantum Safe-prosjektet (liboqs) publiserer også løpende ytelsesmålinger for begge familiene, men uten et samlet ML-KEM-mot-NTRU-oppsett i én tabell. Konklusjonen fra flere uavhengige kilder peker likevel samme vei: ML-KEM sin Module-LWE-konstruksjon er beregningsmessig lettere enn NTRU sin polynomringstruktur, spesielt under nøkkelgenerering.
Hvor mye dette betyr i praksis, avhenger av bruksmønsteret. I TLS 1.3 genereres et nytt, midlertidig nøkkelpar for hver eneste håndtrykk, som en del av forward secrecy-designet i protokollen. Det betyr at nøkkelgenereringskostnaden betales på nytt for hver forbindelse, noe som gjør akkurat den 29 gangers forskjellen svært relevant for en travel webserver eller API-gateway. I SSH er bildet litt annerledes, siden en SSH-server typisk håndterer færre nye forbindelser per sekund enn en offentlig webserver, men selv der merkes forskjellen på store CI/CD-systemer eller Git-tjenester som GitHub, hvor tusenvis av korte SSH-økter åpnes og lukkes kontinuerlig gjennom en arbeidsdag.
Sikkerhetsnivåer og NIST-kategorier
NIST definerer fem sikkerhetskategorier for post-kvante-algoritmer, forankret i hvor mye regnekraft som kreves for å knekke en tilsvarende klassisk chiffer. ML-KEM-512 tilsvarer kategori 1 (omtrent som å knekke AES-128), ML-KEM-768 tilsvarer kategori 3 (omtrent AES-192), og ML-KEM-1024 tilsvarer kategori 5 (omtrent AES-256). Dette er eksplisitt dokumentert i FIPS 203-spesifikasjonen.
NTRU-variantene har ikke offisielle NIST-kategorier siden de ikke ble valgt, men NIST sin egen statusrapport for tredje runde (NIST IR 8413) plasserer ntruhps2048677 og ntruhrss701 på nivå 1, altså omtrent på linje med ML-KEM-512. sntrup761, som er varianten som faktisk brukes i produksjon via OpenSSH, er designet for et sikkerhetsnivå tilsvarende omtrent 128-bit klassisk sikkerhet, sammenlignbart med ML-KEM-512, men uten en formell NIST-kategori å vise til.
For et praktisk perspektiv: den mest utbredte NTRU-varianten i verden (sntrup761) og den mest utbredte ML-KEM-varianten i nettlesere (ML-KEM-768) er ikke direkte sammenlignbare på sikkerhetsnivå, siden sntrup761 typisk pares med nivå 1-styrke, mens ML-KEM-768 ligger på nivå 3. Det er en av grunnene til at direkte “hvem er tryggest”-sammenligninger må ta hensyn til hvilket parametersett som faktisk er i bruk, ikke bare algoritmefamilien.
Dette har en praktisk konsekvens for organisasjoner som planlegger overgang: å bytte fra sntrup761x25519 til mlkem768x25519 er ikke bare et algoritmebytte, det er også en oppgradering av sikkerhetsnivå fra omtrent nivå 1 til nivå 3. For de fleste formål er det en ren gevinst, men det betyr også litt større nøkler og litt mer beregningsarbeid enn et rent nivå 1-til-nivå-1-bytte ville gitt. Dersom man ønsker et mer like-for-like-bytte, er ML-KEM-512 det parametersettet som ligger nærmest sntrup761 i sikkerhetsnivå, selv om ML-KEM-768 er det som faktisk er blitt bransjestandarden i nettlesere og CDN-er.
OpenSSH-historien: fra sntrup761 til ML-KEM på fire år
Ingen annen historie illustrerer bedre hvordan disse to algoritmene har konkurrert i den virkelige verden enn utviklingen i OpenSSH, dokumentert i prosjektets egne spesifikasjoner og utgivelsesnotater. OpenSSH er verdt å bruke som case nettopp fordi prosjektet har måttet ta stilling til begge algoritmene i faktisk produksjonskode, ikke bare i forskningspapirer, og fordi hver overgang er tidsstemplet og offentlig dokumentert i utgivelsesloggen.
| Dato | OpenSSH-versjon | Endring |
|---|---|---|
| Mars 2021 | OpenSSH 8.5 | sntrup761x25519-sha512 lagt til, men avslått som standard |
| April 2022 | OpenSSH 9.0 | sntrup761x25519-sha512 blir standard nøkkelutveksling |
| 2024 | OpenSSH 9.9 | mlkem768x25519-sha256 lagt til som nytt alternativ |
| April 2025 | OpenSSH 10.0 | mlkem768x25519-sha256 blir ny standard, avløser NTRU Prime |
Legg merke til tidslinjen: OpenSSH gjorde NTRU Prime til standard i april 2022, tre måneder før NIST offentliggjorde at Kyber (ML-KEM) hadde vunnet konkurransen i juli 2022. OpenSSH-utviklerne kunne rett og slett ikke vente på en standard som ikke fantes ennå, og NTRU Prime var det mest velprøvde alternativet tilgjengelig på det tidspunktet. Da FIPS 203 endelig var klar i 2024 og implementasjoner modnet, snudde OpenSSH-prosjektet innen tre år og gjorde ML-KEM til ny standard fra versjon 10.0. Det er et konkret, dokumentert eksempel på at industrien selv har validert at ML-KEM er det langsiktige valget, selv der NTRU Prime kom først.
GitHub fulgte et lignende mønster fra motsatt retning: selskapet aktiverte sntrup761x25519-sha512 for SSH-tilgang til Git-data 17. september 2025, lenge etter at ML-KEM allerede var tilgjengelig, nettopp fordi sntrup761 fortsatt er bredt støttet i eldre SSH-klienter som ikke har fått ML-KEM-støtte ennå. De to algoritmene lever altså side om side i en overgangsperiode som trolig varer flere år til.
Verdt å merke seg er at OpenSSH aldri har fjernet sntrup761x25519 fra kodebasen, selv etter at mlkem768x25519-sha256 ble ny standard i versjon 10.0. I stedet degraderte prosjektet NTRU Prime til et sekundært, fortsatt aktivt tilbud. Denne “behold det gamle, legg til det nye”-strategien er trolig den viktigste enkeltårsaken til at sntrup761 fortsatt er så utbredt i 2026 til tross for at det ikke lenger er standardvalget: millioner av eksisterende servere har aldri blitt eksplisitt rekonfigurert, og fortsetter derfor å bruke det som var standard da de sist ble satt opp eller oppgradert.
Nettlesere, Signal og skytjenester: hvem har valgt hva
Utenfor SSH-verdenen er bildet enda tydeligere: nesten alle store forbrukervendte tjenester har landet på ML-KEM/Kyber-familien, ikke NTRU.
- Chrome: Versjon 124 (april 2024) aktiverte den før-standardiserte hybriden X25519Kyber768Draft00 som standard. Versjon 131 (6. november 2024) byttet til den ferdigstandardiserte X25519MLKEM768.
- Cloudflare: Har tilbudt post-kvante nøkkelutveksling gratis på alle abonnement, inkludert gratisplanen, siden en beta i oktober 2022. Selskapet har siden gått til generell tilgjengelighet med X25519MLKEM768 som anbefalt hybrid, ifølge selskapets egen SSL/TLS-dokumentasjon.
- Signal: Kunngjorde PQXDH-protokollen 19. september 2023. Den bruker CRYSTALS-Kyber, algoritmefamilien som senere ble standardisert som ML-KEM, ifølge Signals egen bloggpost.
- OpenSSH: Byttet fra NTRU Prime til ML-KEM som standard i versjon 10.0, april 2025, ifølge prosjektets egen dokumentasjon på post-kvante-kryptografi.
- GitHub: Støtter fortsatt sntrup761x25519-sha512 for bakoverkompatibilitet med eldre SSH-klienter, aktivert september 2025.
Mønsteret er konsistent: der en tjeneste kunne velge fritt uten historisk binding, landet den på ML-KEM. NTRU Prime sin gjenværende posisjon i økosystemet skyldes i stor grad at OpenSSH kom tidlig og skapte treghet, ikke at algoritmen vant på egne meritter i en åpen konkurranse.
Cloudflares egen begrunnelse er verdt å sitere direkte, fordi den fanger hvorfor så mange leverandører har rullet ut støtte selv før det var strengt tatt påkrevd. I den opprinnelige kunngjøringen fra oktober 2022 skrev selskapet at det tilbyr post-kvante-kryptografi gratis fordi det mener post-kvante-sikkerhet bør være den nye grunnlinjen for internett, ikke en betalt tilleggstjeneste. Den holdningen har i praksis blitt normen: ingen av de store CDN-ene eller nettleserne har forsøkt å ta ekstra betalt for beskyttelse mot fremtidige kvanteangrep, noe som har fjernet en av de vanligste barrierene mot rask utrulling av ny sikkerhetsteknologi.
Pris: hva koster det å bruke ML-KEM eller NTRU i skyen?
Begge algoritmene er åpne, royaltyfrie spesifikasjoner uten lisenskostnad. Den reelle kostnaden ligger i hvilke tjenester som støtter dem, og om leverandørene tar seg betalt ekstra for post-kvante-operasjoner sammenlignet med klassiske RSA- eller ECDSA-operasjoner.
| Leverandør | Pris for nøkkeloperasjoner | Ekstra kostnad for PQC/ML-KEM | Kilde |
|---|---|---|---|
| AWS KMS | $1 per nøkkel/måned + $0,03 per 10 000 forespørsler (symmetrisk) | Ingen egen linje for PQC dokumentert | aws.amazon.com/kms/pricing |
| Google Cloud KMS | $0,06 per aktiv programvarenøkkel/måned + $0,03 per 10 000 operasjoner | Ingen egen linje for PQC dokumentert | cloud.google.com/kms/pricing |
| Azure Key Vault | $0,03 per 10 000 operasjoner (programvarenøkler) | Ingen egen linje for PQC dokumentert | azure.microsoft.com/pricing/key-vault |
| Cloudflare (alle planer inkl. gratis) | Inkludert i eksisterende TLS-tjeneste | Gratis siden oktober 2022-beta | blog.cloudflare.com/post-quantum-for-all |
| OpenSSH / GitHub SSH | Gratis, åpen kildekode | Ingen | openssh.com/pq.html |
Det påfallende funnet her er fraværet av prisforskjell. Verken AWS KMS, Google Cloud KMS eller Azure Key Vault har publisert egne prislinjer for ML-KEM-operasjoner utover den vanlige asymmetriske nøkkelprisen, ifølge leverandørenes egne offisielle prissider. Cloudflare har til og med gått motsatt vei og eksplisitt lovet at post-kvante-kryptografi skal være gratis, fordi selskapet mener post-kvante-sikkerhet bør være den nye grunnlinjen for internett, som det ble formulert i selskapets opprinnelige kunngjøring fra 2022. For virksomheter som vurderer migrering, betyr dette at kostnaden ved overgang til ML-KEM i praksis er null i lisens- og driftsavgifter. Den reelle kostnaden ligger i utviklertid, testing og eventuell båndbreddeøkning fra litt større nøkler.
Et konkret eksempel på hvor liten den reelle kostnadsforskjellen er: AWS KMS tar $1 per nøkkel i måneden uansett om nøkkelen er symmetrisk eller asymmetrisk, og forespørsler mot asymmetriske nøkler er ekskludert fra gratistaket på 20 000 forespørsler i måneden, men prisen i seg selv er ikke knyttet til hvilken spesifikk algoritme som brukes. Google Cloud KMS følger samme mønster: $0,06 i måneden per aktiv programvarenøkkelversjon og $0,03 per 10 000 kryptografiske operasjoner, uavhengig av om operasjonen er RSA, ECC eller en fremtidig ML-KEM-implementasjon. Så lenge skyleverandørene fortsetter denne praksisen, er valget mellom ML-KEM og NTRU Prime et rent teknisk og sikkerhetsmessig spørsmål, ikke et budsjettspørsmål.
Fordeler og ulemper med ML-KEM
ML-KEM sin største styrke er at den er den eneste av de to som faktisk er en offisiell standard. FIPS 203 gir organisasjoner et papirspor de kan vise til i revisjoner, anbudsprosesser og compliance-rapporter. Ytelsesmessig er ML-KEM dramatisk raskere på nøkkelgenerering (opptil 29 ganger, som vist over) og moderat raskere på innkapsling og utpakking. Økosystemstøtten er også bredest: Chrome, Firefox, Cloudflare, Signal og fra april 2025 også OpenSSH bruker ML-KEM eller er i ferd med å gå over.
Ulempen er at ML-KEM er en yngre, mindre gjennomtestet konstruksjon i produksjon sammenlignet med NTRU-familien, som har vært gjenstand for kryptoanalyse i over 25 år. Modul-LWE-problemet ML-KEM bygger på har fått mindre “battle-testing” i faktisk drift enn den eldre NTRU-strukturen, selv om det matematiske fundamentet er svært godt studert akademisk gjennom NIST-konkurransen. ML-KEM-1024, det mest sikre parametersettet, har også noe større nøkler enn tilsvarende NTRU-varianter på samme sikkerhetsnivå. En annen praktisk ulempe er at ikke alle eldre klienter og biblioteker støtter ML-KEM ennå, noe som betyr at organisasjoner med stor variasjon i klientparken må kjøre hybride oppsett med fallback til klassisk kryptografi i en overgangsperiode, akkurat slik GitHub og OpenSSH gjør for NTRU Prime i dag.
Fordeler og ulemper med NTRU og NTRU Prime
NTRU sin store fordel er modenhet. Den opprinnelige NTRU-konstruksjonen har eksistert siden midten av 1990-tallet, og NTRU Prime-varianten sntrup761 har vært i skarp produksjonsbruk i OpenSSH siden 2022, uten kjente praktiske brudd. For organisasjoner som allerede har eldre systemer avhengig av sntrup761x25519, er algoritmen fortsatt et solid, velprøvd valg mens overgangen til ML-KEM planlegges. Den brede, årelange utrullingen gjennom OpenSSH betyr også at eventuelle implementasjonsfeil i populære biblioteker trolig ville ha blitt oppdaget og rapportert for lengst, noe som gir en viss praktisk trygghet utover selve den matematiske analysen.
Ulempene er tyngre. Fraværet av NIST-standardisering betyr at NTRU Prime er utelukket fra FIPS-regulerte miljøer. Ytelsen på nøkkelgenerering er betydelig svakere enn ML-KEM, noe som merkes på servere med høy forbindelsesrate. Og kanskje viktigst: selv prosjektet som gjorde NTRU Prime kjent i stor skala, OpenSSH, har nå byttet standardvalg til ML-KEM. Det er et sterkt signal om hvor økosystemet beveger seg, selv om sntrup761 fortsatt vil leve videre som reserveløsning i flere år. Klassisk NTRU, i motsetning til NTRU Prime, sliter i tillegg med enda svakere reell utbredelse: den ble aldri tatt i bruk i noen stor produksjonstjeneste etter å ha tapt NIST-konkurransen, og finnes i praksis bare i forsknings- og referanseimplementasjoner i dag.
Kjente sikkerhetsbetraktninger
Ingen av algoritmene har kjente praktiske brudd per 2026. ML-KEM, som Module-LWE-basert konstruksjon, regnes av NIST som den mest gjennomgåtte gitter-KEM-en i hele standardiseringsprosessen, med et sikkerhetsbevis som reduserer angrep på algoritmen til det underliggende Module-LWE-problemet. NTRU og NTRU Prime bygger på en litt annen gitterstruktur knyttet til polynomringer, og har vært gjenstand for tiår med akademisk kryptoanalyse uten at parametersettene som brukes i produksjon (som sntrup761) er blitt brutt.
Det er verdt å understreke at “ingen kjente brudd” ikke er det samme som “matematisk bevist trygt for alltid”. Gitterbasert kryptografi er en yngre gren av faget enn for eksempel RSA og elliptisk kurve-kryptografi, og både ML-KEM og NTRU-familien kan i teorien vise seg sårbare for angrepsmetoder ingen har oppdaget ennå. Det er nettopp derfor hybridkonstruksjonen med X25519 er så viktig i praksis: den gjør at en eventuell fremtidig svakhet i selve gitterproblemet ikke alene er nok til å bryte forbindelsen, siden angriperen da også må knekke den klassiske komponenten.
Et poeng som ofte trekkes frem i sammenligninger er at NTRU sin opprinnelige gitterstruktur har visse algebraiske egenskaper som gjorde at NTRU Prime-designerne bevisst fjernet dem for å redusere den teoretiske angrepsflaten. Det er nettopp derfor NTRU Prime, ikke klassisk NTRU, ble valgt av OpenSSH-teamet i utgangspunktet. Uansett hvilken algoritme man velger, anbefaler nesten alle produksjonsimplementasjoner en hybridkonstruksjon, altså å kombinere post-kvante-KEM-en med en klassisk kurve som X25519, slik at systemet forblir sikkert selv om én av de to matematiske antagelsene skulle vise seg å være svak.
Hybridkonstruksjon: hvorfor ingen kjører ren post-kvante-kryptografi ennå
Verken sntrup761x25519, mlkem768x25519 eller X25519MLKEM768 er “rene” post-kvante-algoritmer. Alle tre kombinerer en post-kvante-KEM med den klassiske elliptiske kurven X25519. Dette designvalget er bevisst og gjennomgående i hele bransjen: dersom en fremtidig forsker finner en svakhet i Module-LWE eller i NTRU-gitterproblemet, faller sikkerheten tilbake til den velprøvde 128-bit sikkerheten X25519 allerede gir mot klassiske angripere. Motsatt, dersom en kvantedatamaskin bygges og knekker X25519, er forbindelsen fortsatt beskyttet av post-kvante-komponenten.
Denne “beviste sikkerhet i verste fall”-tankegangen er grunnen til at verken Chrome, Cloudflare, Signal eller OpenSSH har rullet ut ML-KEM eller NTRU Prime alene, uten en klassisk komponent ved siden av. Det er også derfor overgangen fra sntrup761x25519 til mlkem768x25519 i praksis bare handler om å bytte ut post-kvante-halvparten av hybriden. X25519-halvparten forblir uendret gjennom hele migreringen, noe som reduserer risikoen for at overgangen introduserer nye sårbarheter i selve nøkkelutvekslingsprotokollen.
Fem virkelige brukstilfeller og hvilken algoritme som passer
Valget mellom ML-KEM og NTRU Prime avhenger sterkt av hva du faktisk bygger. Her er seks konkrete scenarioer basert på hvordan algoritmene faktisk brukes i produksjon i dag.
- Ny TLS-infrastruktur for et nettsted eller API: Bruk ML-KEM-768 i hybrid med X25519 (X25519MLKEM768). Dette er allerede standarden Chrome, Firefox og Cloudflare bruker, og du unngår kompatibilitetsproblemer med moderne klienter.
- SSH-tilgang til eldre servere med gammel OpenSSH-versjon: sntrup761x25519-sha512 er fortsatt riktig valg dersom serverparken kjører OpenSSH eldre enn 9.9, siden ML-KEM-støtte først kom i 9.9 og ble standard i 10.0.
- Nye SSH-oppsett fra bunnen av i 2026: Oppgrader til OpenSSH 10.0 eller nyere og bruk mlkem768x25519-sha256 som standard, med sntrup761x25519 som reserve for klienter som ikke støtter ML-KEM ennå.
- FIPS-regulerte miljøer (offentlig sektor, finans, forsvar): ML-KEM er eneste alternativ som oppfyller FIPS 203-kravet. NTRU Prime kan ikke brukes som primær mekanisme i slike miljøer, uansett hvor godt algoritmen presterer teknisk.
- Meldingsapper og ende-til-ende-kryptert kommunikasjon: Følg Signal sitt eksempel og bruk Kyber/ML-KEM-familien i en PQXDH-lignende hybridkonstruksjon med klassisk elliptisk kurve-kryptografi som bunnplanke.
- Interne mikrotjenester og API-gatewayer med høy forbindelsesrate: Prioriter ML-KEM fremfor NTRU Prime her, siden den 29 ganger raskere nøkkelgenereringen (fra IETF-benchmarken over) monner mest på tjenester som håndterer et stort antall nye forbindelser per sekund.
Migreringsguide: fra NTRU Prime til ML-KEM
For team som i dag kjører sntrup761x25519 og vurderer overgang til ML-KEM, følger her de praktiske trinnene basert på hvordan OpenSSH-prosjektet selv gjennomførte skiftet. Erfaringen fra både OpenSSH og Cloudflare viser at en trinnvis, hybrid utrulling der begge algoritmer støttes parallelt i en overgangsperiode, er tryggere enn et brått bytte, spesielt for tjenester med store og uensartede klientparker.
- Kartlegg hvilke systemer som i dag bruker sntrup761x25519-sha512, inkludert SSH-servere, TLS-termineringspunkter og interne tjenester.
- Oppgrader OpenSSH-klienter og -servere til minst versjon 9.9, som er første versjon med mlkem768x25519-sha256 tilgjengelig.
- Test at mlkem768x25519-sha256 fungerer i et ikke-produksjonsmiljø før du endrer standardinnstillinger, siden eldre klienter fortsatt kan mangle ML-KEM-støtte.
- Behold sntrup761x25519-sha512 som sekundært alternativ i KexAlgorithms-konfigurasjonen under overgangsperioden, slik GitHub gjør for bakoverkompatibilitet.
- For TLS-tjenester, aktiver X25519MLKEM768 som foretrukket hybrid-nøkkelutveksling der biblioteket støtter det (OpenSSL 3.2 og nyere, BoringSSL, samt de fleste moderne TLS-termineringer i CDN-er).
- Oppgrader til OpenSSH 10.0 eller nyere når klientparken tillater det, siden dette gjør ML-KEM til standard uten manuell konfigurasjon.
- Overvåk forbindelsesforsøk som fortsatt faller tilbake til rene klassiske algoritmer uten noen post-kvante-komponent, og prioriter å lukke disse hullene sist i migreringen.
- Dokumenter overgangen for eventuelle compliance-krav, spesielt dersom organisasjonen er underlagt FIPS- eller NIS2-relaterte rapporteringskrav.
- Planlegg en rollback-vei tilbake til sntrup761x25519 eller ren X25519 dersom mlkem768x25519 skulle vise seg å skape kompatibilitetsproblemer med spesifikke klienter, inntil hele klientparken er verifisert kompatibel.
Det er verdt å presisere at ingen av trinnene over krever at man fjerner klassisk kryptografi helt. Både sntrup761x25519 og mlkem768x25519 er hybridkonstruksjoner som beholder X25519 som klassisk sikkerhetsnett. Migreringen handler om å bytte hvilken post-kvante-komponent som er koblet på, ikke om å fjerne den velprøvde elliptiske kurven.
Cloudflare sin egen WARP-klient illustrerer hvor langt en slik utrulling kan komme når den gjøres trinnvis over tid: ifølge selskapets egen bloggpost bruker over en tredjedel av den menneskegenererte trafikken til Cloudflares nettverk allerede TLS 1.3 med post-kvante hybrid nøkkelutveksling. Det er et konkret tegn på at overgangen fra ren klassisk kryptografi til post-kvante-hybrider ikke lenger er et fremtidsscenario, men noe som allerede skjer i stor skala for vanlig internett-trafikk.
Kodeeksempel: sjekke støttede nøkkelutvekslingsalgoritmer i OpenSSH
For å se hvilke nøkkelutvekslingsalgoritmer din lokale SSH-installasjon faktisk støtter, og om ML-KEM allerede er tilgjengelig, kan du kjøre følgende kommando:
ssh -Q kex
# Se etter disse to linjene i output:
# [email protected]
# mlkem768x25519-sha256
# Sjekk hvilken algoritme som faktisk ble brukt i en aktiv tilkobling:
ssh -vv brukernavn@server 2>&1 | grep "kex: algorithm"Dersom du ser mlkem768x25519-sha256 i outputen fra ssh -Q kex, kjører du minst OpenSSH 9.9. Dersom kommandoen kun viser [email protected], er det et tegn på at klienten eller serveren bør oppgraderes for å få tilgang til den NIST-standardiserte ML-KEM-varianten.
Verdikt: hvilken bør du velge i 2026?
Tallene peker i én klar retning. ML-KEM vinner på standardiseringsstatus (eneste FIPS-godkjente alternativ), på ytelse (opptil 29 ganger raskere nøkkelgenerering ifølge IETF CFRG-benchmarken), og på økosystemstøtte (Chrome, Cloudflare, Signal og fra 2025 også OpenSSH selv). NTRU Prime sin eneste gjenværende fordel er at den allerede er utbredt i eldre SSH-installasjoner, en fordel som svinner år for år etter hvert som OpenSSH 10.0 og nyere blir standard.
For ny infrastruktur i 2026 er anbefalingen entydig: bruk ML-KEM-768 i hybrid med X25519 (X25519MLKEM768) for TLS, og mlkem768x25519-sha256 for SSH der OpenSSH 9.9 eller nyere er tilgjengelig. NTRU Prime sin rolle fremover blir i praksis den samme som RSA sin rolle i dag: et bakoverkompatibelt reservealternativ for systemer som ennå ikke er oppgradert, ikke et aktivt førstevalg for nye implementasjoner. At selv OpenSSH-prosjektet, organisasjonen som gjorde NTRU Prime til allmenn standard i utgangspunktet, byttet til ML-KEM som standardvalg i april 2025, er kanskje det klareste beviset på hvor bransjen faktisk lander.
Hva betyr dette for norske og nordiske virksomheter?
For norske virksomheter kommer valget mellom ML-KEM og NTRU Prime sjelden isolert. Digitalsikkerhetsloven, som gjennomfører NIS2-direktivet i norsk rett, stiller krav til risikostyring og dokumentert sikkerhetsarbeid for virksomheter i en rekke sektorer, og kryptografiske valg er en naturlig del av den dokumentasjonen. Siden ML-KEM er den eneste av de to algoritmene med en anerkjent internasjonal standard bak seg, blir det i praksis det enkleste valget å forsvare i en revisjon eller tilsynssak, uavhengig av om selve trusselbildet fra kvantedatamaskiner ennå er nært forestående.
Samtidig er de fleste norske og nordiske virksomheter i praksis konsumenter av kryptografien andre har valgt for dem, ikke implementører fra bunnen av. En bedrift som bruker Cloudflare foran nettstedet sitt, får X25519MLKEM768 automatisk og kostnadsfritt. En organisasjon som drifter egne Linux-servere med SSH-tilgang, arver derimot valget OpenSSH-prosjektet har tatt, og bør derfor sørge for at serverparken kjører versjon 9.9 eller nyere for å faktisk få tilgang til ML-KEM-alternativet, i stedet for å bli stående igjen på NTRU Prime uten et bevisst valg om det.
Ofte stilte spørsmål
Er NTRU Prime usikkert siden det ikke er NIST-standardisert?
Nei, det finnes ingen kjente praktiske brudd på sntrup761. Fraværet av NIST-standardisering handler om at algoritmen aldri ble sendt inn til konkurransen, ikke at den ble avvist på sikkerhetsgrunnlag.
Kan jeg bruke ML-KEM og NTRU Prime samtidig i samme system?
Ja, og det er faktisk vanlig praksis under en overgangsperiode. GitHub støtter for eksempel begge algoritmene parallelt for SSH-tilgang, avhengig av hva klienten støtter.
Hvorfor pares post-kvante-algoritmer alltid med X25519?
Dette kalles en hybridkonstruksjon. Dersom det skulle vise seg at Module-LWE eller NTRU-gitterproblemet har en svakhet ingen har oppdaget ennå, er forbindelsen fortsatt beskyttet av den velprøvde klassiske X25519-kurven, og omvendt mot fremtidige kvantedatamaskiner.
Koster det mer å bruke ML-KEM enn klassisk RSA eller ECDSA i skyen?
Basert på offentlig prising fra AWS, Google Cloud og Azure per 2026 er det ingen egen prislinje for ML-KEM-operasjoner. Cloudflare tilbyr post-kvante nøkkelutveksling gratis på alle abonnement, inkludert gratisplanen.
Når bør jeg oppgradere fra sntrup761x25519 til mlkem768x25519?
Så snart klientparken din støtter OpenSSH 9.9 eller nyere. Behold sntrup761 som reservealternativ til alle klienter er oppgradert, siden det fortsatt gir bedre beskyttelse enn ren klassisk kryptografi.
Er ML-KEM-1024 nødvendig for de fleste, eller holder ML-KEM-768?
ML-KEM-768 er parametersettet browsere, CDN-er og skyleverandører har konvergert på som standard, og tilsvarer omtrent AES-192-sikkerhet. ML-KEM-1024 er primært relevant for spesielt høyverdi-data med lang levetidskrav.
Bruker Signal ML-KEM eller den eldre Kyber-varianten?
Signals PQXDH-protokoll, kunngjort 19. september 2023, bruker CRYSTALS-Kyber, algoritmefamilien NIST senere standardiserte som ML-KEM.
Hva skjer med klassisk NTRU, ikke NTRU Prime, fremover?
Klassisk NTRU (ntruhps2048677, ntruhrss701) tapte i NIST sin tredje runde og har svært begrenset reell utbredelse sammenlignet med NTRU Prime-varianten sntrup761, som i praksis er den eneste NTRU-familien med betydelig produksjonsbruk i dag.
Er NTRU Prime og NTRU det samme?
Nei. NTRU Prime er en egen variant designet for å fjerne visse algebraiske strukturer i det klassiske NTRU-gitteret, med sikte på å redusere den teoretiske angrepsflaten. sntrup761, varianten OpenSSH bruker, tilhører NTRU Prime-familien, ikke klassisk NTRU.
Finnes det et backup-alternativ dersom ML-KEM sin matematikk skulle vise seg sårbar?
Ja. NIST har jobbet med et kodebasert alternativ ved siden av gitterbaserte KEM-er, nettopp for å unngå at all post-kvante-sikkerhet hviler på én matematisk antagelse. Se vår egen sammenligning av ML-KEM mot dette alternativet for mer om hvordan de to skiller seg i praksis.
