ECDSA vs Ed25519: 1,7x Raskere Signering [2026]

Skal en ny server bruke ECDSA eller Ed25519? Spørsmålet dukker opp hver gang et team setter opp SSH-tilgang, bygger et sertifikat for TLS 1.3, eller velger signeringsalgoritme for en intern PKI. Begge er elliptisk kurve-algoritmer med omtrent samme sikkerhetsnivå (128 bit), men de er bygget på ulike matematiske kurver, har ulik motstand mot implementasjonsfeil, og støttes ulikt på tvers av skytjenester og maskinvare. I 2026 er svaret sjelden «alltid det ene» — det avhenger av om du signerer et TLS-sertifikat for offentlig web, en SSH-nøkkel for en utviklermaskin, eller en commit i Git.

For norske og nordiske IT-team er valget sjelden akademisk. Offentlig sektor og finans må ofte forholde seg til FIPS-krav og NIS2-relaterte sikkerhetsprofiler, samtidig som utviklerteamene ønsker enklere og raskere verktøy i det daglige. Den spenningen — mellom regulatorisk kompatibilitet og moderne, feilsikker kryptografi — er kjernen i denne sammenligningen. Denne artikkelen går gjennom spesifikasjonene, ytelsestall fra tre uavhengige benchmarker, prising hos AWS, Google Cloud og Azure, maskinvarestøtte i sikkerhetsnøkler og HSM-er, samt konkrete migreringssteg for team som vurderer å bytte fra ECDSA til Ed25519.

Hva er ECDSA og Ed25519?

Begge algoritmene løser samme problem: å bevise at en melding er signert av eieren av en privat nøkkel, uten å avsløre nøkkelen selv. Begge bygger på elliptisk kurve-kryptografi, men konstruksjonen under panseret er forskjellig nok til at det påvirker både ytelse og feilmarginer i praksis.

ECDSA forklart

ECDSA (Elliptic Curve Digital Signature Algorithm) er den elliptiske kurve-varianten av DSA-standarden, og den mest brukte kurven er NIST P-256 (også kalt secp256r1). Den er standardisert av NIST i FIPS 186-5 og er godkjent for bruk i amerikanske og europeiske myndighetsprofiler. Svakheten ligger ikke i selve matematikken, men i signeringsprosessen: hver signatur krever et engangstall, kalt en nonce, som må være unikt og hemmelig for hver operasjon. Blir samme nonce brukt to ganger, eller er tilfeldighetsgeneratoren svak, kan den private nøkkelen regnes ut algebraisk fra to signaturer. Dette er ikke et teoretisk problem — svak nonce-håndtering har ligget bak flere kjente nøkkellekkasjer i Bitcoin-økosystemet opp gjennom årene, og er fortsatt et aktivt risikoområde for implementasjoner som ikke følger RFC 6979 om deterministiske ECDSA-nonces.

P-256 er også kurven som brukes i det store flertallet av dagens TLS-sertifikater, FIDO2-nøkler og eldre PKI-installasjoner, blant annet fordi den ble standardisert av NIST allerede på 1990-tallet og har fått enorm utbredelse siden. Den lange historien er både en styrke og en svakhet: den gir bred kompatibilitet, men konstruksjonen (en Weierstrass-kurve med spesifikke, ikke offentlig utledbare parametere) har også vært gjenstand for tillitsdiskusjon i kryptografimiljøet siden Snowden-lekkasjene i 2013, uten at det er funnet konkrete bevis på bakdører i P-256 spesifikt.

Ed25519 forklart

Ed25519 er en implementasjon av EdDSA (Edwards-curve Digital Signature Algorithm) på Curve25519, opprinnelig designet av Daniel J. Bernstein og medforfattere og formalisert i RFC 8032. Den store forskjellen fra ECDSA er at nonce-en er deterministisk: den beregnes matematisk fra meldingen og den private nøkkelen, i stedet for å hentes fra en tilfeldighetsgenerator. Det fjerner en hel klasse med feil som har rammet ECDSA i praksis. Ed25519 er også designet for å være enklere å implementere i konstant tid, noe som gjør sidekanalangrep vanskeligere å utføre riktig mot en korrekt skrevet implementasjon.

Curve25519, som Ed25519 bygger på, ble publisert av Bernstein i 2005 og er senere blitt en av de mest analyserte og tillitsvekkende kurvene i moderne kryptografi, nettopp fordi parametervalgene er fullt gjennomsiktige og etterprøvbare — i motsetning til NIST-kurvenes historiske tillitsdebatt. Det er en av grunnene til at kryptografimiljøet, inkludert forfatterne bak Signal og WireGuard, har valgt Curve25519-familien når de har fått bygge fra bunnen av uten krav om bakoverkompatibilitet med eldre systemer.

Spesifikasjoner: ECDSA P-256 mot Ed25519

Tabellen under samler de tekniske spesifikasjonene som avgjør hvor godt hver algoritme passer inn i et gitt system. Legg merke til at begge lander på samme sikkerhetsnivå — forskjellen ligger i detaljene rundt implementasjon, standardisering og økosystemstøtte. Vi har inkludert både de rene tekniske egenskapene og de praktiske faktorene, som FIPS-status og protokollstøtte, fordi det ofte er de sistnevnte som i praksis avgjør valget for et team, snarere enn nøkkel- eller signaturstørrelse.

