Sommeren 2026 gjorde IETF noe kryptografimiljøet har ventet på i over ti år: publiserte RFC 10015 og forbød formelt RSA-nøkkelutveksling og endelig-felt Diffie-Hellman i TLS 1.2 og DTLS 1.2. Teksten er ikke tvetydig. Klienter skal ikke tilby, og servere skal ikke velge, RSA- eller FFDHE-cifferpakker i (D)TLS 1.2-forbindelser. Over 175 cifferpakker havnet dermed i kategorien “frarådet” over natten.

For utviklere og drift-team reiser dette et konkret spørsmål: hva skal erstatte RSA i nøkkelutvekslingen, og hvor mye vinner man egentlig på å bytte til ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)? Vi har gått gjennom ytelsestall fra fem uavhengige studier, gjeldende skypriser fra AWS, Azure og Google Cloud, og selve RFC-teksten for å gi et konkret svar. Merk at dette handler om nøkkelutveksling, altså hvordan TLS-parter blir enige om en delt hemmelighet – ikke om digitale signaturer, som vi har dekket separat i artikkelen om ECDSA vs Ed25519.

Dette er ikke en liten, teoretisk justering. RFC 10015 flytter over 175 cifferpakker fra “tillatt” til “frarådet” i TLS-registeret, og gjør det med bindende språk fremfor en myk anbefaling. For et redaksjonelt medium som dekker sikkerhet handler denne saken derfor om tre ting samtidig: hva IETF faktisk krever, hvor mye raskere og tryggere ECDHE er i praksis, og hva det egentlig koster å gjennomføre byttet i en virksomhet som fortsatt kjører eldre TLS 1.2-oppsett.

Nøkkelutveksling er ikke det samme som signering

Mange norske utviklere blander sammen to helt forskjellige jobber en TLS-håndtrykk gjør. Den ene er autentisering: serveren beviser hvem den er, vanligvis med et sertifikat signert med RSA eller ECDSA. Den andre er nøkkelutveksling: partene blir enige om en felles hemmelig nøkkel som resten av økten krypteres med. RFC 10015 rører ikke autentiseringsdelen. Et nettsted kan fortsatt bruke et RSA-signert sertifikat i 2026, selv om selve nøkkelutvekslingen skjer med ECDHE.

Denne distinksjonen er kjernen i hele saken. RSA kan brukes til nøkkelutveksling på to måter: som statisk nøkkeltransport (klienten krypterer en hemmelighet med serverens offentlige nøkkel) eller indirekte via signering av en Diffie-Hellman-utveksling. Det er den første varianten, ren RSA-nøkkeltransport, som nå er dødsdømt. Den har aldri gitt fremoverrettet hemmelighold (forward secrecy), og det er nettopp det RFC 10015 peker på som hovedbegrunnelsen.

Red Hat forklarte dette allerede i sin TLS-forklaringsserie: man kan fortsatt bruke RSA-sertifikater med TLS 1.3, men all nøkkeletablering må gjøres med Diffie-Hellman, enten i sin klassiske form eller over elliptiske kurver. TLS 1.3 fjernet allerede muligheten for ren RSA-nøkkeltransport for flere år siden. Det RFC 10015 gjør i 2026 er å lukke det samme hullet i TLS 1.2, som fortsatt er i utbredt bruk i eldre infrastruktur.

Slik fungerer RSA-nøkkelutveksling

I klassisk RSA-nøkkeltransport genererer klienten en tilfeldig “pre-master secret”, krypterer den med serverens offentlige RSA-nøkkel og sender den over. Bare serveren, som sitter på den private nøkkelen, kan dekryptere den. Enkelt, men med to store svakheter. For det første: hvis den private nøkkelen noensinne lekker eller knekkes, kan en angriper dekryptere all tidligere trafikk som er logget, fordi hemmeligheten alltid er den samme uansett hvilken økt det gjelder. For det andre er RSA-dekryptering tregt sammenlignet med moderne alternativer, og cifferteksten er sårbar for varianter av Bleichenbacher-angrepet, der en angriper kan bruke serverens feilmeldinger til gradvis å dekryptere data uten å kjenne nøkkelen.

Bleichenbacher-angrepet fra 1998 har vist seg overraskende seiglivet. Varianter som ROBOT (2018) og DROWN (2016) rammet store deler av internett årevis etter at den opprinnelige sårbarheten ble “fikset”, nettopp fordi motmiddelet er vanskelig å implementere riktig i praksis. RFC 10015 nevner dette eksplisitt som en av hovedgrunnene til å fjerne RSA-nøkkelutveksling helt, fremfor å stole på at alle implementasjoner har patchet korrekt.

