I april 2026 meldte Cloudflare at over 65 prosent av den menneskegenererte trafikken gjennom nettverket deres nå bruker kvanteresistent nøkkelutveksling. To år tidligere var tallet under 3 prosent. Det som driver denne veksten er én standard: ML-KEM, den nye NIST-godkjente etterfølgeren til RSA og Diffie-Hellman for nøkkelutveksling. Denne artikkelen setter ML-KEM opp mot RSA på nøkkelstørrelser, ytelse, pris og reell drift, og gir deg en konkret migreringsplan uansett om du drifter en nettside, en API eller en bankinfrastruktur i Norden.

Bakgrunnen er enkel å forstå, men konsekvensene er store. RSA har vært ryggraden i internett-sikkerhet siden 1977. Men en tilstrekkelig stor kvantecomputer som kjører Shors algoritme kan i teorien knekke RSA på timer, ikke årtusener. NIST publiserte derfor FIPS 203, 204 og 205 i august 2024, og bransjen har brukt de siste to årene på å bytte ut RSA og elliptisk kurve-kryptografi med kvanteresistente alternativer. ML-KEM vs RSA er nå et av de mest praktiske spørsmålene for utviklere, sikkerhetsarkitekter og drift-team i 2026.

Spørsmålet er ikke lenger om overgangen skjer, men hvor fort du selv bør henge deg på. Store deler av internett har allerede tatt valget for deg: nettleseren du bruker akkurat nå forhandler trolig en hybrid postkvante-nøkkel mot denne siden uten at du merker noe. Men bak kulissene krever det jobb. Sertifikater må fornyes, biblioteker må oppdateres, og gammelt utstyr må testes eller byttes ut. Denne artikkelen går gjennom nøkkelstørrelser, ytelsestall fra flere uavhengige kilder, konkrete priser fra AWS, Azure og Google Cloud, og en praktisk migreringsplan du kan følge steg for steg, enten du drifter én nettside eller hundrevis av interne tjenester.

Hva er RSA, og hvorfor er det på vei ut?

RSA (Rivest-Shamir-Adleman) bygger på et enkelt matematisk problem: det er lett å multiplisere to store primtall, men svært tungt å faktorisere produktet tilbake til de opprinnelige primtallene. Denne asymmetrien er grunnlaget for hele algoritmen. En RSA-2048-nøkkel har en modulus på 2048 bit, som tilsvarer 256 byte, og gir i praksis rundt 112 bit klassisk sikkerhet. RSA-3072 gir omtrent 128 bit sikkerhet med en modulus på 384 byte, mens RSA-4096 lander på rundt 150 bit sikkerhet med 512 byte.

Problemet er ikke at RSA er svakt mot dagens datamaskiner. Det er fortsatt praktisk umulig å faktorisere en RSA-2048-modulus med klassisk maskinvare. Problemet er Shors algoritme, en kvantealgoritme fra 1994 som løser faktoriseringsproblemet i polynomisk tid på en tilstrekkelig stor, feilkorrigert kvantecomputer. Ingen slik maskin finnes ennå i 2026, men trusselen er alvorlig nok til at data som krypteres i dag kan lagres av en motstander og dekrypteres senere, når kvantemaskinvaren er moden. Dette kalles «harvest now, decrypt later», og det er hovedgrunnen til at NIST, NSA og europeiske myndigheter som det tyske BSI presser på for migrering allerede nå, lenge før noen kvantecomputer faktisk kan knekke RSA.

Ed25519 og andre elliptisk kurve-algoritmer har samme svakhet. De er raskere og har mindre nøkler enn RSA (se vår sammenligning av Ed25519 mot RSA), men Shors algoritme knekker diskret logaritme-problemet på elliptiske kurver like effektivt som faktorisering. Derfor er ikke svaret på kvantetrusselen å bytte til en annen klassisk algoritme. Svaret er en helt ny matematisk grunnmur.

Verdt å understreke: RSA forsvinner ikke fordi det plutselig er blitt dårlig kryptografi. Det forsvinner fordi forutsetningene for hva som regnes som trygt har endret seg. Et system bygget for å beskytte data i ti, tjue eller femti år frem i tid kan ikke lenger regne med at faktoriseringsproblemet forblir uløselig i hele den perioden. Bank-, forsikrings- og helsedata i Norden har ofte lovpålagte oppbevaringstider på flere tiår, noe som gjør akkurat denne typen virksomheter til de som har mest å tape på å vente med migreringen.

ML-KEM og FIPS 203: NIST sin nye standard

NIST finaliserte tre postkvante-standarder i august 2024. FIPS 203 definerer ML-KEM, en nøkkelinnkapslingsmekanisme (Key Encapsulation Mechanism) som erstatter RSA og Diffie-Hellman for nøkkelutveksling. FIPS 204 definerer ML-DSA for digitale signaturer, og FIPS 205 definerer SLH-DSA som et hasjbasert reservealternativ. ML-KEM var tidligere kjent som CRYSTALS-Kyber gjennom hele NIST-konkurransen, og navnet Kyber dukker fortsatt opp i mye teknisk dokumentasjon og biblioteker.