Egenskap	ECDSA (P-256 / secp256r1)	Ed25519 (EdDSA / Curve25519)
Kurvetype	Weierstrass-kurve	Twisted Edwards-kurve
Nøkkelstørrelse (offentlig)	32–33 byte	32 byte
Signaturstørrelse	64–72 byte (DER-kodet, variabel)	64 byte (fast)
Sikkerhetsnivå	~128 bit	~128 bit
Nonce-type	Tilfeldig (krever sikker RNG)	Deterministisk (fra melding + nøkkel)
Standardiseringsorgan	NIST, FIPS 186-5	IETF (RFC 8032), CFRG
FIPS-godkjent (2026)	Ja	Nei, fortsatt utenfor FIPS-validerte algoritmer
Batch-verifisering	Ikke naturlig støttet	Støttet, ifølge CRYPTREC raskere for store volum
Konstant-tid-implementasjon	Krever nøye implementasjon	Designet inn fra start
Bruk i TLS 1.3-sertifikater	Dominerende i dag	Sjelden utstedt av offentlige CA-er
Bruk i SSH	Støttet, mindre anbefalt	Standard anbefaling siden OpenSSH 6.5
Kjent svakhet	Nonce-gjenbruk gir nøkkellekkasje	Implementasjonsspesifikke feil, ikke designsvakhet

Det som skiller de to i praksis, er ikke sikkerhetsnivået — begge gir omtrent 128-bits sikkerhet, tilsvarende AES-128. Forskjellen ligger i hvor mye som kan gå galt i implementasjonen. ECDSA er avhengig av en kvalitetssikret tilfeldighetskilde for hver signatur. Ed25519 fjerner den avhengigheten ved design.

Ytelse: hvor mye raskere er Ed25519 i praksis?

Her spriker tallene mer enn markedsføringen ofte antyder, fordi resultatet avhenger sterkt av hvor optimalisert P-256-implementasjonen er. Vi har samlet tall fra tre uavhengige kilder for å gi et realistisk bilde i stedet for ett enkelt tall.

Kilde	ECDSA P-256 signering	Ed25519 signering	ECDSA P-256 verifisering	Ed25519 verifisering
Praktisk PKI-benchmark, moderne x86-kjerne	~30 000 op/sek	~50 000 op/sek	Ikke oppgitt separat	Ikke oppgitt separat
OpenSSL NISTZ256-forskningsstudie	29 938 op/sek	Opptil 6–7x raskere enn uoptimalisert P-256-baseline	Høyere enn signering	Høyere enn signering
Uavhengig 2023/2025-benchmark på moderne Intel-CPU	32 866 op/sek	30 775 op/sek	10 499 op/sek	11 870 op/sek

Konklusjonen fra disse tre kildene er ikke at Ed25519 alltid vinner med stor margin. På sterkt optimalisert P-256-kode (som Intels egen NISTZ256-implementasjon i OpenSSL) er forskjellen liten, og i noen tester signerer ECDSA faktisk marginalt raskere enn Ed25519. Men på verifisering, og i implementasjoner som ikke er like håndoptimalisert, drar Ed25519 fra med 1,5 til over 6 ganger høyere gjennomstrømning. Poenget er at Ed25519 leverer solid ytelse uten at noen trenger å skrive prosessorspesifikk assembly-kode for å oppnå det — mens ECDSA sin beste ytelse forutsetter nettopp det.

Nonce-gjenbruk: ECDSAs akilleshæl

Den mest praktiske forskjellen mellom de to algoritmene handler ikke om hastighet, men om hvor mye som kan gå galt uten at noen merker det før nøkkelen allerede er kompromittert. I ECDSA beregnes hver signatur med et hemmelig, tilfeldig tall k. Hvis k gjenbrukes på tvers av to signaturer — eller hvis k er forutsigbar fordi tilfeldighetsgeneratoren er svak — kan en angriper løse et enkelt lineært likningssystem og hente ut den private nøkkelen direkte. Dette krever ikke avanserte ressurser, bare to signaturer og litt algebra.

Denne feilklassen har rammet virkelige systemer flere ganger, mest kjent i tidlige Bitcoin-lommebøker med svak tilfeldighetsgenerering på Android, men mønsteret dukker jevnlig opp igjen i nye biblioteker og innebygde enheter der utviklere implementerer ECDSA fra bunnen av. Løsningen industrien har landet på er RFC 6979, som gjør nonce-en deterministisk også for ECDSA — men det er et tillegg utviklere må velge aktivt, ikke noe som følger med algoritmen som standard.

Ed25519 unngår hele problemklassen fordi determinismen er innebygd i spesifikasjonen fra dag én, ikke et tillegg. Det betyr ikke at Ed25519-implementasjoner er immune mot feil — det finnes eksempler på biblioteker som har hatt feil i punktvalidering eller signaturverifisering — men disse er isolerte kodefeil, ikke en strukturell svakhet i selve algoritmen slik nonce-avhengigheten er for ECDSA.