Det underliggende problemet er at RSA-nøkkeltransport (ofte omtalt som PKCS#1 v1.5-padding i denne konteksten) gir en server to forskjellige svar avhengig av om den mottatte cifferteksten er gyldig utfylt eller ikke. En angriper som kan sende tusenvis av forespørsler og observere responstid eller feilmeldinger, kan gradvis rekonstruere den krypterte hemmeligheten uten å noensinne stjele den private nøkkelen direkte. Dette er nøyaktig den type sidekanal som gjør RSA-nøkkeltransport strukturelt sårbar uansett hvor godt resten av implementasjonen er skrevet, og det er derfor IETF til slutt konkluderte med at “frarådet” ikke var nok, det måtte bli et absolutt forbud.

Slik fungerer ECDHE

ECDHE bygger på Diffie-Hellman-prinsippet, men over en elliptisk kurve i stedet for et stort primtallsfelt. Begge parter genererer et midlertidig (efemært) nøkkelpar for hver eneste økt, bytter offentlige nøkler, og regner ut en felles hemmelighet matematisk uten at hemmeligheten noensinne sendes over nettet. Fordi nøklene er efemære, altså engangsbruk, kan ikke en angriper som senere stjeler serverens langsiktige private nøkkel dekryptere gamle økter. Det er selve definisjonen av fremoverrettet hemmelighold.

Den praktiske fordelen med elliptisk kurve-kryptografi er nøkkelstørrelse. Ifølge en analyse publisert i Journal of Student Research gir en 224-bits ECDH-nøkkel omtrent samme sikkerhetsnivå som en 2048-bits RSA-nøkkel, altså 112-bits effektiv sikkerhet. Mindre nøkler betyr mindre data å sende, mindre CPU-arbeid, og raskere håndtrykk, spesielt merkbart på mobil og IoT-maskinvare med begrenset regnekraft.

I praksis forhandler de fleste moderne TLS-stakker en av tre kurver: secp256r1 (også kjent som P-256 eller NIST P-256), secp384r1 (P-384) for høyere sikkerhetsnivåer, eller X25519, en nyere kurve designet spesifikt for enkel og trygg implementasjon uten de fallgruvene som har rammet enkelte NIST-kurver historisk. X25519 har blitt standardvalget i moderne biblioteker som OpenSSL 3.x og BoringSSL nettopp fordi den er raskere å regne på og vanskeligere å implementere feil enn de eldre NIST-kurvene. Valget av kurve påvirker ikke RFC 10015-samsvar i seg selv, men det påvirker hvor mye av ytelsesgevinsten man faktisk henter ut i produksjon.

RFC 10015: Hva IETF faktisk endret i 2026

RFC 10015, med tittelen “Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2”, ble publisert 16. juli 2026 av IETF. Dokumentet er presist i språket sitt: for TLS 1.2 og DTLS 1.2 fjerner det bruken av to nøkkelutvekslinger, nemlig Diffie-Hellman over et endelig felt (FFDHE) og RSA. Teksten bruker det formelle kravordet “MUST NOT”: klienter skal ikke tilby, og servere skal ikke velge, RSA-cifferpakker eller FFDHE-cifferpakker i (D)TLS 1.2-forbindelser.

Viktig detalj: dette gjelder begge varianter av Diffie-Hellman over endelig felt, både statisk og efemær (DHE). Mange antok at bare den statiske varianten ville bli fjernet, men RFC-en er tydelig på at også FFDHE skal bort. Statisk elliptisk kurve-Diffie-Hellman får en mildere anbefaling, “SHOULD NOT”, altså sterkt frarådet, men ikke like absolutt forbudt som RSA og FFDHE.

Resultatet er et klart, lagdelt bilde av TLS-status i 2026: TLS 1.3 er den fullt standardiserte grunnlinjen og krever alltid ECDHE eller DHE. TLS 1.2 med ECDHE er en akseptert reserveløsning for eldre systemer. RSA-nøkkelutveksling og endelig-felt Diffie-Hellman er nå formelt og permanent forbudt i begge protokollversjoner. RSA-sertifikater for autentisering er fortsatt greit å bruke, det er bare nøkkeltransport med RSA som er dødt.

Fra SSL til RFC 10015: en kort tidslinje

Historien til RSA-nøkkelutveksling strekker seg tilbake til SSL 2.0 på nittitallet, da RSA-nøkkeltransport var den eneste reelle metoden for å etablere en delt hemmelighet i en verden uten utbredt elliptisk kurve-støtte. Diffie-Hellman over endelig felt (FFDHE) kom tidlig som et alternativ med fremoverrettet hemmelighold, men var tregere og mer komplekst å konfigurere riktig, noe som gjorde at mange servere aldri skrudde det på.

Elliptisk kurve-varianten ECDHE begynte å bli utbredt på 2010-tallet etter hvert som prosessorstøtte og bibliotekmodenhet tok igjen teorien. TLS 1.3, standardisert i RFC 8446 i 2018, tok det avgjørende steget: RSA-nøkkeltransport ble fjernet helt fra protokollen, og ECDHE eller DHE ble obligatorisk for enhver ny tilkobling. Det som gjensto var TLS 1.2, som fortsatt tillot RSA-nøkkelutveksling som en bakoverkompatibel mulighet for eldre klienter og systemer som ikke hadde blitt oppgradert.

Den siste brikken falt på plass 16. juli 2026 da IETF publiserte RFC 10015 og fjernet også denne bakoverkompatible muligheten i TLS 1.2 og DTLS 1.2. Utkastet som endte opp som RFC 10015 hadde vært under arbeid i IETFs TLS-arbeidsgruppe i flere år før publisering, og reflekterer en bransjekonsensus som lenge har eksistert i praksis, men som nå er nedfelt som bindende standardtekst.

Ytelsen i tall: fem uavhengige kilder

Påstanden om at ECDHE er raskere enn RSA er ikke ny, men tallene varierer mye avhengig av hvem som måler og hvilken maskinvare som brukes. Vi har samlet resultater fra fem separate studier og kilder for å gi et bredere bilde enn ett enkelt benchmark kan gjøre.

En studie publisert i IJARSCT om sikker dataoverføring i skyen fant at ECDH-nøkkelgenerering og utregning av delt hemmelighet var 60-70 prosent raskere enn RSA ved sammenlignbart sikkerhetsnivå. I deres simulerte skymiljø tok ECC-dekryptering omtrent 187 millisekunder, mot omtrent 10 957 millisekunder for RSA, altså nesten 60 ganger raskere. Nøkkelgenerering lå på 15-100 millisekunder for ECDH-256, sammenlignet med over 2000 millisekunder for RSA-3072.

Citrix’ egen tekniske sammenligning av nøkkelutveksling i SSL/TLS oppsummerer forskjellen i en enkel tabell: RSA med 2048-bits nøkkel gir høy ytelseskostnad, ingen fremoverrettet hemmelighold, og klassifiseres som “kun for eldre systemer”. DHE med tilsvarende 2048-bits sikkerhet gir moderat ytelseskostnad, fremoverrettet hemmelighold, og brukes fortsatt i enkelte applikasjoner. ECDHE er ikke tatt med i akkurat den tabellen, men følger samme logikk med enda bedre ytelse enn DHE på grunn av mindre nøkler.

Et interessant historisk motstykke kommer fra Mint Security sin tekniske gjennomgang av TLS-forkortelser: “DHE er tregest. ECDHE er fortsatt tregere enn RSA. RSA er hastighetskongen.” Denne vurderingen er over ti år gammel og gjaldt kun selve nøkkelutvekslingsoperasjonen isolert sett, ikke totalbildet med sikkerhet og maskinvareakselerasjon inkludert. Den illustrerer likevel hvorfor det tok så lang tid å fase ut RSA: i et snevert, isolert benchmark uten moderne kurveimplementasjoner var RSA faktisk raskere på ren nøkkelutvekslingshastighet. Moderne kurver som X25519 og optimaliserte biblioteker har snudd det bildet.

Et femte datapunkt kommer fra en produksjonsmåling av TLS 1.2 mot TLS 1.3 som viser at et fullt håndtrykk tar 45 millisekunder på TLS 1.2 mot 25 millisekunder på TLS 1.3, en forskjell på 20 millisekunder eller om lag 44 prosent raskere. Tiden til første byte (TTFB) falt fra 58 til 32 millisekunder i samme måling, altså 26 millisekunder eller 45 prosent raskere. Siden TLS 1.3 utelukkende bruker ECDHE eller DHE i nøkkelutvekslingen, er denne forskjellen i praksis et direkte mål på hvor mye raskere moderne nøkkelutveksling er sammenlignet med eldre, RSA-tunge håndtrykk.

Samlet gir de fem kildene et konsistent bilde selv om metodene er ulike: rå kryptografiske operasjoner er 60-70 prosent raskere med ECDHE ifølge IJARSCT, håndtrykk i produksjon er 44-45 prosent raskere ifølge bufferspeed.com, og nøkkelstørrelsen er nesten ti ganger mindre ved sammenlignbar sikkerhet ifølge Journal of Student Research. Ingen av kildene motsier hverandre i konklusjon, bare i hvor stor gevinsten måles til.

Spesifikasjonstabell: RSA-nøkkelutveksling mot ECDHE

EgenskapRSA-nøkkelutvekslingECDHE
Type kryptografisk primitivOffentlig nøkkelkryptering (nøkkeltransport)Diffie-Hellman over elliptisk kurve
Fremoverrettet hemmeligholdNei, ved statisk brukJa, per definisjon (efemær)
Typisk nøkkelstørrelse ved ~112-bit sikkerhet2048-3072 bit224-256 bit (f.eks. P-256)
Nøkkelgenereringstid (IJARSCT-studie)Over 2000 ms (RSA-3072)15-100 ms (ECDH-256)
Dekrypteringstid i simulert skymiljø~10 957 ms~187 ms
Status i TLS 1.3Fjernet heltPåkrevd
Status i TLS 1.2 etter RFC 10015 (2026)MUST NOT (forbudt)Anbefalt, akseptert reserveløsning
Kjente historiske angrepBleichenbacher, ROBOT, DROWNIngen tilsvarende protokollsvakhet
Kvantesårbarhet (Shors algoritme)Sårbar, RSA-2048 anslått ~1409 logiske qubitsSårbar, tilsvarende ressursbehov for sterke kurver
Governing standard (2026)RFC 10015 (deprecation)RFC 8446 (TLS 1.3), RFC 10015 (anbefalt)
Prising i AWS KMS per 10 000 operasjoner0,15 USD (asymmetrisk)0,15 USD (asymmetrisk, ingen forskjell)
Brukes fortsatt tilSertifikatsignering (autentisering)All ny nøkkelutveksling

Tabellen over samler tallene fra denne artikkelens research i ett oversiktsbilde. Det som skiller seg mest ut er kombinasjonen av rad fire og fem: forskjellen i nøkkelgenerering og dekrypteringstid er ikke marginal, den er på en størrelsesorden som faktisk merkes i produksjon ved høyt trafikkvolum. En tjeneste som håndterer titusenvis av nye TLS-tilkoblinger i sekundet vil legge merke til om hver håndtrykksoperasjon tar 10 millisekunder eller 2000 millisekunder ekstra CPU-tid, selv om enkeltbrukeren aldri merker forskjellen på sin egen skjerm.

Adopsjon: hvor står TLS 1.3 og ECDHE i praksis?

Tall fra Technologychecker sin analyse av HTTP-protokolladopsjon viser at TLS 1.3s andel av forespørsler økte fra 68,74 prosent i andre kvartal 2025 til 71,71 prosent i andre kvartal 2026. Samtidig falt TLS 1.2 fra 8,92 prosent til 6,07 prosent i samme periode. Den virkelig utdaterte TLS 1.0 og 1.1 utgjør nå bare 0,017 prosent av trafikken, altså praktisk talt utryddet.

Siden TLS 1.3 aldri har støttet RSA-nøkkeltransport i utgangspunktet, betyr disse tallene at over syv av ti tilkoblinger allerede bruker ECDHE eller en beslektet efemær Diffie-Hellman-variant som eneste nøkkelutveksling. De resterende 6,07 prosentene på TLS 1.2 er nå det direkte målet for RFC 10015, ettersom det er der RSA-nøkkelutveksling fortsatt kan forekomme i praksis.

Målt på vertsnivå snarere enn forespørselsnivå viser separate målinger at 85,2 prosent av undersøkte tjenere forhandler frem TLS 1.3 som standard. Forskjellen mellom forespørsel- og vertsmålinger illustrerer noe viktig: enkelte høytrafikk-tjenester på eldre TLS 1.2 drar ned forespørselsandelen, selv om et flertall av individuelle servere allerede er oppgradert.

Red Hats gjennomgang av kommende TLS-endringer peker på et beslektet poeng: selv om et flertall av trafikken nå går over ECDHE-baserte håndtrykk, henger konfigurasjonsarven etter. Mange organisasjoner satte opp cifferpakkelister for ti år siden og har aldri gått tilbake for å fjerne foreldede oppføringer, rett og slett fordi “det virker jo”. RFC 10015 endrer denne kalkylen: det er ikke lenger et spørsmål om beste praksis, men om formelt samsvar med en oppdatert internettstandard.

På ytelsessiden viser et produksjonscase fra desember 2025 at overgang til TLS 1.3 overalt senket global p95 responstid (TTFB) fra 318 til 194 millisekunder, en forbedring på rundt 40 prosent. Andelen fulle håndtrykk falt fra rundt 40 prosent til under 6 prosent, og feilede håndtrykk falt fra 1,2 til 0,4 prosent. Dette er en direkte konsekvens av at TLS 1.3 bruker ett rundtrip (1-RTT) i håndtrykket mot TLS 1.2s to rundtrips (2-RTT), noe som i praksis halverer handshake-forsinkelsen for nye tilkoblinger.

Prisen på nøkkeltype: hva sky-KMS faktisk koster

Et argument man sjelden ser i denne debatten er den rene infrastrukturkostnaden. Vi hentet gjeldende, offentlig publiserte priser fra AWS, Microsoft Azure og Google Cloud for å se om nøkkeltype faktisk påvirker regningen når nøkler forvaltes i en skytjeneste fremfor lokalt.

LeverandørNøkkeltypeLagringskostnadOperasjonskostnad
AWS KMSAlle typer (symmetrisk, RSA, ECC)1,00 USD per nøkkel/måned0,03 USD per 10 000 (symmetrisk)
AWS KMSAsymmetrisk (RSA og ECC)1,00 USD per nøkkel/måned0,15 USD per 10 000 operasjoner
AWS KMS (GovCloud)RSA GenerateDataKeyPair–11,88 USD per 10 000 forespørsler
Azure Key Vault (Premium)RSA 2048-bit1,00 USD per nøkkel/måned0,03 USD per 10 000 operasjoner
Azure Key Vault (Premium)RSA 3072/4096-bit og ECC5,00 USD per nøkkel/måned (første 250)0,15 USD per 10 000 operasjoner
Google Cloud HSMRSA 2048-bit1,00 USD per nøkkelversjon/måned0,03 USD per 10 000 operasjoner
Google Cloud HSMRSA 3072/4096 og EC P-256/P-3842,50 USD/måned (0-2000 nøkler), deretter 1,00 USD0,03 USD per 10 000 operasjoner

Det interessante funnet her er at AWS ikke prissetter RSA og ECC ulikt i det hele tatt, begge havner i samme “asymmetrisk”-kategori til 0,15 USD per 10 000 operasjoner ifølge AWS’ offisielle KMS-prisside. Azure og Google Cloud skiller derimot mellom RSA-2048 (billigst) og både høyere RSA-styrker og ECC-nøkler (dyrere per nøkkel per måned), som dokumentert på Azure Key Vaults prisside og Google Cloud KMS’ prisside. Konklusjonen for driftsbudsjettet: å bytte nøkkelutveksling til ECDHE koster ikke mer i sky-KMS, snarere tvert imot siden ECC-operasjoner ofte krever færre CPU-sykluser bak kulissene selv om den listede prisen er lik.

Det er verdt å understreke at denne prisstrukturen gjelder nøkler forvaltet direkte i en sky-KMS eller HSM-tjeneste, ikke selve TLS-håndtrykket. De aller fleste RSA- eller ECDHE-nøkkelutvekslinger i et vanlig webhotell eller CDN-oppsett skjer helt uavhengig av disse tjenestene og koster ingenting ekstra uansett algoritme. Tabellen er mest relevant for virksomheter som bruker maskinvaresikrede nøkler (HSM) til sertifikatutstedelse, signering, eller sentralisert nøkkelforvaltning i regulerte bransjer som bank og forsikring, der akkurat denne kostnadsforskjellen faktisk vises på fakturaen hver måned.

Fem virkelige eksempler på hvordan dette spiller seg ut

1. IETF og RFC 10015 (juli 2026). Dette er selve utløseren for hele saken: en standardiseringsorganisasjon som formelt fjerner en kryptografisk mekanisme fra en TLS-protokollversjon fortsatt i utbredt bruk, ikke bare som en anbefaling, men med bindende MUST NOT-språk.

2. TLS 1.3s design (RFC 8446). Protokollen fjernet RSA-nøkkeltransport fra dag én, og krever ECDHE eller DHE for enhver tilkobling. Dette var forhåndsvisningen av det RFC 10015 nå gjør obligatorisk også i TLS 1.2.

3. Red Hats TLS-forklaringsserie. Red Hat har offentlig dokumentert at RSA-sertifikater fortsatt kan brukes til autentisering i TLS 1.3, men at all nøkkeletablering må skje via Diffie-Hellman, en presis illustrasjon av skillet mellom autentisering og nøkkelutveksling som mange utviklere overser.

4. Azure Key Vaults prisstruktur. Microsoft har konkret priset “avanserte nøkkeltyper” (RSA 3072, RSA 4096, og ECC) høyere enn standard RSA-2048 i Premium-tieret, et tegn på at større RSA-nøkler (nødvendig etter hvert som RSA-2048 blir ansett svakere) faktisk koster mer enn å bytte til elliptisk kurve.

5. NSAs CNSA 2.0-krav. Ifølge sammendrag av USAs Commercial National Security Algorithm Suite 2.0 skal nye nasjonale sikkerhetssystemer støtte kvanteresistent kryptografi fra 2027, med sikte på at RSA og ECC skal fases ut innen 2030 og forbys innen 2035 i visse høyrisikosammenhenger. Dette legger et konkret tidspress på både RSA- og ECDHE-brukere til å begynne å planlegge for hybrid post-kvante-nøkkelutveksling, ikke bare bytte fra én klassisk algoritme til en annen.

Sikkerhet utover forward secrecy

Fremoverrettet hemmelighold er hovedargumentet, men ikke det eneste. RSA-nøkkeltransport krever at serveren dekrypterer data sendt av klienten, en operasjon som lekker informasjon gjennom feilmeldinger og tidsforskjeller hvis den ikke implementeres nøyaktig etter spesifikasjonen. Det er derfor Bleichenbacher-varianter har dukket opp gjentatte ganger i tiårene etter det opprinnelige funnet i 1998, sist som ROBOT-angrepet i 2018 og DROWN i 2016. RFC 10015 peker konkret på dette som en strukturell svakhet man ikke lenger vil stole på at implementasjoner unngår korrekt.

ECDHE unngår denne klassen av angrep helt fordi den aldri krypterer noe med en langsiktig nøkkel i utvekslingen. Det betyr ikke at elliptisk kurve-kryptografi er immun mot alle implementasjonsfeil, sidekanalangrep mot dårlig implementerte kurveoperasjoner har forekommet, men risikobildet er strukturelt annerledes og har historisk vist seg vanskeligere å utnytte i praksis mot moderne biblioteker som OpenSSL og BoringSSL.

Verdt å nevne er at fremoverrettet hemmelighold også endrer hvordan man bør tenke om trafikklogging og etterretning. Med statisk RSA-nøkkeltransport kan en organisasjon som lagrer krypterte pakkedumper i årevis, dekryptere alt sammen i ettertid dersom den private nøkkelen på et tidspunkt lekker, stjeles av en insider, eller beslaglegges av en myndighet. Med ECDHE finnes det ingen slik enkelt nøkkel å beslaglegge, fordi hver økt har sin egen, midlertidige nøkkel som kastes umiddelbart etter bruk. Dette er en av grunnene til at etterretningstjenester historisk har vært spesielt interessert i å samle inn RSA-krypterte data for senere dekryptering, en praksis kjent som “harvest now, decrypt later”, som ECDHE i praksis gjør mye vanskeligere for klassiske angripere.

Post-kvante-skyggen over begge algoritmene

Det er fristende å si at ECDHE “vinner” og saken er avgjort, men begge algoritmene deler samme langsiktige skjebne. Shors algoritme, kjørt på en tilstrekkelig stor feiltolerant kvantedatamaskin, bryter både RSA og elliptisk kurve-Diffie-Hellman like effektivt. Et 2025-anslag referert av PostQuantum.com setter ressursbehovet for å bryte RSA-2048 til rundt 1409 logiske qubits og 6,5 milliarder Toffoli-porter, tilsvarende omtrent 898 000 fysiske qubits og fem dagers kjøretid på en hypotetisk stor kvantedatamaskin. Tilsvarende ressursanslag gjelder for sterke elliptiske kurver, siden begge er strukturelt sårbare for samme klasse angrep.

Dette er grunnen til at bransjen samtidig beveger seg mot hybride nøkkelutvekslinger som kombinerer ECDHE med en post-kvante-KEM som ML-KEM (tidligere kjent som Kyber). Vi har dekket denne overgangen i detalj i artikkelen om ML-KEM vs RSA, der 65 prosent av målt trafikk allerede var kvantesikret ved hybrid-oppsett. Konklusjonen for 2026 er derfor todelt: bytt fra RSA til ECDHE nå for umiddelbar sikkerhetsgevinst og RFC 10015-samsvar, men begynn parallelt å teste hybrid post-kvante-nøkkelutveksling for den langsiktige trusselen.

Den nevnte sammendragsartikkelen om CNSA 2.0 setter et konkret tall på dette presset: nye nasjonale sikkerhetssystemer i USA skal støtte kvanteresistent kryptografi fra 2027, med sikte på at både RSA og klassisk ECC skal deprioriteres innen 2030 og forbys i visse høyrisikosammenhenger innen 2035. Selv om dette er amerikanske krav, følger EU og andre jurisdiksjoner ofte samme tidslinje for kritisk infrastruktur, noe som betyr at norske virksomheter med internasjonale kunder eller leverandørkjeder bør regne CNSA 2.0-tidslinjen som en reell planleggingshorisont, ikke bare en amerikansk særordning.

Migreringsguide: fra RSA-nøkkelutveksling til ECDHE

De fleste moderne servere har allerede ECDHE aktivert som standard, men mange eldre TLS 1.2-oppsett har RSA-cifferpakker liggende igjen som reserveløsning “for sikkerhets skyld”. Slik rydder du opp:

  1. Kartlegg nåværende cifferpakker med testssl.sh eller SSL Labs’ serververktøy for å se hvilke RSA-baserte pakker som fortsatt er aktive.
  2. Identifiser alle TLS_RSA_*-pakker i konfigurasjonen din (Nginx, Apache, HAProxy eller lastbalanserer) og noter dem før du fjerner noe.
  3. Oppdater cipher-suite-listen til kun å tillate ECDHE- og DHE-baserte pakker, for eksempel ECDHE-RSA-AES256-GCM-SHA384 eller ECDHE-ECDSA-AES128-GCM-SHA256.
  4. Behold RSA-sertifikatet ditt hvis du allerede har ett, det brukes fortsatt til autentisering og påvirkes ikke av denne endringen.
  5. Test kompatibilitet mot eldre klienter i din brukerbase, spesielt gamle mobile enheter eller interne systemer som kanskje mangler moderne cifferstøtte.
  6. Aktiver TLS 1.3 der det ikke allerede er på, siden det automatisk håndhever ECDHE/DHE og fjerner behovet for manuell cifferpakke-styring for nye tilkoblinger.
  7. Kjør et nytt skann med SSL Labs eller testssl.sh og bekreft at ingen RSA-nøkkelutvekslingspakker lenger forhandles.
  8. Overvåk feilrater og handshake-tid etter endringen for å fange opp eventuelle inkompatible klienter tidlig.
  9. Dokumenter endringen i din interne sikkerhetsbaseline, spesielt hvis dere er underlagt NIS2 eller tilsvarende krav om oppdatert kryptografisk praksis.
  10. Sett en påminnelse om å evaluere hybrid post-kvante-nøkkelutveksling (ECDHE + ML-KEM) i løpet av de neste 12-18 månedene.
# Eksempel: Nginx-konfigurasjon som kun tillater ECDHE-baserte pakker
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve X25519:prime256v1:secp384r1;

Eksempelet over beholder både TLS 1.2 og TLS 1.3 aktivert for bakoverkompatibilitet, men fjerner enhver referanse til rene RSA-cifferpakker fra listen. Legg merke til at hver cifferpakke i listen starter med ECDHE, som betyr at nøkkelutvekslingen alltid skjer via elliptisk kurve-Diffie-Hellman uansett hvilken av pakkene som til slutt forhandles frem. Den siste linjen definerer hvilke kurver serveren er villig til å bruke, med X25519 først fordi det generelt er den raskeste og mest moderne kurven tilgjengelig i dagens OpenSSL-versjoner.

Vanlige feil under migreringen

Den vanligste feilen er å anta at man allerede er trygg fordi TLS 1.3 er aktivert. TLS 1.3 tvinger frem ECDHE eller DHE for alle nye tilkoblinger på den protokollversjonen, men de fleste servere har fortsatt TLS 1.2 aktivert samtidig for bakoverkompatibilitet. Hvis TLS 1.2-konfigurasjonen ikke er ryddet opp separat, kan eldre klienter fortsatt forhandle frem RSA-nøkkelutveksling selv om nyere klienter automatisk havner på TLS 1.3.

En annen fallgruve er å fjerne RSA-cifferpakker uten å teste mot faktiske klienter i egen brukerbase først. Interne systemer, gamle betalingsterminaler eller eldre Android-versjoner kan mangle støtte for moderne cifferpakker, og en for aggressiv opprydding kan skape utilsiktede driftsavbrudd. Det er derfor migreringsguiden over anbefaler et eget kompatibilitetstrinn før den endelige verifiseringen.

En tredje feil er å tro at RSA er helt utfaset når man i realiteten bare har fjernet det fra nøkkelutvekslingen. RSA-signerte sertifikater er fortsatt vanlig og fullt lovlig i TLS 1.3, og forveksling mellom “RSA i sertifikatet” og “RSA i nøkkelutvekslingen” fører ofte til unødvendig sertifikatfornyelse når det egentlig bare var cipher-suite-listen som trengte oppdatering.

Bruksområder: når velge hva

Ikke alle organisasjoner har samme presserende behov, og noen har allerede løst dette uten å vite det fordi standardinnstillingene i moderne rammeverk og lastbalanserere allerede prioriterer ECDHE. Under følger seks konkrete situasjoner der valget mellom RSA-nøkkelutveksling og ECDHE bør veie tyngre enn “det vi alltid har brukt”.

Offentlige og kommunale nettsteder i Norge: Bør prioritere ECDHE umiddelbart. Med NIS2 og Digitaliseringsdirektoratets krav om oppdatert sikkerhetspraksis er RFC 10015-samsvar en lavthengende frukt som bør fikses i neste vedlikeholdsvindu.

Betalingstjenester og e-handel: PCI DSS-krav om sterk kryptografi gjør ECDHE med fremoverrettet hemmelighold til et de facto krav, ikke bare en anbefaling. Manglende forward secrecy kan bli et avvik i neste revisjon.

IoT og innebygde enheter: Mindre nøkkelstørrelser i ECDHE (256 bit mot RSA sine 2048-3072 bit) betyr mindre minnebruk og raskere håndtrykk på begrenset maskinvare, noe som gjør ECDHE til et naturlig valg fremfor RSA-baserte løsninger på svak CPU.

Eldre bedriftssystemer på TLS 1.2: Dette er gruppen RFC 10015 faktisk rammer direkte. Hvis lastbalansereren eller VPN-konsentratoren din fortsatt tilbyr RSA-cifferpakker, er dette den mest presserende migreringen å gjennomføre før neste sikkerhetsrevisjon.

Skybaserte mikrotjenester med mTLS: De fleste moderne service mesh-løsninger (Istio, Linkerd) bruker allerede ECDHE som standard, så her handler det mest om å verifisere konfigurasjonen fremfor å gjøre en aktiv migrering.

Forsvars- og sikkerhetssektoren: Med CNSA 2.0-kravet om kvanteresistent støtte fra 2027, bør denne sektoren allerede nå teste hybrid ECDHE+ML-KEM-oppsett parallelt med den umiddelbare RSA-til-ECDHE-migreringen.

Fordeler og ulemper

RSA-nøkkelutveksling

  • Fordel: Enkel å forstå og implementere konseptuelt, kun én kryptografisk operasjon.
  • Fordel: Bred historisk støtte i eldre klienter og biblioteker.
  • Ulempe: Ingen fremoverrettet hemmelighold ved statisk bruk.
  • Ulempe: Sårbar for Bleichenbacher-varianter (ROBOT, DROWN) gjentatte ganger over flere tiår.
  • Ulempe: Tregere nøkkeloperasjoner og større nøkler ifølge IJARSCT-benchmarken.
  • Ulempe: Formelt forbudt for nøkkelutveksling i TLS 1.2 etter RFC 10015 og allerede fjernet fra TLS 1.3.

ECDHE

  • Fordel: Fremoverrettet hemmelighold innebygd i designet.
  • Fordel: Betydelig raskere nøkkelgenerering og mindre nøkler ved sammenlignbar sikkerhet.
  • Fordel: Påkrevd i TLS 1.3 og anbefalt av RFC 10015 for TLS 1.2.
  • Fordel: Ingen kjent strukturell svakhet tilsvarende Bleichenbacher-familien.
  • Ulempe: Fortsatt fullt sårbar for Shors algoritme på en tilstrekkelig stor kvantedatamaskin.
  • Ulempe: Krever korrekt kurveimplementasjon for å unngå sidekanalangrep i dårlig skrevne biblioteker.

Verdikt: hvem vinner nøkkelutvekslingen i 2026?

Basert på tallene er svaret entydig for nøkkelutveksling spesifikt: ECDHE vinner på nesten alle målbare punkter. Opptil 60 ganger raskere dekrypteringstid i simulerte skymiljøer, 60-70 prosent raskere nøkkelgenerering ifølge IJARSCT-studien, innebygd fremoverrettet hemmelighold, ingen kjent strukturell sårbarhet tilsvarende Bleichenbacher, og nå også formelt påkrevd status gjennom RFC 10015 i TLS 1.2 og RFC 8446 i TLS 1.3. Med 71,71 prosent av all TLS-trafikk allerede på TLS 1.3 ifølge Technologycheckers 2026-tall, er ECDHE allerede standarden for det store flertallet av internett.

Det som gjenstår er opprydding: de resterende 6,07 prosentene på TLS 1.2 må fjerne RSA- og FFDHE-cifferpakker for å følge RFC 10015. Dette er ikke en stor teknisk jobb for de fleste, ofte en enkelt konfigurasjonsendring i lastbalansereren, men det krever at noen faktisk gjør det. RSA beholder fortsatt sin plass i autentisering gjennom sertifikater, den jobben er ikke i fare. Den lengre historien handler uansett ikke om RSA mot ECDHE, men om klassisk kryptografi mot post-kvante-kryptografi, en overgang som etter alt å dømme vil dominere resten av tiåret.

For deg som drifter et nettsted, en API eller en intern tjeneste, er den praktiske oppgaven denne: sjekk om TLS 1.2-oppsettet ditt fortsatt tilbyr RSA-nøkkelutveksling, fjern det hvis det gjør det, og behold RSA-sertifikatet ditt urørt hvis det fungerer i dag. Det er en liten endring med stor symbolsk og praktisk betydning, den markerer at nettstedet ditt følger en internettstandard fra 2026 fremfor en arv fra 1996. Gitt hvor lite arbeid som faktisk kreves for de fleste moderne oppsett, er det vanskelig å finne et godt argument for å utsette det.

Ofte stilte spørsmål

Betyr RFC 10015 at RSA-sertifikater ikke lenger fungerer?

Nei. RFC 10015 gjelder kun nøkkelutveksling, altså hvordan partene etablerer en delt hemmelighet. RSA-signerte sertifikater kan fortsatt brukes til autentisering i både TLS 1.2 og TLS 1.3.

Er ECDHE tregere enn RSA slik eldre kilder hevder?

Eldre sammenligninger fra rundt 2015 målte gjerne kun rå nøkkelutvekslingshastighet uten moderne kurveimplementasjoner, og fant at RSA var raskere isolert sett. Nyere studier, som IJARSCT-analysen fra 2025, viser at moderne ECDH-implementasjoner er 60-70 prosent raskere enn RSA ved sammenlignbar sikkerhet.

Må jeg oppgradere til TLS 1.3 for å følge RFC 10015?

Nei, RFC 10015 gjelder spesifikt TLS 1.2 og DTLS 1.2. Du kan følge kravet ved å fjerne RSA- og FFDHE-cifferpakker fra TLS 1.2-konfigurasjonen, men å oppgradere til TLS 1.3 løser problemet automatisk siden protokollen aldri har støttet disse nøkkelutvekslingene.

Koster det mer å bruke ECDHE-nøkler i en skytjeneste?

Ifølge offentlig prising fra AWS er kostnaden identisk mellom RSA og ECC for asymmetriske operasjoner (0,15 USD per 10 000 operasjoner). Azure og Google Cloud priser derimot ECC og høyere RSA-styrker likt, men høyere enn standard RSA-2048, så et bytte til ECDHE koster ikke mer og kan i praksis bli billigere avhengig av leverandør.

Er ECDHE trygt mot kvantedatamaskiner?

Nei. Både RSA og ECDHE er sårbare for Shors algoritme på en tilstrekkelig stor feiltolerant kvantedatamaskin. Løsningen på lang sikt er hybrid nøkkelutveksling som kombinerer ECDHE med en post-kvante-KEM som ML-KEM.

Hva skjer hvis jeg ikke fjerner RSA-cifferpakker fra TLS 1.2?

RFC 10015 er ikke selvhåndhevende, ingen “kryptografipoliti” stenger tjeneren din automatisk. Men manglende samsvar kan bli flagget i sikkerhetsrevisjoner, PCI DSS-vurderinger, eller NIS2-relaterte tilsyn, og eksponerer deg fortsatt for Bleichenbacher-varianter så lenge cifferpakkene er aktive.

Hvordan sjekker jeg om nettstedet mitt fortsatt bruker RSA-nøkkelutveksling?

Kjør et skann med SSL Labs’ gratis serververktøy eller kommandolinjeverktøyet testssl.sh. Begge lister opp alle forhandlede cifferpakker og flagger eksplisitt om RSA-nøkkeltransport eller FFDHE fortsatt er aktivert.

Påvirker dette VPN og andre ikke-web-protokoller?

RFC 10015 gjelder formelt (D)TLS 1.2, som brukes langt utover nettlesertrafikk, blant annet i VPN-løsninger som OpenVPN i TLS-modus, e-postservere med STARTTLS, og enkelte IoT-plattformer. Alle disse bør gjennomgå samme kartlegging og opprydding som beskrevet i migreringsguiden, siden de fleste bygger på de samme underliggende TLS-bibliotekene som webservere.

Er DHE (uten elliptisk kurve) et akseptabelt alternativ til ECDHE?

Nei, ikke lenger. RFC 10015 fjerner både statisk og efemær Diffie-Hellman over endelig felt (FFDHE) fra TLS 1.2, ikke bare RSA. ECDHE, eventuelt en hybrid post-kvante-KEM, er de eneste anbefalte nøkkelutvekslingene som gjenstår etter denne oppryddingen.