ML-KEM bygger på gitterkryptografi, nærmere bestemt et problem kalt Module Learning With Errors (Module-LWE). I stedet for å stole på at det er vanskelig å faktorisere tall, stoler ML-KEM på at det er vanskelig å finne korte vektorer i høydimensjonale gitter, selv med hjelp av en kvantecomputer. Algoritmen finnes i tre parametersett: ML-KEM-512 (NIST sikkerhetsnivå 1, tilsvarer AES-128), ML-KEM-768 (nivå 3, tilsvarer AES-192) og ML-KEM-1024 (nivå 5, tilsvarer AES-256). De aller fleste TLS-implementasjoner i 2026, inkludert Chrome, Firefox og Cloudflare, bruker ML-KEM-768 som standard.

NIST er ikke ferdig med prosessen. 11. mars 2025 valgte NIST algoritmen HQC som et fjerde, kodebasert reservealternativ for nøkkelinnkapsling, som en forsikring i tilfelle det skulle bli funnet svakheter i gitterbaserte metoder. En utkaststandard for HQC ventes tidlig i 2026, med endelig standard rundt 2027. Falcon, nå kalt FN-DSA, er også fortsatt under standardisering som et kompakt signaturalternativ. Poenget er at ML-KEM ikke er et midlertidig plaster, men en grundig gjennomarbeidet standard med flere års offentlig kryptoanalyse bak seg, fra en konkurranse NIST startet allerede i 2016.

Konkurransen samlet inn 82 kandidatalgoritmer fra forskere over hele verden i første runde. De ble silt ned gjennom flere runder med offentlig kryptoanalyse, der forskningsmiljøer aktivt forsøkte å knekke hver kandidat. Kyber overlevde alle rundene og ble kåret til vinner i 2022, sammen med Dilithium (nå ML-DSA), Falcon og SPHINCS+ (nå SLH-DSA). Denne åpne, konkurransebaserte prosessen er nøyaktig samme modell NIST brukte for å standardisere AES i 2001, og den regnes som gullstandarden for hvordan ny kryptografi bør velges ut, i motsetning til lukkede eller proprietære design.

Nøkkelstørrelser og sikkerhetsnivåer: ML-KEM mot RSA i tall

Den mest håndfaste forskjellen mellom ML-KEM og RSA er hvor mye data som må sendes over nettverket. RSA har svært kompakte nøkler og ingen chiffertekst-overhead å snakke om, mens ML-KEM krever mer plass for samme, eller bedre, sikkerhetsnivå. Tabellen under viser byte-tall hentet direkte fra FIPS 203 og fra Open Quantum Safe sin algoritme-oversikt.

AlgoritmeTypeSikkerhetsnivåOffentlig nøkkelPrivat nøkkelChiffertekst / signaturKvanteresistentStandard
ML-KEM-512NøkkelinnkapslingNIST nivå 1 (~AES-128)800 byte1 632 byte768 byteJaFIPS 203 (2024)
ML-KEM-768NøkkelinnkapslingNIST nivå 3 (~AES-192)1 184 byte2 400 byte1 088 byteJaFIPS 203 (2024)
ML-KEM-1024NøkkelinnkapslingNIST nivå 5 (~AES-256)1 568 byte3 168 byte1 568 byteJaFIPS 203 (2024)
RSA-2048Nøkkeltransport / signatur~112 bit klassisk256 byte256 byte256 byteNeiPKCS#1 (1998-)
RSA-3072Nøkkeltransport / signatur~128 bit klassisk384 byte384 byte384 byteNeiPKCS#1
RSA-4096Nøkkeltransport / signatur~150 bit klassisk512 byte512 byte512 byteNeiPKCS#1
X25519 (referanse)Klassisk nøkkelutveksling128 bit klassisk32 byte32 byte32 byteNeiRFC 7748
Ed25519 (referanse)Klassisk signatur128 bit klassisk32 byte32 byte64 byteNeiRFC 8032
Hybrid X25519+ML-KEM-768Nøkkelutveksling (TLS 1.3)128 bit + kvante~1 216 byte–~1 120 byteJaX25519MLKEM768
HQC (reservealgoritme)NøkkelinnkapslingUnder standardiseringIkke endelig fastsattIkke endelig fastsattIkke endelig fastsattJaValgt mars 2025, standard ~2027

Legg merke til at en ML-KEM-768 offentlig nøkkel på 1 184 byte er over 4,6 ganger større enn en RSA-2048-nøkkel på 256 byte, selv om de to gir omtrent sammenlignbar reell sikkerhet mot klassiske angrep. Chifferteksten følger samme mønster. Det er prisen man betaler for kvanteresistens: mer data i hvert håndtrykk, men til gjengjeld et matematisk problem som ikke er kjent sårbart for Shors algoritme. Den hybride raden i tabellen er det som faktisk brukes i produksjon i 2026: en klassisk X25519-nøkkel pluss en ML-KEM-768-nøkkel sendt sammen, slik at forbindelsen er trygg selv om én av de to algoritmene skulle vise seg å ha en svakhet.