Hvor brukes ECDSA og Ed25519 i praksis?

Adopsjonsmønsteret i 2026 følger et tydelig skille: eldre, bredt distribuert infrastruktur som krever maksimal kompatibilitet holder seg til ECDSA, mens nyere verktøy bygget av kryptografer fra bunnen av velger Ed25519.

TLS 1.3 og offentlige nettsertifikater: RFC 8446 prioriterer ECDSA P-256 som primær kurve-signatur, og det er fortsatt det du ser i sertifikatene til de fleste nettsteder og CDN-er. Offentlige CA-er utsteder i praksis ikke Ed25519-sertifikater i stor skala.
SSH: OpenSSH har støttet Ed25519 siden versjon 6.5, og det regnes som standardanbefalingen for nye SSH-nøkler i 2026 på grunn av kompakte nøkler og enkel, sikker generering.
FIDO2/WebAuthn og passkeys: ECDSA P-256 er den mest universelt kompatible signaturmekanismen for autentikatorer, selv om nyere maskinvare også støtter EdDSA.
Bitcoin: bruker ECDSA over secp256k1 (en annen kurve enn P-256), og nonce-sårbarheten har vært en direkte årsak til flere historiske lommeboklekkasjer.
Signal-protokollen: bruker Curve25519 til nøkkelutveksling og Ed25519 til identitetssignaturer, dokumentert i X3DH-spesifikasjonen.
WireGuard: bygger på Curve25519-familien for nøkkelutveksling, i tråd med den samme «moderne og slanke» designfilosofien som Ed25519.
Git commit-signering: støtte for SSH-nøkkelbasert signering, inkludert Ed25519, har blitt mainstream i utviklerverktøy de siste årene, og mange team signerer nå commits med Ed25519 SSH-nøkler i stedet for GPG/RSA.

Skytjenester og prising: hva koster ECDSA og Ed25519 i praksis?

Begge algoritmene er gratis i seg selv — det koster ingenting å bruke matematikken. Det som koster penger er nøkkelhåndtering i skyen, og her er det fortsatt reelle forskjeller i hvilke tjenester som støtter Ed25519 i det hele tatt.

Tjeneste	Ed25519-støtte	ECDSA P-256-støtte	Prisnivå
AWS KMS	Ja, lagt til i november 2025 (ECC_NIST_EDWARDS25519)	Ja	$1/måned per nøkkel, $0,15 per 10 000 asymmetriske forespørsler
Google Cloud KMS	Ja	Ja	Fra $0,06 per aktiv nøkkelversjon/måned, $0,03 per 10 000 operasjoner
Azure Key Vault	Ikke oppført som standard nøkkeltype	Ja	Rundt $0,03 per 10 000 operasjoner, ekstra for HSM-beskyttede nøkler
HashiCorp Vault (Transit)	Ja	Ja	Avhenger av egen Vault-drift, ingen fast API-pris

Det praktiske funnet her er at AWS og Google Cloud har tatt igjen forspranget: begge støtter nå Ed25519 fullt ut i sine administrerte nøkkeltjenester. Azure henger etter — Key Vault sin standarddokumentasjon for nøkkelalgoritmer fremhever fortsatt RSA og NIST-kurver, uten Ed25519 som offisiell nøkkeltype. Skal du bygge på Azure og trenger Ed25519, må du se på tredjeparts nøkkelhåndtering eller HashiCorp Vault i stedet for tjenesten selv.

For team som drifter multi-sky, betyr dette at en enkelt, sky-agnostisk nøkkeltype ikke alltid finnes ennå. Et vanlig mønster i 2026 er å bruke ECDSA P-256 som fellesnevner der arbeidsbelastningen kan flytte mellom AWS, Google Cloud og Azure, og reservere Ed25519 for arbeidsbelastninger som er forpliktet til én enkelt skyleverandør eller kjører i egen infrastruktur der algoritmevalget ikke er begrenset av en tredjepartstjeneste.

NIST, FIPS og standardiseringsstatus i 2026

For organisasjoner som må følge amerikanske eller europeiske sikkerhetsprofiler, er standardiseringsstatus ofte viktigere enn ytelsestall. ECDSA P-256 er fullt godkjent under NIST FIPS 186-5 og inngår i kjernen av amerikanske og europeiske kryptografiprofiler for offentlig sektor. Ed25519 er standardisert av IETF gjennom RFC 8032 og anses som moden og gjennomanalysert, men er fortsatt ikke en del av NIST sine FIPS-validerte signaturalgoritmer per midten av 2026. Det betyr at strengt FIPS-kontrollerte miljøer — typisk offentlig sektor, forsvar og enkelte finansinstitusjoner — i praksis er låst til ECDSA (eller de nyere post-kvante-algoritmene som ML-DSA) selv om Ed25519 er teknisk overlegen på flere punkter.

