Hver gang en nettleser åpner en HTTPS-side, skjer det en liten avgjørelse i bakgrunnen: skal serveren bevise sin identitet med RSA eller med ECDSA? Valget påvirker hastighet, båndbredde og hvor godt sertifikatet tåler fremtidens datamaskiner. I 2026 er begge algoritmene fortsatt i aktiv drift hos de største sertifikatutstederne, men fordelingen mellom dem har begynt å skifte i favør av den yngre av de to.

Denne artikkelen sammenligner ECDSA og RSA på nøkkelstørrelse, signeringshastighet, sertifikatpris og reell bruk i produksjon. Vi bygger på ytelsestall fra flere uavhengige kilder, offisiell prising fra sertifikatutstedere og data fra Certificate Transparency-logger. Målet er å gi et konkret svar på hvilken algoritme som passer best til hvilket formål, ikke bare en teoretisk gjennomgang av matematikken bak dem.

For norske og nordiske virksomheter er spørsmålet ikke bare akademisk. Offentlige etater, banker og skytjenester som drifter infrastruktur i Norge må forholde seg til krav om godkjente algoritmer og nøkkelstørrelser når de setter opp TLS på nye tjenester. Verken RSA eller ECDSA er forbudt eller pålagt i norsk regelverk, men valget påvirker hvor raskt en tjeneste svarer, hvor mye båndbredde som går med til hver tilkobling, og hvor enkelt det blir å bytte algoritme den dagen post-kvante-krav blir obligatorisk. Det gjør en grundig sammenligning nyttig for alle som setter opp eller fornyer sertifikater i 2026, uavhengig av bransje.

Historien bak de to algoritmene

RSA har nesten et tiår forsprang på ECDSA i praktisk bruk. Algoritmen ble beskrevet i 1977 og kom raskt i bruk i tidlige sikre kommunikasjonssystemer på 1980- og 90-tallet, lenge før HTTPS ble vanlig. Elliptisk kurve-kryptografi ble foreslått uavhengig av Neal Koblitz og Victor Miller i 1985, men det tok nesten to tiår før algoritmene var standardisert og utbredt nok til å konkurrere med RSA i vanlig nettrafikk. NIST publiserte de første offisielle kurveparameterne på 1990-tallet, og ECDSA ble en del av FIPS 186-standarden i 2000.

Den brede overgangen til ECDSA i TLS kom først etter 2013, da store nettlesere og servere hadde bygget opp moden støtte for elliptiske kurver, og etter at forskningsmiljøet hadde brukt over et tiår på å teste kurvene for svakheter. RSA har dermed rukket å bli grundig gjennomgått i over 45 år, mens ECDSA i TLS-sammenheng har vært i utbredt bruk i litt over ti år. Denne modenhetsforskjellen er en av grunnene til at enkelte konservative bransjer, som deler av finanssektoren, fortsatt foretrekker RSA i kjernesystemer selv om ytelsesfordelene til ECDSA er godt dokumentert.

Hva er RSA og hva er ECDSA?

Begge algoritmene løser samme problem, digital signering og nøkkelutveksling, men de bygger på helt forskjellig matematikk. Det påvirker alt fra nøkkelstørrelse til hvor raskt en server kan signere tusenvis av forespørsler i sekundet.

RSA: faktorisering av store primtall

RSA ble publisert i 1977 av Rivest, Shamir og Adleman, og er fortsatt en av de mest brukte asymmetriske algoritmene i verden. Sikkerheten hviler på at det er praktisk umulig å faktorisere produktet av to store primtall innen rimelig tid med klassiske datamaskiner. For å oppnå et sikkerhetsnivå som regnes som trygt i dag, må RSA-nøkler være store, typisk 2048, 3072 eller 4096 bit. Det gjør nøklene tunge å generere og signaturene store å overføre, men algoritmen har over 45 år med praktisk erfaring bak seg og støttes av så godt som alt av eldre og nyere programvare.

I praksis brukes RSA på to litt forskjellige måter i moderne systemer. Den ene er ren signering, der en privat nøkkel signerer en melding eller et sertifikat og hvem som helst kan verifisere signaturen med den offentlige nøkkelen. Den andre er nøkkelutveksling i eldre TLS-versjoner, der RSA brukes direkte til å kryptere en øktnøkkel. TLS 1.3 har fjernet RSA som nøkkelutvekslingsmekanisme og bruker i stedet Diffie-Hellman-baserte metoder, men RSA lever videre som signeringsalgoritme for selve sertifikatet i begge protokollversjoner.

ECDSA: diskret logaritme på elliptisk kurve

ECDSA (Elliptic Curve Digital Signature Algorithm) bruker punkter på en elliptisk kurve i stedet for store primtall. Sikkerheten hviler på det diskrete logaritme-problemet for elliptiske kurver, et problem som er vesentlig vanskeligere å knekke per bit enn RSA sin faktorisering. Resultatet er at en 256-bits ECDSA-nøkkel (kurven P-256) gir omtrent samme sikkerhetsnivå som en 3072-bits RSA-nøkkel. NIST standardiserte algoritmen i FIPS 186, og den formelle spesifikasjonen finnes i FIPS 186-5 fra NIST. En vanlig svakhet i tidlige implementasjoner var dårlig tilfeldighet i signeringen (nonce-verdien), noe RFC 6979 løste ved å gjøre nonce-genereringen deterministisk. Den fullstendige spesifikasjonen ligger i RFC 6979.