NIST sine sikkerhetsnivåer fortjener en kort forklaring, siden de dukker opp gjentatte ganger i tabellen. Nivå 1 betyr at algoritmen er minst like vanskelig å knekke som å utføre et uttømmende søk mot AES-128, nivå 3 tilsvarer AES-192, og nivå 5 tilsvarer AES-256. Dette er ikke det samme som å si at ML-KEM-512 er «like sterk» som AES-128 i praktisk forstand, men det gir et felles målestokk for å sammenligne vidt forskjellige algoritmefamilier. De fleste organisasjoner lander på nivå 3, altså ML-KEM-768, som en fornuftig balanse mellom sikkerhetsmargin og størrelsen på nøkler og chiffertekster. Nivå 5 reserveres gjerne for systemer med spesielt strenge krav, som statlige kommunikasjonssystemer eller langtidsarkivering av svært sensitive data.

Ytelse i praksis: hvor mye raskere er ML-KEM?

Størrelsen taler til fordel for RSA, men når det gjelder regnekraft snur bildet fullstendig. RSA sin private nøkkeloperasjon krever modulær eksponentiering med tall som er hundrevis av bit lange, noe som er tungt for prosessoren. ML-KEM sine operasjoner er derimot enkle matrisemultiplikasjoner over et lite endelig legeme, noe moderne CPU-er håndterer svært raskt. Tre uavhengige målinger illustrerer forskjellen.

KildeOperasjonML-KEM / KyberRSAForskjell
CRYSTALS-Kyber referanseteam (pq-crystals.org, Haswell CPU, AVX2)NøkkelgenereringKyber768: 52 732 sykluserIkke målt i denne kilden–
CRYSTALS-Kyber referanseteam (pq-crystals.org, Haswell CPU, AVX2)Innkapsling / dekapslingKyber768: 63 724 / 50 724 sykluserIkke målt i denne kilden–
SpinDynamics.io PQC-benchmarkNøkkelgenereringKyber512: 0,02 msRSA-2048: 45 ms~2 250x raskere
SpinDynamics.io PQC-benchmarkDekapsling / dekrypteringKyber768: 0,05 msRSA-3072: 7,0 ms~140x raskere
arXiv, «Hybrid RSA/ML-KEM Cryptographic Gateway» (2026)NøkkelgenereringML-KEM-768: 0,63 msRSA-2048: 103,96 ms~165x raskere
arXiv, «Performance and Storage Analysis of CRYSTALS-Kyber» (2025)Samlet ytelse på x86_64KyberRSAOver 20 500x raskere

Tallene varierer mellom kildene fordi de tester ulike prosessorer, ulike RSA-nøkkelstørrelser og ulike deler av protokollen, men retningen er entydig. ML-KEM sine nøkkeloperasjoner er konsekvent raskere enn RSA sine, ofte med to til fire størrelsesordener. En arXiv-studie fra 2025 fant at Kyber er over 20 500 ganger raskere enn RSA på x86_64-arkitektur og over 3 400 ganger raskere på ARM64, selv når man tar hensyn til at Kyber sender mer data per operasjon. Den samme studien målte at det totale ekstra dataforbruket ved nøkkeltransport med Kyber var rundt 1 121 byte, mot 993 byte for RSA, en forskjell som knapt merkes på en moderne nettforbindelse, men som betyr noe for IoT-enheter med begrenset båndbredde.

Årsaken til forskjellen ligger i selve matematikken. RSA sin private nøkkeloperasjon krever gjentatte modulære multiplikasjoner med tall som er over tusen bit lange, en operasjon som skalerer dårlig når nøkkelstørrelsen øker. Det er derfor RSA-4096 er merkbart tregere enn RSA-2048 i alle benchmarkene. ML-KEM, derimot, jobber med små heltall (koeffisienter opptil 3329) i faste polynomringer, en type regning prosessorer håndterer effektivt med vektoriserte instruksjoner som AVX2 og NEON. Det er nettopp derfor AVX2-tallene fra CRYSTALS-teamet viser tre til fire ganger raskere ytelse enn referanseimplementasjonen uten spesialinstruksjoner, mens tilsvarende optimalisering gir langt mindre gevinst for RSA.

TLS-håndtrykket: hybridkryptering i praksis

Ingen store aktører har gått rett fra RSA eller ren ECDHE til ren ML-KEM. Løsningen i 2026 er hybridkryptering, der klient og server forhandler frem to delte hemmeligheter samtidig, én med en klassisk algoritme som X25519 og én med ML-KEM-768, og kombinerer dem til én endelig nøkkel. TLS-gruppen kalles X25519MLKEM768, og den er standard i Chrome siden versjon 124 (april 2024), i Firefox siden november 2024, og i store deler av Apple sitt økosystem siden oktober 2025, ifølge målinger fra Cloudflare Radar og uavhengige TLS-analyser.