Den japanske kryptografivurderingen CRYPTREC har vurdert begge algoritmene og konkluderer med at EdDSA er minst like sikker som ECDSA på samme parameterstørrelse, og bedre egnet for batch-verifisering av store mengder signaturer. Det er en nyttig linje å ta med seg: forskjellen mellom de to handler sjelden om grunnleggende sikkerhet, og nesten alltid om hvor algoritmen passer inn i et regelverk eller en eksisterende infrastruktur.

NIS2 og norske sikkerhetskrav: betyr regelverket noe for valget?

NIS2-direktivet, som er implementert i Norge gjennom digitalsikkerhetsloven, stiller krav om risikobaserte tekniske og organisatoriske tiltak, inkludert kryptografi og nøkkelhåndtering, men spesifiserer ikke bestemte signaturalgoritmer. Det betyr at norske virksomheter som omfattes av loven ikke er tvunget til ECDSA fremfor Ed25519 eller omvendt — kravet er at valget er dokumentert, risikovurdert og i tråd med anerkjent praksis. I praksis vil de fleste revisorer og tilsynsmyndigheter akseptere begge algoritmene, forutsatt at implementasjonen følger etablerte standarder som RFC 8032 for Ed25519 eller RFC 6979 for ECDSA.

Der regelverket derimot legger reelle føringer, er for offentlige virksomheter og leverandører som må følge spesifikke sikkerhetsprofiler fra Nasjonal sikkerhetsmyndighet (NSM) eller tilsvarende krav i finanssektoren, som ofte refererer til FIPS-godkjente algoritmer eller Common Criteria-sertifisert maskinvare. I disse tilfellene er ECDSA P-256 fortsatt det trygge, dokumenterbare valget, ganske enkelt fordi det er formelt godkjent i flere regelverk enn Ed25519 er per i dag. For interne systemer uten slike bindinger — som er det store flertallet av SSH-tilgang, interne API-er og utviklerverktøy i en typisk norsk virksomhet — er det ingen regulatorisk hindring for å velge Ed25519.

Maskinvarestøtte: YubiKey, HSM og smartkort

På maskinvaresiden er bildet delt etter grensesnitt, ikke bare etter produsent. Moderne YubiKey-modeller (5-serien og nyere FIDO2-kapable enheter) støtter EdDSA/Ed25519 gjennom FIDO2/WebAuthn-grensesnittet, men PIV-grensesnittet, som brukes til smartkort-autentisering og S/MIME, er i praksis bygget rundt RSA og ECDSA P-256/P-384 — ikke Ed25519. Skal du bruke Ed25519 på maskinvarenivå, må du altså se på FIDO2/WebAuthn-flyten eller SSH-nøkler generert direkte på sikkerhetsnøkkelen (resident/FIDO2 SSH-nøkler), ikke den klassiske PIV-smartkortmodellen.

For dedikerte HSM-er (Hardware Security Modules) er situasjonen lik skysituasjonen: nyere HSM-plattformer legger til Ed25519 gradvis, mens ECDSA og RSA har vært fullt støttet i over et tiår. Hvis compliance-kravet er en spesifikk, sertifisert HSM-modell, er det verdt å sjekke leverandørens algoritme-liste før man planlegger en Ed25519-migrering — ikke alle FIPS 140-validerte moduler har Ed25519 i sitt godkjente sett ennå.

Dette skaper et praktisk dilemma for organisasjoner som allerede har investert i eldre smartkort- eller HSM-infrastruktur: en full overgang til Ed25519 kan bety at eksisterende maskinvare må byttes ut, ikke bare omkonfigureres. For nye anskaffelser i 2026 er rådet enkelt — sjekk Ed25519-støtte eksplisitt før innkjøp, selv om ECDSA fortsatt er det som brukes i dag, slik at maskinvaren er klar for en eventuell migrering senere uten en ny investeringsrunde.

Bibliotekstøtte for utviklere: OpenSSL, libsodium og native crypto-moduler

Valget mellom ECDSA og Ed25519 påvirkes også av hvor moden bibliotekstøtten er i språket og rammeverket du faktisk bygger med. Begge algoritmene er godt støttet i de store kryptografibibliotekene i 2026, men brukervennligheten er ikke identisk.

OpenSSL støtter begge algoritmene, men API-et for ECDSA er eldre og mer generisk (delt med RSA og DSA), noe som gjør det lettere å konfigurere feil, for eksempel ved å bruke en svak tilfeldighetskilde ved signering. Ed25519-støtten i OpenSSL, lagt til fra versjon 1.1.1, er derimot bygget som et eget, forenklet API der nonce-håndteringen er innebygd og ikke kan konfigureres feil av utvikleren. libsodium, som er det mest brukte biblioteket for applikasjonsutviklere som vil unngå å administrere kryptografiske detaljer selv, eksponerer Ed25519 som standard signaturmekanisme og har bevisst ikke lagt til generisk ECDSA-støtte i det hele tatt — et sterkt signal om hvilken algoritme biblioteksdesignerne anser som tryggest å sette i hendene på vanlige utviklere.

