To varianter av samme signaturfamilie krangler om samme jobb: å bevise at en melding kommer fra deg, uten at noen kan forfalske den. Ed25519 og Ed448 bygger begge på Edwards-kurver og den samme EdDSA-konstruksjonen, men de har ulik nøkkelstørrelse, ulikt sikkerhetsnivå og svært ulik støtte hos de store skyleverandørene. Det siste er ikke en detalj. Da Amazon la til Ed25519 i AWS KMS, valgte de å hoppe over Ed448 helt. Google Cloud gjorde det samme. Microsoft støtter verken det ene eller det andre i Azure Key Vault. Det gjør valget mellom de to langt mer praktisk enn teoretisk.
Denne artikkelen går gjennom spesifikasjonene, ytelsen, skyprisene og den faktiske støtten i verktøy som OpenSSH, Tor og DNSSEC. Målet er å gi deg et konkret svar på hvilken algoritme som passer til SSH-nøkler, TLS-sertifikater, kodesignering eller langtidsarkivering, og hvordan du migrerer dit uten å bryte noe underveis.
Bakgrunnen er verdt å kjenne til før du går videre. Daniel J. Bernstein publiserte Curve25519 allerede i 2006, og EdDSA-signaturskjemaet som bygger på den kom noen år senere sammen med medforfattere som Niels Duif, Tanja Lange, Peter Schwabe og Bo-Yin Yang. Curve448 kom til som et alternativ med høyere sikkerhetsmargin for dem som ønsket det, utviklet av Mike Hamburg. Begge endte opp i samme IETF-standard i 2017, men de siste ni årene har vist en tydelig markedsdom: utviklere og protokolldesignere har i praksis valgt den mindre, raskere varianten nesten hver eneste gang de har hatt et reelt valg.
Hva er EdDSA og Edwards-kurver
EdDSA (Edwards-curve Digital Signature Algorithm) er en signaturkonstruksjon utviklet av Daniel J. Bernstein og kolleger, senere formalisert av IETF i RFC 8032. Ed25519 bruker kurven Curve25519 i sin twisted Edwards-form, mens Ed448 bruker Curve448, ofte kalt Goldilocks-kurven. Begge er deterministiske: signaturen avhenger kun av meldingen og den private nøkkelen, ikke av en tilfeldig nonce generert ved hver signering.
Det høres teknisk ut, men konsekvensen er konkret. ECDSA har historisk vært sårbart for svak eller gjenbrukt nonce-generering, noe som har lekket private nøkler i flere kjente hendelser opp gjennom årene. EdDSA fjerner det problemet ved design, fordi nonce-verdien avledes deterministisk fra nøkkelen og meldingen selv. Det er en av grunnene til at både Ed25519 og Ed448 regnes som tryggere å implementere feilfritt enn klassisk ECDSA, selv om de matematiske sikkerhetsantagelsene ligner.
Begge algoritmene er nå del av den offisielle amerikanske standarden for digitale signaturer, NIST FIPS 186-5, som ble endelig publisert av NIST og for første gang inkluderte EdDSA-familien ved siden av RSA og ECDSA. Det gir Ed25519 og Ed448 en formell status de ikke hadde tidligere, og forklarer delvis hvorfor skyleverandører først nå begynner å legge dem til i sine nøkkeltjenester.
En annen praktisk fordel er batch-verifisering. Fordi EdDSA-signaturer er strukturert som lineære ligninger over kurvegruppen, kan man verifisere mange signaturer samtidig langt raskere enn å verifisere dem én for én, ved å kombinere dem til én kombinert sjekk med tilfeldige vekter. Det er nyttig i systemer som validerer store mengder signaturer samtidig, som blokkjeder eller sertifikattransparens-logger, og gjelder i prinsippet for både Ed25519 og Ed448. I praksis er det nesten utelukkende Ed25519-implementasjoner som faktisk har utnyttet dette i produksjonskode, rett og slett fordi det er den varianten som brukes i de systemene der volumet er stort nok til at det lønner seg.
Spesifikasjonstabell: Ed25519 mot Ed448
Tabellen under samler de tekniske forskjellene som faktisk påvirker et produksjonsvalg, fra rå tallstørrelser til hvilke systemer som støtter hva i 2026.
| Egenskap | Ed25519 | Ed448 |
|---|---|---|
| Underliggende kurve | Curve25519 (twisted Edwards) | Curve448 / Goldilocks |
| Feltstørrelse | 255-bit primtallsfelt | 448-bit primtallsfelt |
| Sikkerhetsnivå | Ca. 128 bit | Ca. 224 bit |
| Offentlig nøkkel | 32 byte | 57 byte |
| Privat nøkkel (seed) | 32 byte | 57 byte |
| Signaturstørrelse | 64 byte | 114 byte |
| Intern hash-funksjon | SHA-512 | SHAKE256 |
| Definert i | RFC 8032 | RFC 8032 |
| NIST-standard | FIPS 186-5 | FIPS 186-5 |
| TLS 1.3 signature_scheme | ed25519 (RFC 8446) | ed448 (RFC 8446) |
| OpenSSH-nøkler | Ja, ssh-ed25519 | Nei, ikke støttet |
| AWS KMS | Ja | Nei |
| Google Cloud KMS | Ja (EC_SIGN_ED25519) | Nei |
| Azure Key Vault | Nei | Nei |
| DNSSEC algoritmenummer | 15 (RFC 8080) | 16 (RFC 8080) |
| Tor identitetsnøkler | Ja | Nei |
| GnuPG / OpenPGP | Ja, standard i moderne versjoner | Delvis, avhenger av implementasjon |
Legg merke til mønsteret. Ed25519 er standardisert på papiret sammen med Ed448 i nesten alle de samme RFC-ene og NIST-dokumentene. I praksis er det bare Ed25519 som har blitt implementert bredt av de systemene folk faktisk bruker daglig.
Valget av intern hash-funksjon er verdt en kommentar. Ed25519 bruker SHA-512, en veletablert hash-funksjon som allerede fantes i de fleste kryptografibiblioteker da RFC 8032 ble skrevet. Ed448 bruker i stedet SHAKE256, en variabel-lengde utgang-funksjon fra SHA-3-familien. Valget gir Ed448 en litt annen matematisk struktur internt, men påvirker ikke den praktiske sikkerheten nevneverdig. Det betyr derimot at et bibliotek som støtter Ed25519 ikke automatisk støtter Ed448, siden de to algoritmene krever ulike underliggende hash-primitiver implementert korrekt og optimalt for å være raske i praksis.
Nøkkel- og signaturstørrelse i praksis
En Ed448-signatur er 114 byte mot 64 byte for Ed25519, nesten dobbelt så stor. Det spiller kanskje ikke stor rolle for en enkelt e-post, men det teller når signaturer sendes i store mengder. DNSSEC-soner som signerer hver post kan vokse betydelig i pakkestørrelse med Ed448, noe som øker risikoen for UDP-fragmentering og tvinger frem TCP-fallback ved DNS-oppslag. Tor-nettverket, som distribuerer identitetsnøkler for tusenvis av relés kontinuerlig, drar tilsvarende nytte av at Ed25519 holder både nøkler og sertifikater kompakte.
Samme logikk gjelder for offline-signering med QR-koder, air-gapped maskinvarelommebøker og innebygde enheter med begrenset lagringsplass. En 32-byte offentlig nøkkel og en 64-byte signatur koder seg enkelt inn i en liten QR-kode eller NFC-melding. Ed448 sine 57 og 114 byte krever mer plass, flere skanninger eller tettere koding, noe som gjør brukeropplevelsen merkbart tregere på enheter med små skjermer eller trege kameraer.
Git, som mange utviklere bruker til å signere commits og tags, er et godt eksempel på hvor lite denne forskjellen betyr i et enkelttilfelle, men hvor mye den betyr i skala. Et repository med hundretusenvis av signerte commits lagrer effektivt dobbelt så mye signaturdata hvis prosjektet velger Ed448 fremfor Ed25519, uten noen synlig gevinst for de fleste trusselmodeller.
Blokkjeder er et av de tydeligste eksemplene på hvor mye nøkkelstørrelse betyr i skala. Solana signerer hver eneste transaksjon med Ed25519, ifølge nettverkets egen tekniske dokumentasjon, nettopp fordi nettverket prosesserer et høyt antall transaksjoner per sekund og ikke har råd til at hver signatur nesten dobler seg i størrelse. Hadde et nettverk med tilsvarende volum valgt Ed448 i stedet, ville den ekstra dataen alene lagt merkbar vekt på blokkstørrelse og lagringskrav for hver eneste node i nettverket, uten at sikkerhetsgevinsten hadde vært relevant for trusselbildet transaksjonene faktisk står overfor.
Sikkerhetsnivå: 128-bit mot 224-bit forklart
Sikkerhetsnivået måles i hvor mange operasjoner en angriper i teorien må utføre for å knekke nøkkelen med best kjente angrep. Ed25519 gir omtrent 128-bit sikkerhet, som betyr rundt 2^128 operasjoner. Ed448 gir omtrent 224-bit sikkerhet, eller rundt 2^224 operasjoner. Forskjellen er astronomisk i teorien, men i praksis regnes 128-bit sikkerhet som tilstrekkelig for alt overskuelig fremtid mot klassiske datamaskiner. Ingen kjent superdatamaskin kommer i nærheten av å true et 128-bit sikkerhetsnivå de neste tiårene.
Hvorfor velger da noen Ed448? Svaret handler mindre om rå styrke og mer om sikkerhetsmargin og samsvar med visse konservative krav. Enkelte myndighetsprofiler og langtidsarkiveringssystemer ønsker seg et høyere sikkerhetsnivå som buffer mot fremtidige kryptoanalytiske fremskritt, selv uten et konkret kjent angrep i dag. FIPS 186-5 inkluderer begge nivåene nettopp for å dekke ulike risikoprofiler, fra vanlig kommersiell bruk til høyere sikkerhetsklareringer.
Det er verdt å nevne at verken Ed25519 eller Ed448 er motstandsdyktige mot en tilstrekkelig stor kvantedatamaskin. Shors algoritme bryter det underliggende diskrete logaritme-problemet for begge kurvene like effektivt. Sikkerhetsnivåforskjellen på 128 mot 224 bit gjelder klassiske angrep, ikke kvanteangrep. Har du et trusselbilde som inkluderer kvantedatamaskiner om ti til tjue år, er verken Ed25519 eller Ed448 svaret. Da bør du heller se på ML-DSA eller andre post-kvante signaturalgoritmer.
Et praktisk poeng er at sikkerhetsnivået bør henge sammen med resten av arkitekturen. Bruker systemet ditt AES-256 for symmetrisk kryptering et annet sted, kan det virke inkonsekvent å kombinere det med en signaturalgoritme på 128-bit nivå. I praksis er dette sjelden et reelt problem, siden de ulike primitivene i en systemarkitektur angripes på helt ulike måter, men det er et argument enkelte sikkerhetsteam bruker når de vurderer Ed448 fremfor Ed25519 i helhetlige krav til et system.
Ytelse: signering og verifisering
Ed25519 er raskere enn Ed448 på nesten alle plattformer og i alle kjente implementasjoner, inkludert biblioteker som libsodium og OpenSSL. Forklaringen ligger i matematikken, ikke i implementasjonskvalitet.
Hvorfor Ed25519 er raskere
Ed25519 opererer over et 255-bit primtallsfelt, mens Ed448 opererer over et 448-bit felt. Hver punktoperasjon på kurven krever flere modulære multiplikasjoner, og disse multiplikasjonene blir dyrere jo større tallene er. Et 448-bit felt krever nesten dobbelt så mange maskinord som et 255-bit felt på en vanlig 64-bit prosessor, og kostnaden ved multiplikasjon vokser raskere enn lineært med tallstørrelsen. Resultatet er at både signering og spesielt verifisering tar merkbart lengre tid med Ed448, uavhengig av hvilket bibliotek eller hvilken CPU-arkitektur som brukes.
Hva koster de ekstra bitene
For de aller fleste bruksområder, som SSH-innlogging, TLS-håndtrykk eller signering av en enkelt melding, er ytelsesforskjellen umerkelig for et menneske. Begge algoritmene fullfører en signatur på under et millisekund på moderne maskinvare. Forskjellen blir synlig først når man signerer eller verifiserer i stort volum, som ved DNSSEC-zonesignering, sertifikatutstedelse i bulk eller høyfrekvent transaksjonsverifisering. Der legger Ed448 en reell ekstra CPU-kostnad på toppen av den doblede databruken fra de større signaturene.
Det finnes ikke ett enkelt, universelt tall for hvor mye raskere Ed25519 er, fordi resultatet avhenger av prosessorarkitektur, kompilator, om koden bruker vektoriserte instruksjoner, og om man måler ren signering eller ren verifisering. Det er også derfor seriøse benchmark-prosjekter som SUPERCOP alltid oppgir eksakt CPU-modell, kompilatorflagg og biblioteksversjon sammen med resultatene sine, i stedet for å publisere ett enkelt tall som skal gjelde overalt. Den konsistente konklusjonen på tvers av disse målingene er likevel alltid den samme retningen: Ed25519 signerer og verifiserer raskere enn Ed448, aldri motsatt, uansett hvilken plattform testen kjører på.
Skystøtte og pris: AWS KMS, Google Cloud og Azure Key Vault
Her blir forskjellen mellom de to algoritmene mest konkret for en driftsansvarlig. Ingen av de tre store skyleverandørene støtter Ed448 i sine nøkkeltjenester per 2026. Støtten for Ed25519 varierer derimot, og prisen er overraskende sammenlignbar på tvers av leverandørene når man ser på selve signeringsoperasjonen.
| Tjeneste | Ed25519-støtte | Ed448-støtte | Pris per nøkkel/mnd | Pris per 10.000 signeringer |
|---|---|---|---|---|
| AWS KMS | Ja | Nei | 1,00 USD | 0,03 USD (ikke-RSA-2048) |
| Google Cloud KMS | Ja (EC_SIGN_ED25519) | Nei | 0,06 USD (programvarebeskyttet) | 0,03 USD |
| Azure Key Vault | Nei | Nei | Inkludert i flat transaksjonspris | 0,03 USD (flat rate, alle nøkkeltyper) |
Tallene kommer direkte fra AWS sin offisielle prisside for KMS og Google Cloud sin prisside for Cloud KMS, samt Microsofts prisside for Key Vault. AWS tar 0,15 dollar per 10.000 forespørsler for RSA-2048, altså fem ganger mer enn for elliptisk kurve-baserte operasjoner som Ed25519. Google skiller ikke prisen på selve signeringsoperasjonen mellom nøkkeltyper, men lar den månedlige kostnaden for en aktiv nøkkelversjon ligge på 0,06 dollar for både RSA og elliptisk kurve på programvarebeskyttelsesnivå.
Et konkret regnestykke gjør forskjellen tydeligere. Signerer du 10 millioner meldinger i måneden med Ed25519 i AWS KMS, betaler du 1 dollar for selve nøkkelen pluss 30 dollar for signeringsoperasjonene, altså 31 dollar totalt. Hadde du i stedet brukt RSA-2048 for samme volum, hadde operasjonskostnaden alene vært 150 dollar, fem ganger så mye, fordi AWS priser RSA-2048-forespørsler på 0,15 dollar per 10.000 mot 0,03 dollar for Ed25519. Google Cloud KMS lander på et lignende bilde: 0,06 dollar for nøkkelversjonen og 30 dollar for operasjonene, altså 30,06 dollar for samme volum. Azure Key Vault sin flate pris på 0,03 dollar per 10.000 operasjoner uavhengig av nøkkeltype gir 30 dollar for volumet, men løser ikke det faktum at Ed25519 ikke er tilgjengelig som nøkkeltype der i utgangspunktet.
Azure Key Vault er det klare unntaket i tabellen. Microsoft har ikke lagt til Ed25519 eller Ed448 som støttede kurvetyper i det hele tatt. Ifølge Microsofts egen dokumentasjon støtter Key Vault kun P-256, P-384, P-521 og secp256k1 for elliptisk kurve-nøkler. Vil du bruke Ed25519 i Azure, må du enten kjøre signeringen utenfor Key Vault, for eksempel i egen applikasjonskode med et bibliotek som libsodium, eller velge en av de støttede ECDSA-kurvene i stedet.
Tilgjengelighet i Norden
Alle tre tjenestene finnes i nordiske datasenterregioner. AWS KMS kjører i Stockholm-regionen eu-north-1, Google Cloud KMS kjører i Finland-regionen europe-north1, og Azure Key Vault er tilgjengelig i norway-east og norway-west, ifølge leverandørenes egne regionsoversikter. Det betyr at et norsk selskap som vil holde nøkkeloperasjoner innenfor Norden kan gjøre det med alle tre, men bare to av dem lar deg faktisk bruke Ed25519 der.
For selskaper med krav om datalagring innenfor EØS eller Norge spesifikt, gjør dette Azure Key Vault til et mindre naturlig valg dersom Ed25519 allerede er den foretrukne algoritmen i resten av arkitekturen. Et alternativ mange velger er å bruke Azure til øvrig infrastruktur, men legge selve nøkkelhåndteringen til AWS KMS i Stockholm eller Google Cloud KMS i Finland, eventuelt kjøre Ed25519-signering i egen applikasjonskode med et HSM-støttet bibliotek dersom hele arbeidslasten allerede ligger i Azure og en fullstendig leverandørbytte ikke er aktuelt.
Protokoll- og verktøystøtte i 2026
Utenfor skytjenestene handler mye om hva SSH, TLS og e-post-verktøyene dine faktisk snakker. Her er Ed25519 nesten enerådende.
- OpenSSH: støtter ssh-ed25519 som nøkkeltype for vertsnøkler og brukernøkler siden versjon 6.5. Ed448 er ikke en standard OpenSSH-nøkkeltype, ifølge OpenSSH sine egne versjonsnotater.
- TLS 1.3: definerer signature_scheme-verdier for både ed25519 og ed448 i RFC 8446, men faktisk støtte avhenger av hvilket TLS-bibliotek og sertifikat som brukes. Ed25519 er langt vanligere i praksis.
- DNSSEC: har egne algoritmenummer for begge, 15 for Ed25519 og 16 for Ed448, definert i RFC 8080. Ed25519 er betydelig mer utbredt blant DNS-operatører på grunn av de kompakte postene.
- Tor: bruker Ed25519 til relé-identitet og katalogsignering, dokumentert i Tor-prosjektets egne sertifikatspesifikasjoner. Ed448 er ikke i bruk i Tor-nettverket.
- GnuPG/OpenPGP: har støttet Ed25519-signeringsnøkler siden GnuPG 2.1, ifølge prosjektets egen oversikt over nyheter. Ed448-støtte finnes i enkelte nyere OpenPGP-implementasjoner, men er langt fra like universell.
- Signal: bruker en Ed25519-kompatibel signaturvariant kalt XEdDSA for identitetsnøkler, mens selve nøkkelutvekslingen går via X25519. Ed448 er ikke del av Signal-protokollen.
- WireGuard: bruker verken Ed25519 eller Ed448 til signering. Protokollen er bygget rundt Curve25519 og X25519 for nøkkelutveksling, ikke EdDSA-signaturer, noe som er verdt å vite for å unngå å blande sammen kurvefamilie og signaturskjema.
Mønsteret er konsekvent på tvers av hele lista. Der en protokoll støtter EdDSA i det hele tatt, er Ed25519 nesten alltid implementert først og oftest alene. Ed448 finnes i standardene, men mangler den kritiske massen av faktiske implementasjoner som gjør en algoritme nyttig i et interoperabelt system.
Det er en klassisk nettverkseffekt. En signaturalgoritme er kun nyttig hvis mottakersiden også kan validere den, og hver ny protokoll som legger til Ed25519-støtte gjør det marginalt mer attraktivt for neste protokoll å gjøre det samme. Ed448 startet i samme posisjon som Ed25519 i 2017, men manglet den innledende drahjelpen fra OpenSSH og Signal-økosystemet som ga Ed25519 et forsprang. Ti år senere er forspranget blitt til en solid vegg av produksjonsstøtte som gjør det stadig mindre attraktivt å velge Ed448, selv for team som i utgangspunktet ønsker seg det høyere sikkerhetsnivået.
Virkelige eksempler på Ed25519 og Ed448 i produksjon
Standarder er én ting, faktisk bruk i produksjon er noe annet. Fem konkrete eksempler viser hvor forskjellen mellom standardisert og faktisk brukt slår ut i praksis, og hvorfor det er langt lettere å finne Ed25519 i drift enn Ed448 i 2026. For det første signerer millioner av utviklere sine SSH-nøkler med ssh-ed25519 hver eneste dag, og GitHub anbefaler algoritmen fremfor RSA for nye nøkler. For det andre bruker Tor-nettverket Ed25519 til å identifisere hvert eneste relé og skjulte tjeneste, noe som gjør algoritmen til en usynlig, men kritisk, del av anonymitetsinfrastrukturen. For det tredje har DNS-operatører som signerer soner med DNSSEC-algoritme 15 redusert størrelsen på DNSKEY- og RRSIG-postene sine sammenlignet med eldre RSA-baserte oppsett.
For det fjerde la Amazon til Ed25519 som nøkkelspesifikasjon i AWS KMS, med signeringsalgoritmene ED25519_SHA_512 og ED25519_PH_SHA_512, noe som gjør det mulig for AWS-kunder å bruke Ed25519 i skalerbare, administrerte signeringspipeliner uten å drifte egen nøkkelinfrastruktur. For det femte har GnuPG gjort Ed25519 til standardanbefaling for nye signeringsnøkler siden versjon 2.1, noe som har flyttet store deler av OpenPGP-økosystemet bort fra RSA-2048 og eldre DSA-nøkler.
Ed448 mangler et tilsvarende sett med storskala produksjonseksempler. Algoritmen finnes i biblioteker som OpenSSL og i TLS 1.3-spesifikasjonen, men det er vanskelig å peke på en enkelt utbredt tjeneste som bruker den som standardvalg i dag. Det gjenspeiler ikke en svakhet i selve matematikken, men mangelen på etterspørsel etter 224-bit sikkerhetsnivå når 128-bit allerede dekker de fleste trusselmodeller frem mot en eventuell kvante-æra.
Som sjette eksempel er det verdt å trekke frem blokkjedenettverket Solana, som bruker Ed25519 til å signere hver transaksjon som sendes gjennom nettverket, ifølge Solanas egen utviklerdokumentasjon. Kombinert med de fem eksemplene over, fra SSH og Tor til DNSSEC, AWS KMS og GnuPG, tegner det et konsistent bilde: der en organisasjon faktisk må velge og drifte en signaturalgoritme i stor skala, lander valget nesten alltid på Ed25519, mens Ed448 forblir et standardisert alternativ uten tilsvarende produksjonstyngde.
Når bør du velge Ed25519 eller Ed448?
Valget kommer sjelden ned til ren kryptografisk styrke. Det handler om hvilket system du skal integrere med, og hvilken sikkerhetsmargin organisasjonen din faktisk krever.
- SSH-nøkler til servere og utviklere: velg Ed25519. OpenSSH støtter den nativt, og de fleste terminaler og Git-verktøy håndterer den uten ekstra konfigurasjon.
- Signering av Git-commits og tags: velg Ed25519, siden GitHub, GitLab og de fleste kodefliter allerede aksepterer nøkkeltypen for verifisert signering.
- DNSSEC-signering av soner: velg Ed25519 for kompakte poster og raskere zonetransfer, med mindre registraren din krever RSA av kompatibilitetshensyn.
- Signeringspipeliner i AWS eller Google Cloud: velg Ed25519, siden begge tjenestene støtter den native og priser den likt med andre elliptisk kurve-operasjoner. Skal du derimot bruke Azure Key Vault, må du velge en ECDSA-kurve som P-256 i stedet, siden hverken Ed25519 eller Ed448 er tilgjengelig der.
- Innebygde enheter og IoT: velg Ed25519 for lavest mulig CPU-bruk, minst signaturoverhead og enklest implementasjon på begrenset maskinvare.
- Langtidsarkivering med svært høye sikkerhetskrav: vurder Ed448 hvis organisasjonen din har et regulatorisk eller policykrav om 224-bit sikkerhetsnivå, og du kan leve med mangelen på skystøtte og bredere verktøystøtte.
- Statlige eller forsvarsrelaterte systemer med konservative sikkerhetsprofiler: Ed448 kan være riktig valg der marginen mot fremtidig kryptoanalyse veier tyngre enn ytelse og økosystemstøtte, forutsatt at all infrastruktur i kjeden faktisk støtter det.
- Vanlige nettsteder og TLS-sertifikater: hold deg til Ed25519 der sertifikatutstederen støtter det, eller ECDSA P-256 som det mest universelt kompatible alternativet i dag.
Et gjennomgående mønster i listen over er at Ed448 nesten alltid krever at du aktivt bekrefter støtte i hele kjeden, fra biblioteket i koden din til klienten som validerer signaturen i den andre enden, før du kan stole på at det fungerer i produksjon. Ed25519 har derimot nådd et modenhetsnivå der du som regel kan anta at støtte finnes, og heller bekrefte unntakene. Den asymmetrien i risiko, ikke bare selve sikkerhetsnivået, er ofte den avgjørende faktoren når et team skal ta en rask, praktisk beslutning.
Migreringsguide: slik bytter du til Ed25519
De fleste migreringer går fra RSA-2048 eller ECDSA P-256 til Ed25519, ikke fra eller til Ed448. Slik gjør du overgangen uten å låse deg selv ute av servere eller bryte eksisterende signaturer.
Den viktigste regelen underveis er å aldri fjerne en gammel nøkkel før den nye er bekreftet fungerende i alle systemer som avhenger av den. En SSH-migrering som fjerner den gamle vertsnøkkelen for tidlig kan låse driftsteamet ute av en server som befinner seg i et annet land eller datasenter, og en DNSSEC-migrering som ikke dobbeltsignerer riktig kan gjøre en hel sone uoppløselig for resolvere som validerer strengt. Bygg derfor alltid inn en overlappende periode der begge nøkkeltypene er gyldige samtidig, og sett en eksplisitt dato for når den gamle nøkkelen faktisk fjernes.
- Kartlegg hvor RSA- eller ECDSA-nøkler brukes i dag: SSH, TLS-sertifikater, kodesignering, Git, DNSSEC og eventuelle interne API-er.
- Bekreft at OpenSSL-versjonen din er 1.1.1 eller nyere, siden det er minimumskravet for innebygd Ed25519-støtte.
- Sjekk om skytjenesten din støtter Ed25519 direkte, som AWS KMS og Google Cloud KMS gjør, eller om du må håndtere signering i applikasjonslaget slik som i Azure.
- Generer en ny Ed25519-nøkkel parallelt med den eksisterende nøkkelen, uten å slette den gamle ennå.
- For SSH: legg den nye offentlige ed25519-nøkkelen til i authorized_keys på serverne dine i tillegg til den gamle, test innlogging, og fjern først den gamle nøkkelen når alt fungerer.
- For TLS-sertifikater: bestill et nytt sertifikat med Ed25519-nøkkel fra en sertifikatutsteder som støtter det, og test kompatibilitet mot klientene dine før du bytter fullstendig, siden ikke alle eldre klienter validerer Ed25519-sertifikater korrekt.
- For DNSSEC: planlegg et algoritme-rollover fra RSA til algoritme 15, inkludert dobbel signering i overgangsperioden slik at både gamle og nye resolvere validerer korrekt.
- For Git-signering: kjør git config for å bruke den nye ed25519-nøkkelen, og informer teamet om at gamle signerte commits fortsatt validerer mot den gamle nøkkelen.
- Test alle klienter, integrasjoner og tredjepartstjenester som validerer signaturene dine, siden noen eldre biblioteker mangler Ed25519-støtte helt.
- Sett en avviklingsdato for de gamle nøklene, og fjern dem fra alle systemer når overgangsperioden er over og ingen trafikk lenger bruker dem.
Kodeeksempelet under viser hvordan du genererer et Ed25519-nøkkelpar med OpenSSL fra kommandolinjen, samme kommando som brukes i steg to og fire over. Legg merke til at kommandoen ikke krever noen ekstra parametre for kurvevalg slik ECDSA gjør, siden Ed25519 alltid bruker samme kurve og samme parametersett.
openssl genpkey -algorithm ed25519 -out ed25519_private.pem
openssl pkey -in ed25519_private.pem -pubout -out ed25519_public.pem
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "[email protected]"Fordeler og ulemper
| Ed25519 | Ed448 |
|---|---|
| Fordel: rask signering og verifisering på all vanlig maskinvare | Fordel: høyere klassisk sikkerhetsmargin på 224 bit |
| Fordel: kompakte 32-byte nøkler og 64-byte signaturer | Fordel: dekker enkelte konservative myndighetskrav |
| Fordel: native støtte i AWS KMS og Google Cloud KMS | Fordel: standardisert i RFC 8032, FIPS 186-5 og TLS 1.3 |
| Fordel: bred støtte i OpenSSH, Tor, DNSSEC og GnuPG | Ulempe: ikke støttet i AWS KMS, Google Cloud KMS eller Azure Key Vault |
| Ulempe: 128-bit sikkerhetsnivå er lavere enn Ed448 på papiret | Ulempe: tregere signering og verifisering enn Ed25519 |
| Ulempe: ikke kvantesikker, som Ed448 | Ulempe: nesten dobbelt så store nøkler og signaturer |
| Ulempe: ikke støttet i Azure Key Vault | Ulempe: minimal støtte i SSH, Tor og de fleste konsumentverktøy |
Tabellen viser hvorfor dette sjelden er et vanskelig valg i praksis. Ed448 sine fordeler er reelle, men smale og teoretiske for de fleste trusselmodeller, mens ulempene er brede og konkrete: du mister skystøtte, du mister verktøystøtte, og du betaler en reell ytelseskostnad. Ed25519 sine ulemper er derimot stort sett teoretiske, ettersom 128-bit sikkerhet ikke har noen kjent praktisk svakhet mot klassiske angrep i dag. Det er denne asymmetrien, ikke en kryptografisk svakhet ved Ed448, som forklarer hvorfor markedet har landet så tydelig på én vinner.
Kjente sikkerhetsfeil og implementasjonsrisiko
Verken Ed25519 eller Ed448 har et kjent matematisk brudd. Risikoen ligger nesten alltid i implementasjonen, ikke i selve algoritmen. Vanlige feil inkluderer aksept av ikke-kanoniske kodinger av signaturkomponenter, mangelfull validering av offentlige nøkler før verifisering, og feilaktig bruk av en Ed25519-nøkkel som om den var en X25519-nøkkel til nøkkelutveksling uten riktig konvertering mellom formatene. Disse to nøkkeltypene deler underliggende matematikk, men er ikke direkte utbyttbare uten en definert konverteringsprosess.
En annen fallgruve er å gjenbruke samme nøkkelpar på tvers av protokoller som ikke er designet for det, for eksempel å bruke den samme Ed25519-nøkkelen både til SSH-autentisering og til signering av programvareoppdateringer. Selv om det tekniske formatet tillater det, blander det trusselbildene til to helt ulike systemer. Kompromitteres den ene bruken, kompromitteres begge samtidig. Beste praksis er separate nøkkelpar per formål, selv om algoritmen som brukes er den samme.
Kommandolinjeverktøy har også vist seg som en overraskende feilkilde. Rapporter fra OpenSSLs egne sikkerhetsrådgivninger har dokumentert tilfeller der kommandolinjegrensesnittet, ikke selve signaturalgoritmen, håndterte input feil. Det illustrerer et generelt poeng: en trygg algoritme betyr lite hvis biblioteket eller verktøyet rundt den kutter hjørner. Bruk alltid en oppdatert, veletablert kryptografibibliotek som libsodium eller en nylig OpenSSL-versjon, og unngå å skrive egen EdDSA-implementasjon fra bunnen av.
Et siste poeng gjelder kontekst og forhåndshasing. RFC 8032 definerer tre varianter innenfor hver kurve: en ren variant, en variant med forhåndshashing (Ed25519ph og Ed448ph) og en variant med kontekststreng. Blander man varianter mellom signering og verifisering, feiler valideringen selv om nøkkelen og meldingen er korrekte. AWS KMS støtter for eksempel både ED25519_SHA_512 og ED25519_PH_SHA_512 som separate algoritmeidentifikatorer nettopp av denne grunnen, ifølge tjenestens egen dokumentasjon.
Et beslektet råd gjelder nøkkelrotasjon og oppbevaring. Selv om EdDSA fjerner risikoen for svak nonce-generering under selve signeringen, avhenger sikkerheten fortsatt fullstendig av at den private nøkkelen aldri lekker. Bruk maskinvarebeskyttede nøkler der det er mulig, enten via en administrert tjeneste som AWS KMS eller Google Cloud KMS, eller via en lokal HSM eller sikkerhetsbrikke for SSH- og GPG-nøkler. En matematisk perfekt signaturalgoritme løser ingenting hvis den private nøkkelen ligger ukryptert på disken til en bærbar PC.
Konklusjon: hvilken bør du velge i 2026?
Dataene peker i én retning for de aller fleste. Ed25519 vinner på ytelse, på nøkkel- og signaturstørrelse, på skystøtte hos AWS og Google, og på faktisk protokollstøtte i OpenSSH, Tor, DNSSEC og GnuPG. Ed448 vinner kun på ett punkt: et høyere teoretisk sikkerhetsnivå på 224 bit mot 128 bit. For de fleste organisasjoner er det ikke nok til å oppveie at ingen av de tre store skyleverandørene, og nesten ingen konsumentverktøy, faktisk støtter det.
Velg Ed25519 som standard for SSH, TLS, DNSSEC, kodesignering og skybaserte signeringspipeliner. Reserver Ed448 for de spesifikke tilfellene der en konkret policy eller et regulatorisk krav eksplisitt spesifiserer 224-bit sikkerhetsnivå, og bekreft først at hele signeringskjeden din, fra bibliotek til klient, faktisk støtter det før du forplikter deg. Husk samtidig at ingen av algoritmene løser kvanteproblemet. Har trusselmodellen din en tidshorisont som inkluderer kvantedatamaskiner, må Ed25519 og Ed448 uansett suppleres eller erstattes med post-kvante alternativer på sikt.
For norske og nordiske team er det praktiske svaret enda enklere å lande på. Både AWS KMS i Stockholm og Google Cloud KMS i Finland lar deg holde Ed25519-nøkler og signeringsoperasjoner innenfor Norden, til en pris målt i øre per tusen operasjoner. Azure Key Vault dekker regionene godt for øvrige nøkkeltyper, men er ikke veien å gå hvis Ed25519 spesifikt er kravet. Kombinasjonen av lav pris, god regional dekning og bred verktøystøtte gjør at spørsmålet i 2026 sjelden er om du bør bruke Ed25519, men heller hvor raskt du får migrert de siste RSA- og eldre ECDSA-nøklene bort.
Hvis du allerede bruker ECDSA og vurderer å bytte til Ed25519, eller lurer på hvordan Ed25519 stiller seg mot RSA i praktisk signeringshastighet, dekker vi begge sammenligningene i egne artikler. Bruker du secp256k1 i en blokkjede-sammenheng, gjelder mange av de samme størrelses- og ytelsesargumentene som over. Og hvis nøkkelutveksling er neste steg etter signering, har vi også sett nærmere på X25519 mot P-256 og P-256 mot P-384 i egne dype gjennomganger. For flere artikler om kryptografiske grunnprimitiver, se vår samleside for kryptografi.
Ofte stilte spørsmål
Er Ed25519 sikrere enn Ed448?
Nei, Ed448 har et høyere teoretisk sikkerhetsnivå på omtrent 224 bit mot 128 bit for Ed25519. Begge nivåene regnes som trygge mot klassiske angrep i overskuelig fremtid, og Ed25519 sitt lavere nivå er ikke en praktisk svakhet for de aller fleste bruksområder.
Kan jeg bruke Ed448 i AWS, Google Cloud eller Azure?
Nei. Ingen av de tre store skyleverandørene støtter Ed448 i sine administrerte nøkkeltjenester per 2026, ifølge deres egne dokumentasjonssider. AWS KMS og Google Cloud KMS støtter Ed25519, mens Azure Key Vault støtter verken Ed25519 eller Ed448.
Er Ed25519 raskere enn Ed448?
Ja, Ed25519 er raskere enn Ed448 for både signering og verifisering på all vanlig maskinvare, siden den opererer over et mindre 255-bit felt mot Ed448 sitt 448-bit felt, noe som krever færre og billigere modulære multiplikasjoner per operasjon.
Fungerer Ed25519 og Ed448 mot angrep fra kvantedatamaskiner?
Nei. Begge algoritmene bygger på det diskrete logaritme-problemet på elliptiske kurver, som Shors algoritme kan løse effektivt på en tilstrekkelig kraftig kvantedatamaskin. Verken Ed25519 eller Ed448 er post-kvante-algoritmer, og organisasjoner med et langsiktig kvantetrusselbilde bør vurdere ML-DSA eller andre NIST-godkjente post-kvante signaturalgoritmer i tillegg.
Støtter OpenSSH Ed448-nøkler?
Nei. OpenSSH støtter ssh-ed25519 som standard nøkkeltype, men Ed448 er ikke en offisiell OpenSSH-nøkkeltype for vertsnøkler eller brukernøkler, ifølge prosjektets egen dokumentasjon.
Hvorfor er Ed25519-signaturer mindre enn Ed448-signaturer?
En Ed25519-signatur er 64 byte fordi den er bygget rundt et 255-bit felt, mens en Ed448-signatur er 114 byte fordi den er bygget rundt et 448-bit felt. Signaturstørrelsen følger direkte av feltstørrelsen og dermed av sikkerhetsnivået algoritmen er designet for.
Kan jeg bruke samme nøkkel til Ed25519-signering og X25519-nøkkelutveksling?
Ikke uten en eksplisitt og korrekt konverteringsprosess. Ed25519 og X25519 deler underliggende matematikk fra samme kurve, men er designet for ulike formål, og å blande dem uten riktig konvertering regnes som en kjent implementasjonsfeil som kan svekke sikkerheten.
Bør nye prosjekter velge Ed25519 eller RSA i 2026?
De fleste nye prosjekter bør velge Ed25519 fremfor RSA der systemet støtter det, på grunn av raskere signering, mindre nøkler og signaturer, og fravær av svakheter knyttet til dårlig tilfeldighetsgenerering ved signering. RSA er fortsatt relevant kun der eldre systemer eller spesifikke sertifiseringskrav tvinger frem det valget.
Hvorfor støtter ikke Azure Key Vault Ed25519 eller Ed448?
Microsoft har ikke offentliggjort en detaljert begrunnelse for hvorfor Ed25519 og Ed448 mangler i Azure Key Vault. Ifølge tjenestens egen dokumentasjon støttes kun RSA og elliptisk kurve-nøkler på P-256, P-384, P-521 og secp256k1. Skal du bruke Ed25519 sammen med Azure i dag, må signeringen skje utenfor Key Vault, for eksempel i applikasjonskode med et bibliotek som libsodium, eller ved å legge nøkkelhåndteringen til en annen skytjeneste som støtter algoritmen direkte.