Hybridtilnærmingen finnes fordi ingen, ikke engang NIST, vil satse hele internetts sikkerhet på at gitterkryptografi holder i femti år uten at det dukker opp et smart matematisk angrep. Skulle ML-KEM vise seg sårbar, faller forbindelsen tilbake på at X25519 fortsatt er trygg mot klassiske angrep. Skulle en kvantecomputer dukke opp tidligere enn ventet, er det ML-KEM-delen som redder forbindelsen. Kostnaden er beskjeden: håndtrykket blir litt over én kilobyte tyngre, noe som knapt er målbart på en vanlig internettforbindelse, men som kan kreve justering av MTU-innstillinger på eldre nettverksutstyr som ikke takler TCP-pakkefragmentering godt.

Slik sjekker du hvilken nøkkelutvekslingsgruppe en server faktisk bruker:

openssl s_client -connect eksempel.no:443 -groups X25519MLKEM768 -tls1_3 2>&1 | grep -i "server temp key"

# Forventet svar ved vellykket hybrid PQC-oppsett:
# Server Temp Key: X25519MLKEM768, 4096 bits

Får du i stedet «X25519» eller «prime256v1» tilbake, betyr det at serveren ennå ikke tilbyr postkvante nøkkelutveksling, og trafikken er fortsatt kun beskyttet av klassisk kryptografi.

Hvem bruker allerede ML-KEM? Seks eksempler fra virkeligheten

Overgangen fra RSA til ML-KEM er ikke lenger et forskningsprosjekt. Den kjører i produksjon hos noen av verdens største nettjenester akkurat nå, og alle seks eksemplene under bekrefter samme trend: jo mer en tjeneste har å tape på at trafikken avlyttes og lagres i dag, desto tidligere har den innført postkvante-beskyttelse.

  • Cloudflare slo på hybrid postkvante nøkkelutveksling som standard for alle TLS 1.3-tilkoblinger allerede i oktober 2022. I mars 2024 var andelen «nesten to prosent» av tilkoblingene, ifølge Cloudflares egen blogg. I april 2026 hadde tallet passert 65 prosent av menneskegenerert trafikk, og selskapet sikter mot full postkvantesikkerhet, inkludert autentisering, innen 2029.
  • Google Chrome aktiverte X25519Kyber768 som eksperiment i versjon 116 (august 2023) og satte hybrid ML-KEM som standard i Chrome 124 fra april 2024. Cloudflare målte at globalt PQ-klientstøtte hoppet fra rundt 2 til 12 prosent i løpet av den påfølgende måneden.
  • Mozilla Firefox fulgte etter med standardaktivert hybrid nøkkelutveksling i november 2024.
  • Apple lanserte PQ3-protokollen for iMessage i begynnelsen av 2024, en egenutviklet hybrid postkvanteprotokoll for meldingskryptering, og utvidet postkvantestøtte bredere i økosystemet mot slutten av 2025.
  • Signal byttet ut sin X3DH-nøkkelavtale med PQXDH, en hybrid postkvanteversjon som legger til ML-KEM oppå den klassiske X25519-utvekslingen for å beskytte samtaler mot fremtidig dekryptering.
  • AWS har rullet ut hybrid postkvante nøkkelutveksling for utvalgte tjenester, inkludert forhåndsvisning for AWS KMS og støtte i AWS CloudFront, ifølge offentlig dokumentasjon og uavhengige målestudier av internett-infrastruktur i 2026.

Mønsteret er tydelig: infrastrukturselskaper og meldingsapper med lange konfidensialitetskrav går først, fordi «harvest now, decrypt later» rammer dem hardest. En melding som avlyttes og lagres kryptert i dag, kan bli lesbar om den ligger i et arkiv hos en statsaktør med tilgang til en fremtidig kvantecomputer. Vanlige nettbutikker og interne API-er har typisk mindre press, men følger samme retning i takt med at nettlesere og biblioteker gjør hybrid PQC til standardvalg.

Cloudflares egne radarmålinger viser hvor raskt kurven har beveget seg. Fra under 3 prosent global PQ-klientstøtte i begynnelsen av 2024, via over 50 prosent i slutten av oktober 2025, til godt over 60 prosent i februar 2026. Utviklingen har gått raskere enn de fleste sikkerhetsmigreringer i internetthistorien, raskere enn overgangen fra SHA-1 til SHA-256 og raskere enn utrullingen av TLS 1.3. Hovedforklaringen er at de tunge løftene ble gjort av et lite antall aktører: noen få nettlesere og noen få store CDN-er dekker en enorm andel av all internett-trafikk, og når de bytter standardinnstilling, følger resten av verden automatisk med uten å måtte gjøre noe selv.

Hva koster overgangen? Nøkkelhåndtering og maskinvare

Et vanlig spørsmål er om ML-KEM koster mer å drifte enn RSA. Svaret, i alle fall hos de store skyleverandørene, er nei. Verken AWS, Azure eller Google Cloud legger på et eget gebyr for kvanteresistente nøkkeltyper. Kostnaden ligger i nøkkelen som sådan, ikke i algoritmen den bruker.