I Node.js sin innebygde crypto-modul, Python sin cryptography-pakke, og Go sin standardbibliotek crypto/ed25519 og crypto/ecdsa, er begge algoritmer tilgjengelige med noenlunde likeverdig API-kvalitet i 2026. Forskjellen som gjenstår er ikke tilgjengelighet, men fallgruver: ECDSA-API-er krever fortsatt at utvikleren eksplisitt bruker en kryptografisk sikker tilfeldighetsgenerator for signering, mens Ed25519-API-ene ikke gir utvikleren mulighet til å gjøre den feilen i utgangspunktet.

Kvantedatamaskiner og fremtiden for elliptisk kurve-kryptografi

Et poeng som ofte overses i ECDSA vs Ed25519-diskusjonen: begge algoritmene er sårbare for en tilstrekkelig stor kvantedatamaskin som kjører Shors algoritme. Det gjelder all elliptisk kurve-kryptografi, uavhengig av hvilken kurve som brukes. Verken ECDSA P-256 eller Ed25519 er kvanteresistente, og ingen av dem vil bli det — de er ikke bygget på et matematisk problem som er vanskelig for en kvantedatamaskin.

NIST har derfor allerede standardisert etterfølgere: ML-DSA (tidligere CRYSTALS-Dilithium) er den anbefalte post-kvante-signaturalgoritmen for de fleste bruksområder, med SLH-DSA som et konservativt alternativ for spesielt langsiktige signaturbehov. For team som planlegger langsiktig infrastruktur i 2026, er det verdt å tenke på ECDSA og Ed25519 som gode og trygge valg for signaturer med kort levetid (SSH-økter, TLS-sertifikater som fornyes årlig), men ikke som permanente løsninger for data eller signaturer som må forbli troverdige i flere tiår. Der post-kvante-hensyn er kritisk, bør ECDSA og Ed25519 vurderes i kombinasjon med, eller på sikt erstattet av, hybride ordninger som kombinerer klassisk og post-kvante kryptografi.

Det er verdt å understreke at valget mellom ECDSA og Ed25519 i seg selv ikke gjør noen av dem mer eller mindre utsatt for et fremtidig kvanteangrep — de faller begge samtidig, gitt en tilstrekkelig kraftig kvantedatamaskin. Diskusjonen om ECDSA versus Ed25519 og diskusjonen om post-kvante-migrering er derfor to separate spørsmål som ofte blandes sammen i praksis. Den korte versjonen: velg mellom ECDSA og Ed25519 basert på ytelse, implementasjonssikkerhet og kompatibilitet slik denne artikkelen beskriver, og planlegg post-kvante-migrering som et eget, senere prosjekt når signaturens forventede levetid faktisk strekker seg inn i en tidsperiode der kvantedatamaskiner utgjør en reell trussel.

Fem virkelige brukstilfeller

For å gjøre valget konkret, her er fem reelle systemer og hvorfor de valgte som de gjorde:

OpenSSH (utviklertilgang): har anbefalt Ed25519 som standard nøkkeltype siden versjon 6.5 fra 2014, og anbefalingen står fortsatt i 2026 fordi nøklene er korte, raske å generere, og fjerner nonce-risikoen helt for utviklere som logger inn på servere daglig.
Signal (sikker meldingsapp): bygger hele identitets- og nøkkelutvekslingslaget på Curve25519/Ed25519 fordi appen håndterer millioner av nøkkelutvekslinger daglig og trenger en algoritme som er trygg selv med enkle, mobile implementasjoner.
Offentlige nettsteder med TLS 1.3: holder seg til ECDSA P-256 fordi Web-PKI-økosystemet, nettlesere og CDN-er er bygget rundt den kurven, og et Ed25519-sertifikat i praksis ikke vil bli utstedt eller akseptert bredt.
FIDO2-passkeys for forbrukerinnlogging: bruker som oftest ECDSA P-256 fordi det gir bredest kompatibilitet på tvers av telefoner, nettlesere og sikkerhetsnøkler i dag, selv om spesifikasjonen tillater EdDSA.
Git-commit-signering hos utviklerteam: flere team har gått over til å signere commits med Ed25519 SSH-nøkler i stedet for GPG-nøkler med RSA, fordi oppsettet er enklere og nøklene allerede finnes for SSH-tilgang.
WireGuard VPN-tilkoblinger: nøkkelutvekslingen bygger på Curve25519, samme familie som Ed25519, valgt spesifikt fordi protokolldesigneren ønsket minimal angrepsflate og forutsigbar ytelse selv på svak maskinvare som IoT-rutere og innebygde brannmurer.
age, det moderne filkrypteringsverktøyet: bruker X25519 for nøkkelutveksling og er et godt eksempel på hvordan nyere verktøy bygget fra bunnen av konsekvent velger Curve25519-familien fremfor NIST-kurver når det ikke finnes noe kompatibilitetskrav som tvinger dem til noe annet.

TLS-håndtrykk i praksis: påvirker signaturvalget nettstedets hastighet?