Det finnes flere godkjente kurver å velge mellom, og valget av kurve påvirker både sikkerhet og ytelse. P-256 (også kalt secp256r1 eller prime256v1) er desidert mest brukt i TLS-sertifikater i dag, mens P-384 velges av organisasjoner som ønsker et høyere sikkerhetsnivå på bekostning av noe lavere ytelse. Kurven secp256k1, kjent fra Bitcoin og Ethereum, er teknisk sett en egen kurve med andre parametere enn P-256, valgt av opprinnelige designere for spesifikke matematiske egenskaper som er nyttige i et desentralisert system, ikke fordi den er raskere eller sikrere for generell TLS-bruk.

Nøkkelstørrelse og sikkerhetsnivå side ved side

Den mest håndfaste forskjellen mellom de to algoritmene er hvor mye plass de tar. Tabellen under viser hvordan nøkkel- og signaturstørrelse utvikler seg etter hvilket sikkerhetsnivå man sikter mot, og hvorfor RSA vokser mye raskere enn ECDSA når kravene skjerpes.

EgenskapRSAECDSA
Matematisk grunnlagFaktorisering av store primtallDiskret logaritme på elliptisk kurve
Nøkkelstørrelse for ~128-bit sikkerhet3072 bit256 bit (kurven P-256)
Offentlig nøkkelstørrelse (SPKI, ca.)~294 byte ved 2048 bit~65 byte ved P-256 (ukomprimert)
Signaturstørrelse256 byte (2048-bit) / 512 byte (4096-bit)~64-72 byte (P-256, DER-kodet)
Sikkerhetsnivå, RSA-2048 mot ECDSA P-256~112-bit~128-bit
Sikkerhetsnivå, RSA-3072 mot ECDSA P-256~128-bit~128-bit
Sikkerhetsnivå, RSA-4096 mot ECDSA P-384~140-152-bit~192-bit
Vanlige varianter2048, 3072, 4096 bitP-256, P-384, P-521, secp256k1
Nøkkelgenereringstid (relativt)Sekunder ved 4096 bitMillisekunder
KvanteresistensIngen, sårbar for Shors algoritmeIngen, sårbar for Shors algoritme
Standardisert iRFC 8017 (PKCS#1)FIPS 186-5 og RFC 6979
NettleserstøtteAlle, siden tidlig 2000-tallAlle større nettlesere siden rundt 2013
Typisk bruksområdeEldre systemer, e-postsignering, PDF-signaturTLS-sertifikater, SSH, kryptovaluta, moderne PKI

Legg merke til at nøkkelstørrelsen for ECDSA vokser lineært med sikkerhetsnivået, mens RSA-nøkkelen må vokse mye raskere for å holde tritt. Det er hovedgrunnen til at ECDSA fortsatt gir kompakte sertifikater selv når sikkerhetskravene skjerpes fremover. Sammenligningen mellom nøkkelstørrelse i klassiske kurver kan sees i praksis hos Keylength.com sin oversikt over nøkkellengder, som samler anbefalinger fra flere standardiseringsorgan i én tabell.

Et annet moment som sjelden nevnes er hvordan nøkkelstørrelsen påvirker signeringskjeder med flere ledd. Et sertifikat blir aldri stående alene, det følger normalt med minst ett mellomsertifikat opp til en rot som nettleseren allerede stoler på. Hvert ledd i denne kjeden bærer sin egen signatur, så forskjellen i signaturstørrelse multipliseres med antall ledd i kjeden. For en tre-ledds kjede kan forskjellen mellom RSA-2048 og ECDSA P-256 fort utgjøre flere hundre byte totalt, noe som er merkbart første gang en klient kobler til og må laste ned hele kjeden før den krypterte forbindelsen er klar. Effekten forsterkes ytterligere av at TCP i utgangspunktet sender data i pakker med en fast maksimal størrelse (MTU), så en større sertifikatkjede kan i verste fall kreve en ekstra pakke i selve håndhilsen, noe som legger til en hel ekstra tur-retur-forsinkelse (RTT) før forbindelsen er ferdig etablert.

Ytelse i praksis: tre uavhengige tester

Nøkkelstørrelse er interessant på papiret, men det som faktisk merkes på en produksjonsserver er hvor raskt algoritmen signerer og verifiserer. Her skiller RSA og ECDSA seg kraftig fra hverandre, og retningen er ikke entydig, RSA vinner faktisk på ett av målene.

OperasjonRSA-2048ECDSA P-256
Signeringer per sekund (OpenSSL speed-referanse)934,623.119
Nøkkelgenerering142,98 ms26,76 ms
Signering, enkeltoperasjon3,25 ms1,56 ms
Verifisering, enkeltoperasjon0,12 ms3,67 ms

Den første raden kommer fra en OpenSSL speed-referansetest kjørt i 2026, der ECDSA P-256 klarte om lag 25 ganger flere signeringsoperasjoner per sekund enn RSA-2048. Den andre kilden, en uavhengig 2026-ytelsestest av nøkkelgenerering, signering og verifisering hver for seg, bekrefter mønsteret for signering og nøkkelgenerering, men snur bildet for verifisering. RSA-2048 verifiserer en signatur på 0,12 millisekunder, mens ECDSA P-256 bruker rundt 3,67 millisekunder på samme operasjon. Grunnen er at RSA sin offentlige eksponent normalt er et lite tall (65537), noe som gjør verifisering svært billig, mens ECDSA krever full punktmultiplikasjon på kurven for hver verifisering.

Den tredje kilden er Cloudflare selv. Selskapet har i flere år argumentert for at ECDSA gir bedre ytelse i praksis fordi de mindre nøklene reduserer både CPU-bruk og mengden data som må sendes i en TLS-håndhilsen, samtidig som de påpeker at RSA og ECDSA kan gi likeverdig sikkerhet når nøklene er riktig dimensjonert. Les mer i Cloudflares gjennomgang av ECDSA. For en tjeneste som håndterer millioner av nye TLS-forbindelser hvert sekund, betyr signeringskostnaden mer enn verifiseringskostnaden, siden serveren signerer på hver ny håndhilsen mens klienten kun verifiserer én gang per tilkobling. Det er derfor store CDN-er og skytjenester generelt foretrekker ECDSA på serversiden.

Ytelse på ulik maskinvare: server, mobil og IoT

Tallene over gjelder for typisk servermaskinvare, men bildet endrer seg noe når man beveger seg til mindre kraftige enheter. Mange moderne x86- og ARM-prosessorer har innebygd akselerasjon for enkelte RSA-operasjoner gjennom instruksjonssett som reduserer kostnaden ved store heltallsoperasjoner, mens ECDSA sin fordel på slike prosessorer først og fremst kommer fra at operasjonene i seg selv er mindre regnetunge, ikke fra spesialisert maskinvarestøtte. På rene ARM-baserte servere, som stadig flere skytilbydere bruker for å kutte strømforbruk, er ECDSA sitt forsprang på signering ofte enda tydeligere enn på eldre x86-maskinvare, siden ARM-kjerner historisk har hatt mindre optimalisert støtte for de store heltallsoperasjonene RSA krever.

For batteridrevne enheter og IoT-utstyr er forskjellen enda mer merkbar. Nøkkelgenerering med RSA-2048 kan ta over 100 millisekunder på en kraftig server, og betydelig lenger på en svak innebygd prosessor, mens ECDSA-nøkler genereres på en brøkdel av tiden uansett maskinvare. For enheter med begrenset batterikapasitet, som sensorer i industrielle IoT-nett, kan denne forskjellen bety merkbart lavere strømforbruk over enhetens levetid, selv om selve TLS-trafikkmengden er liten sammenlignet med en vanlig nettside.

Sertifikatstørrelse og TLS-håndhilsen

Et TLS-sertifikat inneholder mer enn selve nøkkelen, det bærer også metadata, signaturen fra utstederen og ofte en hel kjede av mellomliggende sertifikater. Fordi ECDSA-nøkler og -signaturer er mye mindre enn RSA sine, blir hele sertifikatkjeden lettere å overføre. En typisk RSA-2048-sertifikatkjede med to mellomsertifikater kan fort komme opp i flere kilobyte, mens en tilsvarende ECDSA P-256-kjede ofte er under halvparten så stor.

Forskjellen merkes mest på trege eller ustabile mobilnett, der hver ekstra pakke øker sjansen for retransmisjon og forsinkelse. Under TLS 1.3-håndhilsen sendes sertifikatet i klartekst før den krypterte kanalen er etablert, så en mindre sertifikatkjede betyr kortere tid til første byte med data. Google og Cloudflare har begge pekt på dette som en av hovedgrunnene til at store nettsteder migrerer til ECDSA som standard, samtidig som de beholder RSA som reserveløsning for eldre klienter som ikke støtter elliptisk kurve-kryptografi. Let’s Encrypt håndterer nettopp dette ved å utstede separate sertifikatkjeder for de to nøkkeltypene, dokumentert i deres integrasjonsguide for utstedere og servere.

OCSP-stapling, mekanismen som lar en server bekrefte at eget sertifikat ikke er tilbakekalt uten at klienten må spørre utstederen direkte, fungerer likt for begge algoritmer og påvirkes ikke av valget mellom RSA og ECDSA. Det samme gjelder støtte for wildcard-sertifikater og multi-domene-sertifikater (SAN-sertifikater), som begge sertifikatutstedere tilbyr uavhengig av nøkkelalgoritme. Den eneste praktiske begrensningen oppstår hvis en organisasjon bruker maskinvaresikkerhetsmoduler (HSM-er) som er kjøpt inn spesifikt for RSA-operasjoner og som ikke støtter elliptisk kurve-kryptografi uten en fastvareoppdatering eller ny lisens.

Sikkerhet: styrker og svakheter

Ingen av algoritmene er iboende “sikrere” enn den andre når nøklene er riktig dimensjonert og implementasjonen følger standardene. Begge har derimot egne fallgruver som utviklere må kjenne til.

RSA sin største risiko ligger i konfigurasjonsfeil: for korte nøkler (under 2048 bit regnes i dag som utrygt), svak eller manglende padding (PKCS#1 v1.5 uten riktige mottiltak har historisk gitt opphav til Bleichenbacher-angrep), og gjenbruk av primtall på tvers av nøkkelpar generert med dårlige tilfeldighetskilder. Disse er kjente problemer med kjente løsninger, men de krever at implementasjonen faktisk følger anbefalt praksis, noe OWASP dokumenterer i sin veiledning for kryptografisk lagring. Moderne kryptografibiblioteker håndterer disse fallgruvene automatisk for utviklere som bruker standard API-er, så risikoen ligger i praksis nesten utelukkende hos egenskrevet eller svært gammel kryptografikode som ikke er oppdatert på mange år.

ECDSA sin største historiske svakhet var nonce-generering. Dersom samme tilfeldige tall (k-verdien) brukes to ganger, eller hvis tallet lekker delvis gjennom en implementasjonsfeil, kan en angriper regne ut hele den private nøkkelen fra kun to signaturer. Dette har rammet virkelige systemer, blant annet en tidlig Sony PlayStation 3-implementasjon der en fast k-verdi gjorde det mulig å hente ut signeringsnøkkelen. RFC 6979 løser problemet ved å gjøre k-verdien deterministisk utledet fra meldingen og den private nøkkelen, slik at samme inndata alltid gir samme, men ikke gjenbrukte, signatur.

Begge algoritmene er også utsatt for sidekanalangrep dersom implementasjonen lekker informasjon gjennom tidsbruk, strømforbruk eller cache-oppførsel under signeringen. Slike angrep krever normalt fysisk eller svært tett nærhet til maskinvaren som signerer, og er derfor mest relevant for smartkort, hardware-lommebøker og innebygde enheter fremfor vanlige nettservere. Godt vedlikeholdte kryptografibiblioteker som OpenSSL, BoringSSL og LibreSSL implementerer mottiltak mot de mest kjente sidekanalangrepene for begge algoritmer, men eldre eller egenutviklet kryptografikode bør alltid gjennomgås av noen med spesialkompetanse før den settes i produksjon.

Adopsjon i 2026: hvem velger hva

Tallene på hvor mange sertifikater som faktisk bruker hver algoritme spriker mellom ulike målemetoder, noe som i seg selv sier noe om hvor jevnt løpet har blitt. En analyse av Certificate Transparency-logger fra august 2026 fant at ECDSA sto for 50,53 prosent av alle sertifikatoppføringer mot 49,47 prosent for RSA, tilnærmet dødt løp. Ser man kun på endelige, utstedte sertifikater i samme datasett, lå RSA litt foran med 51,51 prosent, mens ECDSA dominerte forhåndssertifikatene med 52,52 prosent.

En annen 2026-undersøkelse av bladsertifikater på åpne nettsteder tegnet et litt annet bilde: 61,6 prosent RSA mot 38,4 prosent ECDSA, med RSA-2048 alene som 60,2 prosent av alle sertifikater og ECDSA P-256 på 37,8 prosent. Forskjellen mellom de to undersøkelsene skyldes trolig ulik metodikk, ulikt utvalg av nettsteder og forskjellige måletidspunkt, og bør leses som et tegn på metodisk usikkerhet snarere enn en endelig fasit på markedsandeler. Det som er tydelig uansett kilde: RSA er ikke på vei ut, men ECDSA har tatt igjen mye av forspranget de siste årene, særlig hos de største CDN-ene og skytjenestene.

Chrome, Firefox, Safari og Edge støtter i dag begge familiene uten videre konfigurasjon, og de vanligste kurvene, P-256 og P-384, er standard i alle moderne TLS-biblioteker. Det praktiske hinderet for full overgang til ECDSA er ikke lenger nettleserstøtte, men eldre servere, interne systemer og IoT-enheter som fortsatt kjører programvare bygget før elliptisk kurve-kryptografi ble utbredt.

For norske og nordiske virksomheter som følger nasjonale grunnprinsipper for IKT-sikkerhet, er det ingen motsetning mellom disse anbefalingene og valget mellom RSA og ECDSA. Begge algoritmer regnes som godkjente når nøkkelstørrelsen er tilstrekkelig, og myndighetenes fokus ligger på at algoritmen faktisk følger oppdaterte standarder og at nøklene roteres og beskyttes riktig, ikke på hvilken av de to familiene som velges. Det gir norske organisasjoner frihet til å velge algoritme basert på ytelse og kompatibilitet fremfor regulatoriske krav.

Bransjeforskjellene er også verdt å nevne. Finanssektoren og deler av offentlig forvaltning har tradisjonelt vært konservative i valg av kryptografi, ofte fordi eldre kjernesystemer er bygget rundt RSA og en fullstendig migrering krever omfattende regresjonstesting. Teknologiselskaper, spillutviklere og nyere skyfødte tjenester har i motsetning til dette adoptert ECDSA raskere, siden de sjeldnere har tunge avhengigheter til eldre PKI-infrastruktur. Denne todelingen forklarer trolig hvorfor de to undersøkelsene nevnt over kommer frem til så ulike tall, avhengig av hvilke typer nettsteder som er inkludert i utvalget.

Slik sjekker du hvilken algoritme et sertifikat bruker

Før du planlegger en migrering er det nyttig å vite nøyaktig hvilken algoritme en gitt tjeneste bruker i dag. Det enkleste er å bruke OpenSSL til å koble til tjenesten direkte og lese ut sertifikatinformasjonen, uten å måtte stole på hva nettleseren viser i adressefeltet.

# Koble til en tjeneste og hent ut sertifikatet
openssl s_client -connect eksempel.no:443 -servername eksempel.no < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Public Key Algorithm"

# Sjekk nøkkelstørrelse og kurve for et lokalt sertifikat
openssl x509 -in sertifikat.pem -noout -text | grep -E "Public-Key|ASN1 OID"

Kommandoen over viser om sertifikatet bruker rsaEncryption eller id-ecPublicKey, samt hvilken kurve som er i bruk hvis det er ECDSA. Mange overvåkingsverktøy for sertifikater, inkludert kommersielle tjenester og gratisverktøy basert på Certificate Transparency-logger, gir samme informasjon i et grensesnitt som er enklere å lese for et helt sertifikatlager på tvers av mange domener samtidig, noe som er nyttig når man skal kartlegge status før en organisasjonsomfattende migrering.

Pris og kostnad: koster ECDSA-sertifikater mer?

Et vanlig spørsmål er om ECDSA-sertifikater er dyrere enn RSA-sertifikater siden de er nyere teknologi. Svaret, basert på offisielle prislister fra flere store sertifikatutstedere, er nei. Ingen av de undersøkte utstederne skiller prisen etter hvilken nøkkelalgoritme kunden velger, prisen bestemmes av valideringsnivå (DV, OV eller EV), antall domener og abonnementslengde, ikke av RSA versus ECDSA.

Utsteder / sertifikattypeOffisiell pris per årPrisforskjell RSA vs ECDSA
Let’s Encrypt, DVGratisIngen, begge algoritmer støttes likt
Sectigo, DV enkeltdomeneFra $110Ingen prisforskjell oppgitt
DigiCert, DV standard$372Ingen prisforskjell oppgitt
DigiCert, OV standard$624Ingen prisforskjell oppgitt
DigiCert, virksomhetsnivå$1.548Ingen prisforskjell oppgitt

Den reelle kostnadsforskjellen ligger ikke i sertifikatprisen, men i driftskostnaden. Fordi ECDSA signerer raskere og krever mindre CPU per håndhilsen, kan en server håndtere flere samtidige TLS-tilkoblinger på samme maskinvare. For en tjeneste med svært høyt volum av nye tilkoblinger, som en CDN eller en offentlig API, kan denne CPU-besparelsen bety færre servere eller lavere skyregning over tid, selv om selve sertifikatet koster akkurat det samme uansett algoritme. Motsatt kan RSA sin billige verifisering være relevant for systemer som verifiserer enorme mengder signaturer, men sjelden signerer selv, som klienter i et betalingssystem eller en logg-verifiseringstjeneste.

Det er verdt å nevne at kostnadsbildet også omfatter driftsressurser utover selve CPU-tiden. Overgang til et nytt sertifikat, uansett algoritme, krever tid fra driftsteamet til å konfigurere, teste og overvåke utrullingen. Denne engangskostnaden i arbeidstid er ofte større enn den løpende forskjellen i sertifikatpris eller CPU-bruk, og er en av grunnene til at mange organisasjoner venter til neste planlagte sertifikatfornyelse før de bytter algoritme, fremfor å gjøre et hastverksbytte utelukkende for ytelsesgevinsten.

Fem virkelige eksempler på RSA og ECDSA i produksjon

Teori blir mer konkret når man ser hvordan store aktører faktisk har valgt mellom de to algoritmene. Felles for eksemplene under er at valget sjelden er absolutt, de fleste tjenester i stor skala tilbyr begge algoritmene samtidig og lar klienten forhandle frem det beste alternativet, fremfor å tvinge frem ett eneste valg for alle brukere.

  • Let’s Encrypt utsteder sertifikater med begge algoritmene gjennom separate sertifikatkjeder, én for RSA-nøkler (2048, 3072 eller 4096 bit) og én for ECDSA-nøkler (P-256 eller P-384), slik at klienten kan velge algoritme uten å endre utsteder. Se gjennomgangen av ECDHE mot RSA i TLS 1.2 for hvordan valget påvirker selve nøkkelutvekslingen.
  • Cloudflare tilbyr begge algoritmene til alle kunder gjennom sertifikatutstedere som Let’s Encrypt, Google Trust Services og SSL.com, men fremhever internt at ECDSA gir bedre ytelse på grunn av mindre nøkler og signaturer.
  • Bitcoin og en rekke andre kryptovalutaer bruker ECDSA over kurven secp256k1 til å signere hver eneste transaksjon på kjeden, et av de mest brukte enkeltstående ECDSA-systemene i verden målt i antall daglige signeringer.
  • Skytjenester som AWS Certificate Manager lar kunder velge mellom RSA- og ECDSA-sertifikater ved utstedelse, og anbefaler ECDSA for tjenester med høyt tilkoblingsvolum der signeringskostnad på serversiden er en flaskehals.
  • SSH-infrastruktur i mange virksomheter har gradvis gått bort fra RSA-verthetnøkler til fordel for ECDSA eller Ed25519, delvis fordi nøkkelgenerering og signering er raskere. Se sammenligningen mellom ECDSA og Ed25519 for hvordan de to elliptisk kurve-algoritmene skiller seg fra hverandre.
  • Kubernetes-klynger bruker ofte ECDSA til intern mTLS mellom noder og kontrollplan, fordi et stort antall interne tilkoblinger gjør signeringskostnaden til en reell flaskehals når klyngen skaleres til hundrevis eller tusenvis av noder.

Bruksområder: når bør du velge ECDSA, og når bør du velge RSA?

Valget avhenger mer av hvem som skal bruke sertifikatet enn av abstrakt sikkerhet. Under følger konkrete anbefalinger basert på trafikkmønster og kompatibilitetsbehov.

Velg ECDSA når:

  • Du drifter en tjeneste med høyt volum av nye TLS-tilkoblinger, som en CDN, API-gateway eller lastbalanserer.
  • Du vil redusere størrelsen på sertifikatkjeden for mobile klienter eller nett med høy latens.
  • Du bygger nye systemer uten avhengighet til eldre programvare fra før 2013.
  • Du trenger raske signeringsoperasjoner i stort volum, for eksempel i en mikrotjenestearkitektur med mange interne mTLS-tilkoblinger.
  • Du signerer blokkjede-transaksjoner eller andre systemer der secp256k1 eller lignende kurver allerede er bransjestandard.

Velg RSA når:

  • Systemet må kommunisere med eldre klienter, industriutstyr eller innebygde enheter som mangler ECDSA-støtte.
  • Du signerer sjelden, men verifiserer ofte, for eksempel i et system som validerer tusenvis av signerte dokumenter mot noen få signeringsnøkler. Se sammenligningen av RSA-2048 mot RSA-4096 for hvilken nøkkelstørrelse som passer best.
  • Compliance-krav eller bransjestandarder (enkelte finans- og myndighetssystemer) fortsatt eksplisitt krever RSA.
  • Du trenger maksimal kompatibilitet med eldre PKI-infrastruktur som ikke enkelt lar seg oppgradere.

I praksis lander de fleste organisasjoner på en hybrid tilnærming: ECDSA som standard for nye tjenester og eksternvendte nettsider, RSA beholdt for et avgrenset sett med eldre integrasjoner der man vet at klienten ikke støtter elliptisk kurve-kryptografi. Denne kombinasjonen krever litt mer administrasjon enn å velge én algoritme for alt, men gir det beste av begge verdener uten å ofre kompatibilitet.

Migreringsguide: fra RSA til ECDSA-sertifikater

En overgang fra RSA til ECDSA gjøres tryggest gradvis, med begge algoritmene i drift samtidig i en overgangsperiode. Slik gjør du det i praksis.

  1. Kartlegg hvilke klienter som kobler til tjenesten din i dag, og sjekk om noen fortsatt mangler støtte for elliptisk kurve-kryptografi (sjelden i 2026, men fortsatt mulig med eldre IoT-utstyr).
  2. Generer en ECDSA-nøkkel med kurven P-256 som standardvalg for de fleste bruksområder.
  3. Opprett en CSR (Certificate Signing Request) basert på den nye nøkkelen og send den til samme sertifikatutsteder du allerede bruker.
  4. Installer det nye ECDSA-sertifikatet ved siden av det eksisterende RSA-sertifikatet, ikke i stedet for det, slik at webserveren kan velge algoritme basert på hva klienten støtter.
  5. Konfigurer webserveren (nginx, Apache eller lignende) til å prioritere ECDSA-cipherpakker først, med RSA som fallback.
  6. Overvåk tilkoblingslogger i minst to til fire uker for å bekrefte at ingen klienter feiler mot det nye sertifikatet.
  7. Fjern RSA-sertifikatet først når overvåkingen bekrefter at ingen aktive klienter lenger krever det.

Under følger kommandoene for å generere begge nøkkeltypene med OpenSSL, slik at du kan sette opp dobbel sertifisering i praksis:

# Generer ECDSA-nøkkel med kurven P-256
openssl ecparam -genkey -name prime256v1 -noout -out ecdsa_key.pem

# Opprett CSR for ECDSA-nøkkelen
openssl req -new -key ecdsa_key.pem -out ecdsa.csr -subj "/CN=eksempel.no"

# Generer RSA-nøkkel på 3072 bit (fallback for eldre klienter)
openssl genrsa -out rsa_key.pem 3072

# Opprett CSR for RSA-nøkkelen
openssl req -new -key rsa_key.pem -out rsa.csr -subj "/CN=eksempel.no"

Etter at begge CSR-ene er signert av utstederen, kan nginx eller en tilsvarende webserver settes opp til å tilby begge sertifikatene samtidig og la TLS-forhandlingen velge riktig par basert på klientens støtte, uten at det krever noen endring i applikasjonskoden.

Et vanlig feilsteg under migreringen er å fjerne RSA-sertifikatet for tidlig, før overvåkingsvinduet har fanget opp trafikk fra sjeldne klienter som bare kobler til én gang i måneden eller sjeldnere, som enkelte batch-jobber eller integrasjoner mot tredjepartssystemer. Et overvåkingsvindu på to til fire uker fanger opp de fleste vanlige mønstre, men systemer med kjent sjelden trafikk bør vurdere en lengre overgangsperiode før RSA-sertifikatet fjernes helt.

Fordeler og ulemper

Etter å ha gått gjennom nøkkelstørrelse, ytelse, sikkerhet, pris og reell bruk, kan styrkene og svakhetene til hver algoritme oppsummeres kort. Bruk denne listen som en rask sjekk før du tar den endelige beslutningen for ditt eget system.

  • RSA, fordeler: enorm kompatibilitet, lang driftshistorikk, svært rask verifisering, godt forstått av nesten alle sikkerhetsteam.
  • RSA, ulemper: store nøkler og signaturer, treg signering og nøkkelgenerering ved høye sikkerhetsnivåer, høyere båndbreddekostnad per håndhilsen.
  • ECDSA, fordeler: små nøkler og signaturer, rask signering, lavere CPU-bruk på serversiden, godt egnet for høyvolum-tjenester.
  • ECDSA, ulemper: treg verifisering sammenlignet med RSA, historisk sårbar for dårlig nonce-generering i feilkonfigurerte implementasjoner, marginalt dårligere støtte i svært gammelt utstyr.

Post-kvante trusselen mot begge algoritmene

Verken RSA eller ECDSA er motstandsdyktige mot en tilstrekkelig kraftig kvantedatamaskin. Shors algoritme kan i teorien knekke både faktoriseringsproblemet bak RSA og det diskrete logaritme-problemet bak ECDSA, forskjellen er i praksis kun hvor mange qubits som trengs, ikke om angrepet er mulig. Det er grunnen til at NIST har standardisert egne post-kvante-algoritmer til å etter hvert erstatte begge de klassiske algoritmene i sensitive systemer. Se sammenligningen av ML-DSA mot ECDSA for hvor mye større de nye post-kvante-signaturene er.

NIST ferdigstilte de første post-kvante-standardene, ML-KEM for nøkkelutveksling og ML-DSA og SLH-DSA for digitale signaturer, i august 2024. Disse algoritmene bruker helt andre matematiske problemer enn både RSA og ECDSA, basert på strukturerte gitter og hash-funksjoner, som i dag anses som motstandsdyktige mot kjente kvantealgoritmer. Signaturene fra disse nye algoritmene er derimot betydelig større enn både RSA- og ECDSA-signaturer, noe som skaper nye utfordringer for båndbredde og lagring selv om sikkerhetsproblemet løses.

Ingen dagens kvantedatamaskiner er i nærheten av å true RSA-2048 eller ECDSA P-256 i praksis, men migrasjonen til post-kvante-algoritmer tar tid, og mange organisasjoner har startet planleggingen allerede nå. For systemer med lang levetid, som infrastruktur som skal driftes i 15-20 år fremover, er dette en reell vurdering å ta med i valget mellom RSA og ECDSA i dag, siden ingen av dem er et endestasjon-svar på lang sikt. For hybridløsninger som kombinerer klassisk og post-kvante kryptografi i samme sertifikat, se også gjennomgangen av AES-256 mot RSA-4096 i symmetrisk og asymmetrisk sammenheng.

Konklusjon: hva sier tallene?

Tallene peker i en klar retning for de fleste nye systemer: ECDSA P-256 gir om lag 25 ganger flere signeringer per sekund enn RSA-2048 i referansetester, krever mindre enn en femtedel av nøkkelstørrelsen for samme sikkerhetsnivå, og koster ingenting ekstra hos noen av de store sertifikatutstederne. RSA holder fortsatt stand der kompatibilitet med eldre systemer er avgjørende, eller der verifiseringshastighet betyr mer enn signeringshastighet.

Adopsjonstallene fra 2026 viser et marked i nesten dødt løp, med ECDSA i ferd med å ta igjen RSA på antall utstedte sertifikater, mens RSA fortsatt dominerer i eldre installasjoner og bransjer med strenge compliance-krav. For et nytt prosjekt uten spesielle kompatibilitetsbehov er ECDSA P-256 det naturlige standardvalget i dag. For eksisterende infrastruktur anbefales en gradvis migrering med begge algoritmene i drift samtidig, slik migreringsguiden over beskriver, fremfor en brå full overgang. Les mer om cluster-oversikten vår i kryptografi-arkivet.

Uansett hvilken algoritme du lander på i dag, er det verdt å huske at valget ikke er permanent. Sertifikater fornyes typisk hvert 90. til 398. dag avhengig av utsteder og policy, noe som gir hyppige naturlige punkter for å bytte algoritme uten en stor separat migreringsjobb. Bruk derfor gjerne neste planlagte fornyelse som anledning til å teste ECDSA parallelt med eksisterende RSA-sertifikater, fremfor å vente på et prosjekt dedikert utelukkende til algoritmebytte.

Ofte stilte spørsmål

Er ECDSA tryggere enn RSA?

Ikke iboende. Når nøklene er riktig dimensjonert, gir begge algoritmene tilsvarende sikkerhetsnivå. Forskjellen ligger i ytelse, nøkkelstørrelse og hvilke implementasjonsfeil hver algoritme historisk har vært utsatt for, ikke i matematisk styrke ved korrekt bruk.

Kan jeg bruke både RSA og ECDSA på samme server?

Ja. De fleste moderne webservere, inkludert nginx og Apache, støtter å installere begge sertifikattypene samtidig, slik at TLS-forhandlingen automatisk velger riktig algoritme basert på hva klienten støtter.

Koster et ECDSA-sertifikat mer enn et RSA-sertifikat?

Nei. Offisielle prislister fra Let’s Encrypt, Sectigo og DigiCert viser ingen prisforskjell mellom algoritmene. Prisen bestemmes av valideringsnivå og abonnementstype, ikke av hvilken nøkkelalgoritme du velger.

Hvilken ECDSA-kurve bør jeg velge, P-256 eller P-384?

P-256 dekker de fleste behov og tilsvarer om lag 128-bit sikkerhet, samme nivå som RSA-3072. P-384 gir høyere sikkerhet (rundt 192-bit) på bekostning av noe lavere ytelse, og passer best til systemer med spesielt strenge sikkerhetskrav.

Er RSA på vei ut helt?

Nei. Certificate Transparency-data fra 2026 viser at RSA fortsatt utgjør mellom 49 og 62 prosent av aktive sertifikater avhengig av målemetode. RSA forblir relevant der eldre klienter, strenge compliance-krav eller verifiseringstung bruk dominerer.

Påvirker valget mellom RSA og ECDSA sidehastighet?

Indirekte, ja. Et mindre ECDSA-sertifikat gir en marginalt raskere TLS-håndhilsen, spesielt på mobilnett med høy latens, noe som kan bidra positivt til mål som tid til første byte og dermed til sidehastighetsrelaterte rangeringssignaler.

Er secp256k1, kurven Bitcoin bruker, det samme som P-256?

Nei, det er to forskjellige kurver med ulike matematiske parametere. Secp256k1 er valgt for spesifikke egenskaper som er nyttige i blokkjeder, mens P-256 er NIST-standardkurven som brukes i de aller fleste TLS-sertifikater.

Hva er forskjellen mellom ECDSA og Ed25519?

Begge er elliptisk kurve-algoritmer, men Ed25519 bruker en annen kurve (Curve25519) og en annen signaturkonstruksjon (EdDSA) som fjerner behovet for en tilfeldig nonce ved hver signering. Det gjør Ed25519 mindre sårbar for nettopp den typen implementasjonsfeil som historisk har rammet ECDSA. Ed25519 har derimot noe smalere støtte i eldre TLS-stabler og enkelte sertifikatutstedere sammenlignet med ECDSA P-256.

Trenger jeg to separate sertifikater permanent, eller bare under overgangen?

Det avhenger av hvor mye du vet om klientene dine. Har du full kontroll over alle klienter som kobler til, kan du gå fullt over til ett sertifikat. Betjener du en åpen tjeneste med ukjente klienter, som en offentlig nettside, er det tryggere å beholde begge sertifikattypene permanent og la TLS-forhandlingen velge, siden kostnaden ved å drifte to sertifikater er lav sammenlignet med risikoen for at enkelte besøkende ikke får koblet til.

Hva skjer med RSA- og ECDSA-sertifikater når kvantedatamaskiner blir kraftige nok?

Begge algoritmene vil i teorien kunne knekkes av en tilstrekkelig kraftig kvantedatamaskin ved hjelp av Shors algoritme. NIST har derfor standardisert post-kvante-alternativer til å etter hvert erstatte både RSA og ECDSA i sensitive systemer, men overgangen forventes å ta flere år.