TjenesteLagring per nøkkel/mndPris per 10 000 operasjonerMerknad
AWS KMS (kundestyrt nøkkel)$1,00$0,03 (etter 20 000 gratis kall/mnd)Samme pris for symmetriske, asymmetriske og HMAC-nøkler, uavhengig av algoritme
Azure Key Vault (Standard-nivå)Ingen fast lagringsavgift~$0,03 per 10 000 operasjonerBetaling skjer hovedsakelig per operasjon, ikke per lagret nøkkel
Google Cloud KMS (programvarebasert)$0,06~$0,03 per 10 000 operasjonerHSM-beskyttede nøkler koster mer enn programvarenøkler
AWS CloudHSM–$1,60 per HSM-instans/timeDedikert maskinvare, brukes typisk der compliance krever fysisk isolasjon

Den reelle kostnaden ved en RSA-til-ML-KEM-migrering ligger sjelden i selve krypteringsprisen. Den ligger i arbeidstimer: å kartlegge hvor RSA-nøkler brukes i dag, oppgradere TLS-biblioteker og operativsystemer til versjoner som støtter hybrid PQC, teste kompatibilitet mot eldre klienter, og validere at sertifikatkjeder, VPN-er og interne tjenester fortsatt fungerer. For de fleste organisasjoner er dette en fase i den normale patchesyklusen for infrastruktur, ikke et eget stort budsjettpunkt, forutsatt at man begynner tidlig og ikke venter til alt må gjøres samtidig under tidspress.

HSM-kostnaden fortjener en egen kommentar. AWS CloudHSM sin timepris på 1,60 dollar høres lite ut isolert, men løper over et helt år til rundt 14 000 dollar per instans, og de fleste produksjonsoppsett krever minst to instanser for redundans. Dette er imidlertid samme kostnad uansett om HSM-en beskytter en RSA-nøkkel eller en ML-KEM-nøkkel, siden prisen er knyttet til maskinvaren og ikke algoritmen. Den store variabelen er om HSM-leverandøren din faktisk har fastvarestøtte for ML-KEM og ML-DSA ennå. Dette bør du sjekke direkte med leverandøren før du planlegger migreringen, siden støtten varierer mellom produktgenerasjoner, og eldre HSM-modeller kan kreve full utskiftning fremfor en enkel fastvareoppdatering.

Migreringsguide: fra RSA til ML-KEM i ni steg

  1. Kartlegg alle RSA-avhengigheter. Finn hvor RSA brukes til TLS, kodesignering, SSH, VPN og interne API-er. Mange organisasjoner blir overrasket over hvor mange steder RSA-2048 fortsatt ligger gjemt i gamle systemer, ofte i tredjepartsbiblioteker ingen har sett nærmere på siden de ble installert. Et fullstendig kryptografi-inventar er tidkrevende, men det er umulig å prioritere riktig uten det.
  2. Oppdater TLS-biblioteker. Sørg for at OpenSSL (3.2 eller nyere med oqs-provider), BoringSSL, eller ditt språks TLS-bibliotek faktisk støtter X25519MLKEM768-gruppen. Sjekk versjonsnumre eksplisitt, siden mange langtidsstøttede Linux-distribusjoner fortsatt pakker eldre OpenSSL-versjoner uten PQC-støtte som standard.
  3. Aktiver hybridmodus, ikke ren PQC. Bruk X25519+ML-KEM-768 som standard fremfor å hoppe rett til ren postkvante-kryptografi, slik at du har en klassisk fallback dersom noe går galt. Dette er også det eneste oppsettet store leverandører som Cloudflare og Google i praksis anbefaler i 2026.
  4. Test mot eldre klienter. Kontroller at nettlesere, mobilapper og IoT-enheter som ikke støtter PQC fortsatt kan forhandle en trygg klassisk forbindelse. Sett opp overvåking som logger hvilken nøkkelutvekslingsgruppe hver enkelt tilkobling faktisk bruker, slik at du kan følge migreringsgraden over tid.
  5. Overvåk MTU og pakkefragmentering. Det større håndtrykket kan trigge fragmentering på nettverksutstyr med stramme MTU-grenser, spesielt over eldre VPN-tunneler og satellittforbindelser. Test spesifikt mot brannmurer og lastbalanserere som gjør dyp pakkeinspeksjon, siden enkelte eldre modeller feiltolker de større TLS-håndtrykkene.
  6. Oppgrader kodesignering separat. Signaturalgoritmen ML-DSA (FIPS 204) migreres uavhengig av nøkkelutveksling, og bør prioriteres for programvare- og fastvaresignering først, i tråd med NSA sine anbefalinger. Dette er ofte det området organisasjoner glemmer fordi fokuset lett havner ensidig på TLS.
  7. Planlegg for HSM- og sertifikatoppdateringer. Sjekk om maskinvaren din (Thales, AWS CloudHSM, YubiHSM eller tilsvarende) faktisk støtter ML-KEM og ML-DSA i fastvaren, ikke bare i programvarelaget. Be leverandøren om en konkret roadmap med datoer dersom støtten ikke er der ennå.
  8. Følg med på sertifikatmyndighetene. De første hybride PQC-sertifikatene fra offentlige CA-er ventes å bli tilgjengelige i løpet av 2026, foreløpig ikke aktivert som standard. Meld deg på nyhetsbrev eller endringslogger fra din CA slik at du ikke går glipp av når støtten blir tilgjengelig for din organisasjon.
  9. Dokumenter og revider. Før logg over hvilke systemer som er migrert, og sett en frist for når RSA skal deaktiveres helt, ikke bare legges til side som et alternativ. Uten en eksplisitt sluttdato for RSA har erfaring vist at gamle konfigurasjoner har en tendens til å leve videre i årevis, lenge etter at de skulle vært fjernet.