Et vanlig spørsmål fra utviklere som optimaliserer nettsteder for Nordics-brukere er om signaturalgoritmen faktisk merkes av besøkende. Svaret er: marginalt, men det finnes en reell forskjell. Et TLS 1.3-håndtrykk med ECDSA P-256-signert sertifikat legger til noen titalls mikrosekunder ekstra prosesseringstid per tilkobling sammenlignet med et Ed25519-signert sertifikat, basert på signeringsbenchmarkene over. For et enkeltbesøk er dette usynlig for brukeren — nettverkslatens dominerer fullstendig. For en tjeneste med svært høyt volum av nye TLS-tilkoblinger, som en stor CDN-node eller en API-gateway som håndterer titusener av nye forbindelser i sekundet, kan den aggregerte CPU-besparelsen derimot bli merkbar på serversiden, selv om den er usynlig for sluttbrukeren.

Problemet er, som nevnt tidligere, at Ed25519-sertifikater i praksis ikke er tilgjengelige fra de store offentlige sertifikatutstederne i stor skala i 2026. Så selv om en tjeneste kunne spart noen prosent CPU ved å bytte til Ed25519 for offentlige TLS-sertifikater, er det sjelden et reelt valg i dag. Der valget derimot er reelt, er for intern TLS mellom mikrotjenester (mTLS), hvor teamet selv kontrollerer både klient og server og kan velge Ed25519 fritt uten å vente på bred CA-støtte. Flere norske skyarkitekter har begynt å bruke nettopp Ed25519 for intern mTLS mellom tjenester i Kubernetes-klynger, mens de fortsatt bruker ECDSA P-256 for det offentlige inngangspunktet.

Migrere fra ECDSA til Ed25519: en praktisk sjekkliste

Skal du bytte ut eksisterende ECDSA-nøkler med Ed25519, for eksempel for SSH-tilgang i organisasjonen, følger her en trinnvis fremgangsmåte som minimerer risikoen for at noen mister tilgang underveis. Den vanligste feilen team gjør i denne typen migrering er å fjerne de gamle nøklene for tidlig, før alle klienter og automatiseringsskript faktisk er oppdatert — en tilsynelatende enkel algoritmebytte kan i praksis stoppe en CI/CD-pipeline eller stenge ute en administrator som logger inn fra et sjeldent brukt verktøy.

Kartlegg hvor ECDSA-nøkler faktisk brukes i dag: SSH, TLS, kodesignering, VPN og interne API-er.
Sjekk kompatibilitet: bekreft at alle klienter, servere og biblioteker i kjeden faktisk støtter Ed25519 før du fjerner noe.
Generer nye Ed25519-nøkler parallelt med de gamle, ikke i stedet for dem ennå.
Legg til de nye offentlige nøklene der de gamle allerede er godkjent (f.eks. authorized_keys), slik at begge fungerer samtidig.
Test innlogging og signering med de nye nøklene på et lite, ikke-kritisk system først.
Rull ut til produksjon gradvis, team for team, med mulighet til å rulle tilbake.
Overvåk feilrater og supporthenvendelser i minst én til to uker etter hver rulleringsbølge.
Fjern de gamle ECDSA-nøklene først når ingen aktiv trafikk lenger bruker dem.
Dokumenter unntakene: systemer som krever FIPS-godkjenning eller mangler Ed25519-støtte, blir stående på ECDSA inntil videre.

Kommandoene under viser selve nøkkelgenereringen for SSH, som er det vanligste startpunktet for en slik migrering:

# Generer en ny Ed25519 SSH-nøkkel
ssh-keygen -t ed25519 -a 100 -C "[email protected]"

# Sammenlign med en tilsvarende ECDSA-nøkkel (P-256)
ssh-keygen -t ecdsa -b 256 -C "[email protected]"

# Legg den nye offentlige nøkkelen til på serveren, i tillegg til den gamle
cat id_ed25519.pub >> ~/.ssh/authorized_keys

Fordeler og ulemper

Ingen av algoritmene er universelt bedre. Her er en ærlig oppsummering av styrker og svakheter for begge.

ECDSA P-256

Fordeler: FIPS 186-5-godkjent, bredest mulig kompatibilitet i Web-PKI og FIDO2, fullt maskinvarestøttet i alle store HSM-er og smartkort, mange års produksjonserfaring.
Ulemper: avhengig av kvalitetssikret tilfeldighetsgenerator for hver signatur, variabel signaturstørrelse gjør parsing mer komplisert, beste ytelse krever tungt optimalisert, prosessorspesifikk kode.

Ed25519

Fordeler: deterministisk signering fjerner nonce-risiko, fast og kompakt signaturstørrelse, enklere å implementere riktig i konstant tid, standard for nye SSH-nøkler, god ytelse uten spesialtilpasset kode.
Ulemper: ikke FIPS-validert, begrenset støtte i offentlig Web-PKI for TLS-sertifikater, ujevn støtte i eldre HSM-er og PIV-smartkort, Azure Key Vault støtter den fortsatt ikke som standard nøkkeltype.

Satt på spissen: ECDSA sine ulemper er stort sett knyttet til hvor lett det er å gjøre implementasjonsfeil, mens Ed25519 sine ulemper stort sett handler om hvor bredt algoritmen er akseptert av eksterne systemer dere ikke kontrollerer selv. Det første er noe et internt team kan fikse med god praksis og kodegjennomgang. Det andre er noe som løser seg over tid etter hvert som flere sertifikatutstedere, skytjenester og maskinvareleverandører legger til støtte, men som dere ikke kan fremskynde alene.

Anbefalinger etter brukstilfelle

Basert på spesifikasjonene, ytelsestallene og støtte-status over, er dette hvordan du bør velge i ulike situasjoner:

SSH-tilgang til servere og skytjenester: velg Ed25519. Det er standardanbefalingen i OpenSSH siden 2014, nøklene er korte nok til å lime rett inn i en terminal, og nonce-risikoen forsvinner helt siden signeringen er deterministisk.
Offentlige TLS-sertifikater for nettsteder: hold deg til ECDSA P-256 inntil videre. Web-PKI-økosystemet, inkludert de fleste nettlesere og sertifikatutstedere, er rett og slett ikke klart for Ed25519 i stor skala ennå, og å velge det ville skapt unødvendige kompatibilitetsproblemer for besøkende.
Interne API-er og tjeneste-til-tjeneste-autentisering (mTLS): Ed25519, spesielt hvis du kontrollerer begge endepunkt og ikke er bundet av eldre klienter eller tredjeparts-integrasjoner som mangler støtte.
Regulerte miljøer med krav om FIPS 140-validering: ECDSA P-256, fordi det er det eneste alternativet av de to som er formelt godkjent i FIPS 186-5, og dermed det eneste som passer i en revisjonsklar dokumentasjon i dag.
Git-commit- og tag-signering for utviklerteam: Ed25519 SSH-nøkler, som nå er godt støttet i mainstream Git-verktøy og gjenbruker nøkler utviklerne allerede har for SSH-tilgang, uten behov for en separat GPG-nøkkel.
Konstrede IoT- og innebygde enheter: Ed25519, på grunn av lavere ressursbruk, mindre kode å vedlikeholde, og enklere, sikrere implementasjon på begrenset maskinvare der en full, spesialtilpasset ECDSA-implementasjon ofte ikke er realistisk.
FIDO2-passkeys for forbrukerinnlogging: ECDSA P-256, for maksimal kompatibilitet med eksisterende telefoner, nettlesere og sikkerhetsnøkler i dag, med EdDSA som fremtidig tillegg etter hvert som flere autentikatorer legger det til.
Signering av programvareoppdateringer og release-artefakter: Ed25519, delvis fordi batch-verifisering er raskere for store volum, og delvis fordi kompakte, faste signaturer er enklere å bygge inn i eksisterende oppdateringsformater.

Sikkerhet i praksis: hva har faktisk gått galt?

Det er lett å diskutere kryptografi i teorien og glemme at de fleste virkelige sikkerhetshendelser skyldes implementasjon, ikke matematikk. For ECDSA er nonce-gjenbruk det klart dominerende feilmønsteret: svak eller forutsigbar tilfeldighetsgenerering har gjentatte ganger ført til at private nøkler har blitt beregnet ut fra offentlig synlige signaturer, særlig i Bitcoin-relaterte lommebøker med dårlig implementert tilfeldighetsgenerering på mobile enheter. Mønsteret er så velkjent at det er blitt en egen kategori av sårbarheter i sikkerhetsopplæring.

For Ed25519 er bildet annerledes. Fordi determinismen er innebygd i algoritmen, finnes ikke den samme åpenbare feilklassen. De hendelsene som har dukket opp har typisk vært spesifikke biblioteksfeil, som mangelfull validering av punkter på kurven eller feil i hvordan enkelte implementasjoner håndterer malformerte signaturer — reelle feil, men strukturelt forskjellige fra ECDSA sin nonce-avhengighet. Det er en viktig distinksjon for team som vurderer risiko: ECDSA sin svakhet ligger i selve bruksmønsteret, mens Ed25519 sine svakheter historisk har ligget i enkeltimplementasjoner som kan rettes uten å endre algoritmen.

For et sikkerhetsteam som skal prioritere revisjonsarbeid, betyr dette to ulike sjekklister. Med ECDSA bør revisjonen fokusere hardt på tilfeldighetsgenerering: er RNG-en kryptografisk sikker, er den riktig seedet, gjenbrukes noen mellomsteg på tvers av signeringer, og følger implementasjonen RFC 6979? Med Ed25519 flyttes fokuset til biblioteksversjon og punktvalidering: bruker prosjektet en oppdatert, godt vedlikeholdt implementasjon (libsodium, OpenSSL 1.1.1+, eller språkets standardbibliotek), og valideres innkommende signaturer og offentlige nøkler korrekt før de stoler på dem? Begge sjekklistene er håndterbare, men de krever ulik kompetanse i teamet som gjennomfører revisjonen.

Verdikt: hvilken bør du velge i 2026?