Fordeler og ulemper med RSA

Fordeler:

  • Nesten femti år med offentlig kryptoanalyse og et enormt økosystem av biblioteker, maskinvare og verktøy som støtter det fullt ut.
  • Svært kompakte nøkler og chiffertekster sammenlignet med ML-KEM, noe som er en fordel for lavbåndbredde-enheter uten kvantetrussel-krav.
  • Universell kompatibilitet. Praktisk talt alt eldre utstyr, fra betalingsterminaler til industrisystemer, forstår RSA.

Ulemper:

  • Sårbar for Shors algoritme på en tilstrekkelig stor kvantecomputer, uansett nøkkellengde.
  • Trege private nøkkeloperasjoner sammenlignet med ML-KEM, målt i millisekunder mot brøkdeler av et millisekund.
  • Rammet av «harvest now, decrypt later»: data kryptert med RSA i dag kan avlyttes og lagres for senere dekryptering.
  • NSA sin egen CNSA 2.0-veiledning krever at nasjonale sikkerhetssystemer faser ut RSA og ECC innen 2030 til 2033, avhengig av kategori.
  • Skalerer dårlig: å øke sikkerhetsmarginen fra RSA-2048 til RSA-4096 gjør nøkkeloperasjonene vesentlig tregere, mens tilsvarende sikkerhetsøkning i ML-KEM koster langt mindre i regnetid.

Fordeler og ulemper med ML-KEM

Fordeler:

  • Motstandsdyktig mot både klassiske og kjente kvantealgoritmer, inkludert Shors algoritme.
  • Vesentlig raskere nøkkeloperasjoner enn RSA, ifølge flere uavhengige benchmarker fra pq-crystals.org, SpinDynamics.io og akademiske studier på arXiv.
  • Offisielt standardisert av NIST gjennom FIPS 203, med bred støtte i Chrome, Firefox, Cloudflare og store deler av skyøkosystemet allerede i 2026.
  • Designet for hybriddrift, slik at du ikke må stole blindt på en ny algoritme uten en klassisk sikkerhetsmargin.

Ulemper:

  • Større nøkler og chiffertekster, opptil 4,6 ganger større enn RSA-2048 for sammenlignbar sikkerhet.
  • Yngre matematisk grunnlag. Gitterbasert kryptografi har færre tiår med offentlig gransking enn faktorisering, selv om det har vært studert intensivt siden tidlig 2000-tall.
  • Krever oppdatert programvare og maskinvare. Svært gammelt utstyr som ikke får fastvareoppdateringer kan ikke støtte ML-KEM uten utskifting.
  • HQC-reservealgoritmen er fortsatt under standardisering og ikke klar til bruk før tidligst 2027.

Når bør du velge hva? Fem bruksområder

1. Offentlige nettsteder og API-er

Aktiver hybrid X25519MLKEM768 i webserveren så snart TLS-stacken din støtter det. De fleste moderne nettlesere forhandler dette automatisk, og du trenger ikke fjerne RSA-fallback for klienter som henger etter.

2. Meldingsapper og ende-til-ende-kryptering

Følg Signal og Apple sitt eksempel. Her er «harvest now, decrypt later» den mest akutte trusselen, siden private samtaler kan ha verdi for en motstander i årevis fremover. En melding om et forretningsoppkjøp, en helsetilstand eller en personlig konflikt kan være like følsom om ti år som i dag, og det er nettopp denne typen langvarig sensitivitet som gjør meldingsapper til en naturlig førstemover-kategori.

3. Finans og offentlig sektor i Norden

Bank- og forsikringssystemer med lange oppbevaringsplikter bør prioritere migrering nå, spesielt siden BSI i Tyskland og tilsvarende europeiske organer allerede har oppdatert sine kryptografianbefalinger med postkvante-krav i 2026.

4. IoT og innebygde enheter

Her er avveiningen mer krevende. ML-KEM-512 holder nøklene relativt små, men enheter med svært begrenset minne og båndbredde bør teste faktisk overhead før de bytter ut RSA fullstendig, og kan med fordel vente på flere lette implementasjoner. Mikrokontrollere med bare noen titalls kilobyte RAM kan oppleve at selv ML-KEM-512 sine 1,6 kilobyte private nøkkel er en reell begrensning, og bør evalueres per enhetstype fremfor å migreres samlet under ett.

5. Kodesignering og programvareoppdateringer

Prioriter ML-DSA (FIPS 204) for signering av fastvare og programvareoppdateringer først. NSA sin CNSA 2.0-tidslinje setter nettopp dette som den tidligste kategorien for obligatorisk overgang, med eksklusiv bruk innen 2030.