Tallene peker ikke mot én vinner, men mot to algoritmer med ulike styrkeområder. Ed25519 vinner på designsikkerhet (deterministisk signering fjerner en hel feilklasse), på konsistent ytelse uten spesialtilpasning, og på kompakt, fast signaturstørrelse. ECDSA P-256 vinner på kompatibilitet: det er fortsatt det eneste alternativet som er FIPS 186-5-godkjent, universelt støttet i Web-PKI, og tilgjengelig i praktisk talt alle HSM-er og smartkort som finnes i dag.

For et team som setter opp SSH-tilgang eller signerer interne API-kall i 2026, er Ed25519 det tryggeste og enkleste valget. For et team som utsteder offentlige TLS-sertifikater eller må forholde seg til FIPS-krav, er ECDSA P-256 fortsatt det eneste realistiske alternativet. Begge algoritmene gir 128-bits sikkerhet — spørsmålet er aldri «hvilken er sikrest i teorien», men «hvilken passer best inn i systemet du faktisk bygger».

Oppsummert i tall: Ed25519 leverer 30 000–50 000 signeringer per sekund på tvers av de tre benchmarkene vi har sett på, mot 30 000–33 000 for ECDSA P-256, med et unntak der tungt optimalisert P-256-kode holder tritt eller marginalt slår Ed25519 på ren signeringshastighet. Signaturen er fast 64 byte for Ed25519 mot 64–72 byte variabelt for ECDSA. Skystøtten har gått fra ujevn til god i løpet av 2025, med AWS og Google Cloud på plass, mens Azure fortsatt mangler nøkkeltypen. FIPS-status er uendret: ECDSA er godkjent, Ed25519 er det ikke. Disse fire faktorene, ikke en enkelt «vinner», bør styre valget for hvert enkelt system dere bygger eller migrerer i 2026.

Ofte stilte spørsmål

Er Ed25519 tryggere enn ECDSA?

Begge gir omtrent samme sikkerhetsnivå på rundt 128 bit. Forskjellen er at Ed25519 fjerner risikoen for nonce-gjenbruk gjennom deterministisk signering, mens ECDSA er avhengig av en sikker tilfeldighetsgenerator for hver signatur. I praksis gjør det Ed25519 mer robust mot implementasjonsfeil, ikke matematisk sterkere.

Kan jeg bruke Ed25519 for TLS-sertifikater på nettstedet mitt?

Teknisk ja, men i praksis er det få offentlige sertifikatutstedere som tilbyr Ed25519-sertifikater i stor skala, og nettleserstøtten er ujevn. ECDSA P-256 er fortsatt det trygge valget for offentlige TLS-sertifikater i 2026.

Hvorfor anbefaler OpenSSH Ed25519 fremfor ECDSA?

Fordi Ed25519-nøkler er korte, raske å generere og verifisere, og fjerner nonce-relatert risiko helt. OpenSSH har anbefalt Ed25519 som standard siden versjon 6.5 fra 2014.

Støtter AWS og Google Cloud Ed25519 i sine nøkkeltjenester?

Ja. AWS KMS la til Ed25519-støtte i november 2025, og Google Cloud KMS støtter det også i sine asymmetriske nøkkelfamilier. Azure Key Vault mangler fortsatt Ed25519 som offisiell nøkkeltype i sin standarddokumentasjon.

Er ECDSA fortsatt trygt å bruke i 2026?

Ja, forutsatt at implementasjonen følger RFC 6979 for deterministiske nonces, eller bruker en kvalitetssikret tilfeldighetsgenerator. Risikoen ligger nesten utelukkende i svak nonce-håndtering, ikke i selve algoritmen.

Hvorfor bruker Bitcoin ECDSA og ikke Ed25519?

Bitcoin ble designet før Ed25519 var like moden og utbredt, og bruker ECDSA over kurven secp256k1 (ikke P-256). Å bytte signaturalgoritme i et etablert nettverk med denne skalaen krever et bredt konsensus-oppgradering, noe som er en mye større endring enn et enkelt algoritmevalg.

Kan jeg bruke Ed25519 med en YubiKey?

Ja, gjennom FIDO2/WebAuthn-grensesnittet på moderne YubiKey-modeller. Det klassiske PIV-grensesnittet, som brukes til smartkort-autentisering, er derimot bygget rundt RSA og ECDSA P-256/P-384, ikke Ed25519.

Hva er raskest i praksis, ECDSA eller Ed25519?

Det avhenger av implementasjonen. Uavhengige benchmarker viser alt fra tilnærmet likt (rundt 30 000–33 000 signaturer per sekund for begge på moderne x86-maskinvare) til Ed25519 som klart raskere når ECDSA-implementasjonen ikke er spesialtilpasset prosessoren. Ed25519 gir jevnere ytelse uten at noen må skrive assembly-optimalisert kode for å oppnå den.

Må jeg velge én algoritme for hele organisasjonen, eller kan jeg bruke begge?

De fleste organisasjoner bruker begge, avhengig av system. Et vanlig oppsett i 2026 er Ed25519 for SSH og interne API-er, kombinert med ECDSA P-256 for offentlige TLS-sertifikater og FIDO2-autentisering. Det er ikke et tegn på dårlig planlegging — det er en riktig respons på at de to algoritmene har ulike styrker i ulike deler av infrastrukturen.