Trusselbildet: når kan en kvantecomputer knekke RSA?

Ingen kan i dag sette en eksakt dato på når en kvantecomputer klarer å faktorisere en RSA-2048-nøkkel. Det som derimot finnes, er konkrete myndighetsfrister for når organisasjoner må ha byttet ut RSA, uavhengig av når trusselen faktisk materialiserer seg. Den amerikanske sikkerhetstjenesten NSA publiserte i 2022 sin CNSA 2.0-veiledning, oppdatert i 2025, med følgende tidslinje for nasjonale sikkerhetssystemer:

KategoriFrist for eksklusiv bruk av postkvante-algoritmer
Programvare- og fastvaresignering2030
Nettlesere, servere og skytjenester2033
Tradisjonelt nettverksutstyr (VPN, rutere)2030
Eldre utstyr som ikke kan oppgraderesUtfases innen 31. desember 2030
Alle nasjonale sikkerhetssystemer (NSS)2035

Dette er amerikanske myndighetsfrister, men de fungerer som en de facto bransjestandard fordi leverandører som må levere til offentlig sektor uansett må bygge produktene sine PQC-klare. Ekspertmiljøet er delt om når selve «Q-day», altså dagen en kvantecomputer faktisk knekker RSA-2048, kan inntreffe. Noen forskere peker på tidlig 2030-tall som et realistisk vindu gitt fremgangen i feilkorrigert kvantemaskinvare, mens andre mener det fortsatt ligger tiår unna. Usikkerheten er nettopp hvorfor «harvest now, decrypt later» tas på alvor allerede nå: dersom Q-day kommer om ti år, og en motstander lagrer trafikken din i dag, er skaden allerede skjedd lenge før du rekker å reagere.

Det er verdt å skille mellom to typer risiko her. Den ene er konfidensialitet: data som krypteres i dag og avlyttes av en motstander som lagrer den for senere dekryptering. Den andre er integritet og autentisitet: signaturer som brukes til å bekrefte at programvare, fastvare eller meldinger ikke er tuklet med. Konfidensialitetsrisikoen er akutt allerede nå, fordi skaden skjer i det øyeblikket data avlyttes, ikke når den dekrypteres. Signaturrisikoen er mer umiddelbar på en annen måte: en forfalsket signatur er et problem i det øyeblikket en kvantecomputer finnes, uansett når signaturen ble laget. Det er trolig derfor NSA sin CNSA 2.0-tidslinje setter programvare- og fastvaresignering til samme tidlige frist som nøkkelutveksling for nettverksutstyr, altså 2030, mens nettlesere og skytjenester for øvrig først kreves eksklusivt postkvante innen 2033.

Vanlige feil under PQC-migrering

  • Å hoppe rett til ren ML-KEM uten klassisk fallback. Hybridmodus finnes av en grunn, og de fleste store aktørene bruker den nettopp for å unngå å satse alt på én ny algoritme. Ren PQC uten klassisk sikkerhetsnett bør reserveres for spesialtilfeller der du vet nøyaktig hva du gjør.
  • Å glemme signaturalgoritmen. Mange fokuserer kun på nøkkelutveksling (ML-KEM) og overser at digitale signaturer (ML-DSA) trenger sin egen migreringsplan, ofte med andre tidsfrister og andre ansvarlige team.
  • Å ikke teste MTU og fragmentering. Større håndtrykk kan brekke på nettverksutstyr som ikke håndterer TCP-fragmentering korrekt, noe som gir kryptiske tilkoblingsfeil i produksjon som er vanskelige å feilsøke i ettertid.
  • Å anta at skyleverandøren automatisk fikser alt. PQC-støtte varierer fortsatt mellom tjenester hos samme leverandør, og enkelte KMS- og sertifikattjenester har foreløpig kun forhåndsvisningsstøtte som ikke er ment for produksjonsbruk ennå.
  • Å utsette migreringen til frister nærmer seg. Med CNSA 2.0-frister i 2030 og 2033 er det fristende å vente, men testing, kompatibilitetsarbeid og maskinvareoppgraderinger tar tid, spesielt i store, sammensatte IT-miljøer med mange gamle systemer i drift.
  • Å behandle migreringen som et rent teknisk prosjekt. Uten forankring hos ledelsen risikerer sikkerhetsteamet å stå alene med en flerårig oppgave som krever budsjett, prioritering på tvers av avdelinger og tålmodighet fra virksomheten.

Konklusjon: verdikten med tall på bordet

ML-KEM vinner den langsiktige sikkerhetsdebatten uten tvil. Det er den eneste av de to som faktisk motstår Shors algoritme, det er raskere i praksis ifølge flere uavhengige benchmarker, og det er allerede standard hos Cloudflare, Chrome, Firefox og store deler av skyøkosystemet. Prisen er større nøkler og chiffertekster, typisk 4 til 5 ganger tyngre enn RSA-2048 for tilsvarende klassisk sikkerhetsnivå, men den kostnaden er i praksis usynlig for de fleste moderne nettforbindelser.

Sett i sammenheng er dette et uvanlig klart teknologiskifte. De fleste kryptografiske oppgraderinger handler om marginale forbedringer, litt bedre ytelse eller litt strammere sikkerhetsmarginer. Overgangen fra RSA til ML-KEM handler om noe mer grunnleggende: hele det matematiske fundamentet under internett-sikkerheten bytter fra faktorisering til gitterproblemer, fordi det gamle fundamentet har en kjent, teoretisk løsning som bare venter på riktig maskinvare. Det gjør denne migreringen mindre valgfri enn de fleste tidligere oppgraderinger av kryptografiske standarder, og det er trolig hovedgrunnen til at adopsjonstakten har vært så mye raskere enn normalt.

RSA er ikke død i 2026, og det blir det ikke over natten. Det finnes fortsatt i utallige eldre systemer, betalingsterminaler og innebygde enheter som ikke lar seg oppgradere raskt. Men retningen er entydig: NSA krever eksklusiv bruk av postkvante-algoritmer for signering innen 2030 og for nettlesere og skytjenester innen 2033, og Cloudflares tall viser at internett allerede har passert vippepunktet, med over 65 prosent postkvantesikret trafikk i april 2026. For enhver ny arkitektur bygget i 2026 er svaret enkelt: bruk hybrid X25519+ML-KEM-768 som standard, behold RSA kun der kompatibilitet krever det, og sett en konkret dato for når RSA skal fases helt ut av systemene dine.

Ofte stilte spørsmål

Er ML-KEM det samme som Kyber?

Ja. ML-KEM er NIST sitt offisielle navn på algoritmen som tidligere het CRYSTALS-Kyber gjennom hele standardiseringskonkurransen. FIPS 203, publisert i august 2024, gjorde navnebyttet offisielt, men mye eksisterende dokumentasjon og biblioteker bruker fortsatt Kyber-navnet.

Må jeg fjerne RSA fullstendig med det samme?

Nei. De fleste organisasjoner kjører hybridmodus, der RSA eller X25519 fortsatt fungerer som klassisk sikkerhetsnett ved siden av ML-KEM. NSA sin CNSA 2.0-tidslinje setter frister for eksklusiv bruk av postkvante-algoritmer i 2030 og 2033, ikke et krav om umiddelbar full utfasing av RSA i 2026.

Er ML-KEM tregere enn RSA fordi nøklene er større?

Nei, det motsatte. Selv om ML-KEM sender mer data, er selve regneoperasjonene betydelig raskere enn RSA sine. Uavhengige benchmarker fra SpinDynamics.io og akademiske arXiv-studier viser 100 til over 20 000 ganger raskere operasjoner, avhengig av hvilken RSA-nøkkelstørrelse og hvilken operasjon som sammenlignes.

Hva er forskjellen mellom ML-KEM og ML-DSA?

ML-KEM (FIPS 203) håndterer nøkkelutveksling og erstatter RSA og Diffie-Hellman der. ML-DSA (FIPS 204) håndterer digitale signaturer og erstatter RSA-signaturer og ECDSA. De er to separate standarder som ofte migreres på ulike tidspunkt, siden signeringssystemer og nøkkelutvekslingssystemer typisk driftes av forskjellige team.

Støtter alle nettlesere ML-KEM i 2026?

De store nettleserne gjør det. Chrome siden versjon 124 (april 2024), Firefox siden november 2024, og store deler av Apple sitt økosystem siden oktober 2025. Eldre nettlesere og systemer som ikke oppdateres, forhandler fortsatt en klassisk forbindelse, noe hybridmodus håndterer automatisk uten at brukeren merker noe.

Koster det mer å bruke ML-KEM i skytjenester som AWS?

Nei. AWS KMS, Azure Key Vault og Google Cloud KMS priser nøkler likt uavhengig av om de er RSA-baserte eller kvanteresistente. AWS KMS koster for eksempel 1 dollar per nøkkel per måned pluss 0,03 dollar per 10 000 API-kall, samme sats for symmetriske, asymmetriske og HMAC-nøkler.

Hva skjer med eldre systemer som aldri kan oppgraderes til ML-KEM?

De blir et voksende sikkerhetsproblem. NSA sin CNSA 2.0-veiledning sier eksplisitt at utstyr som ikke kan støtte de nye algoritmene skal fases ut innen utgangen av 2030. For systemer som ikke kan oppgraderes i tide, bør organisasjoner vurdere segmentering, ekstra overvåking, eller planlagt utskifting fremfor å la dem stå eksponert mot fremtidige kvanteangrep på ubestemt tid.

Kan jeg fortsatt bruke RSA til nye prosjekter i 2026?

Teknisk sett ja, men det anbefales ikke for noe som skal driftes over flere år. Bygger du et nytt system i 2026, er det langt mer fornuftig å starte med hybrid X25519+ML-KEM-768 fra dag én enn å bygge på RSA og migrere senere. Kostnaden ved å designe riktig fra start er minimal sammenlignet med å gjøre om en hel arkitektur i etterkant.

Relatert dekning