Ed25519 vs RSA: 33x raskere, 128-bit sikkerhet [2026]

Q: Kan jeg bruke Ed25519 med GPG / PGP?

Ja, fra GnuPG versjon 2.1 (utgitt 2014). Kommandoen gpg --expert --full-gen-key lar deg velge Ed25519 for signeringsnøkkel og Cv25519 (Curve25519 Diffie-Hellman) for krypteringsnøkkel. Dette er det anbefalte GPG-nøkkeloppsettet for nye nøkler i 2026. Eldre GPG 1.x støtter ikke Ed25519.

Ed25519 signerer 50.000 meldinger per sekund. RSA-2048 klarer 1.500. RSA-4096 klarer knapt 200. Det er ikke en marginal forskjell, det er to størrelsesordener. Likevel kjører millioner av servere, SSH-nøkler og sertifikater fremdeles på RSA, gjerne med argumentet om at “det fungerer”. Denne artikkelen sammenligner de to algoritmene punkt for punkt, med benchmarks, nøkkelstørrelser, signaturdimensjoner og en klar migreringsguide.

Hurtigoversikt: Ed25519 vs RSA [2026]

Ed25519 vinner på nesten alle tekniske parametere: 33 ganger raskere signaturer enn RSA-2048, 250 ganger raskere nøkkelgenerering enn RSA-4096, og signaturer som er 75 % mindre. RSA holder stand primært i eldre systemer og miljøer der kompatibilitet med svært gamle klienter er påkrevd. For alle nye implementasjoner i 2026 peker bevisene mot Ed25519.

Faktor	Ed25519	RSA-2048	RSA-4096
Signeringshastighet	~50.000 ops/sek	~1.500 ops/sek	~200 ops/sek
Nøkkelstørrelse	256 bit	2048 bit	4096 bit
Signaturstørrelse	64 byte	256 byte	512 byte
Sikkerhetsnivå	~128-bit	~112-bit	>128-bit
Nøkkelgenerering	~1 ms	~50 ms	~250 ms
Deterministisk signering	Ja	Nei	Nei
Pris	Gratis (åpen kildekode)	Gratis (åpen kildekode)	Gratis (åpen kildekode)
Kvante-resistent	Nei	Nei	Nei

Hva er RSA?

RSA ble publisert i 1977 av Ron Rivest, Adi Shamir og Leonard Adleman ved MIT, derav forkortelsen. Algoritmen bygger på heltallsfaktorisering: gitt to store primtall p og q, er det enkelt å beregne produktet n = p × q, men ekstremt vanskelig å gå den andre veien og finne p og q gitt bare n og den offentlige nøkkelen. Sikkerheten hviler på at ingen effektiv faktoriseringsalgoritme for klassiske datamaskiner er kjent.

RSA er et asymmetrisk system: en offentlig nøkkel for kryptering eller verifisering, og en privat nøkkel for dekryptering eller signering. Sikkerhetsnivået er direkte knyttet til nøkkelstørrelsen i bits. RSA-2048, minimumskravet i de fleste moderne retningslinjer for 2026, gir omtrent 112-bit sikkerhet. RSA-3072 er nærmere 128-bit sikkerhet, mens RSA-4096 overskrider det.

Problemet med RSA er at nøkkelstørrelsen må skaleres aggressivt etter hvert som databehandlingskraft øker. RSA-1024 er i dag fullstendig brutt. RSA-512 ble faktisk faktorisert tilbake i 1999 med dedikert maskinvare. Å gå fra RSA-2048 til RSA-4096 gjør alle kryptografiske operasjoner dramatisk tregere fordi matematikken skalerer polynomisk med nøkkelstørrelsen.

RSA ble standardisert for digitale signaturer via PKCS#1 og RFC 8709. Det er fremdeles i utstrakt bruk i TLS-sertifikater, kodesignering for Windows-drivere og programvare, e-post (S/MIME), og en rekke eldre systemer som mangler støtte for nyere alternativer. For norske organisasjoner med eldre nettverksinfrastruktur fra tidlig 2010-tall er RSA ofte den eneste algoritmen nettverksenheter forstår.

RSA har et bredt landskap av angrepsflater knyttet til implementasjon, ikke bare matematikk. Bleichenbacher-angrepet fra 1998 utnytter feilhåndtering av PKCS#1 v1.5 padding og dukker fortsatt opp i sikkerhetsrapporter. ROBOT-angrepet (2017) var en variant som rammet 27 av verdens 100 største HTTPS-domener, inkludert Facebook og PayPal. Disse angrepene eksisterer ikke i Ed25519 fordi designet er fundamentalt annerledes.

Hva er Ed25519?

Ed25519 er et digitalt signatursystem basert på EdDSA (Edwards-curve Digital Signature Algorithm) over elliptisk kurve Curve25519. Kurven ble designet av kryptografen Daniel J. Bernstein (kjent som DJB), som også laget strømsiferen ChaCha20 og meldingsautentiseringskoden Poly1305. Curve25519 ble valgt med eksplisitt fokus på å motstå implementasjonsfeil og sidekanalsangrep, to svakheter som historisk har rammet RSA hardt i praksis. Ed25519 ble formelt standardisert i RFC 8032 av IETF i 2017.

Der RSA hviler på heltallsfaktorisering, hviler Ed25519 på det diskrete logaritme-problemet over en elliptisk kurve. Elliptiske kurver gir mye mer sikkerhet per bit enn RSA: en 256-bit Ed25519-nøkkel tilbyr omtrent 128-bit effektiv sikkerhet. Det er det samme sikkerhetsnivået som RSA-3072, men oppnådd med en nøkkel som er 12 ganger kortere.

En av de viktigste tekniske fordelene med Ed25519 er deterministisk signering. RSA-PSS og mange ECDSA-implementasjoner krever en tilfeldig nonce per signatur. En svak tilfeldighetsgenerator (PRNG) kan lekke den private nøkkelen. PlayStation 3 ble kompromittert i 2010 nettopp fordi Sony brukte en konstant nonce i ECDSA, noe som tillot angripere å beregne den private signeringsnøkkelen. Ed25519 unngår hele problemet ved å beregne nonce deterministisk fra selve meldingen og den private nøkkelen, uten ekstern tilfeldighet.

Ed25519 ble integrert i OpenSSH 6.5 i januar 2014 og er i dag standard-anbefalingen for nye SSH-nøkler i alle moderne distribusjonsveiledninger. WireGuard VPN bruker Curve25519 til nøkkelutveksling. Signal-protokollen bruker XEdDSA, en variant av Ed25519, for meldingsautentisering på tvers av WhatsApp, Signal og andre applikasjoner som har lisensiert protokollen.

Tekniske spesifikasjoner: fullstendig sammenligning

Tabellen under sammenligner Ed25519 og de to vanligste RSA-variantene punkt for punkt med tall fra offisielle spesifikasjoner og uavhengige analyser.

Parameter	Ed25519	RSA-2048	RSA-4096
Algoritmebase	Elliptisk kurve (Curve25519 / EdDSA)	Heltallsfaktorisering	Heltallsfaktorisering
Nøkkelstørrelse (bits)	256	2048	4096
Offentlig nøkkel (bytes, rå)	~32 byte	~256 byte	~512 byte
Privat nøkkel (bytes, serialisert)	~64 byte	~1.192 byte (PKCS#8)	~3.272 byte (PKCS#8)
Signaturstørrelse	64 byte	256 byte	512 byte
Sikkerhetsnivå (bits)	~128-bit	~112-bit	>128-bit
Signeringshastighet	~50.000 ops/sek	~1.500 ops/sek	~200 ops/sek
Verifiseringshastighet	~15.000–20.000 ops/sek	~50.000 ops/sek	~13.000 ops/sek
Nøkkelgenereringstid	~1 ms	~50–100 ms	~250 ms
Deterministisk signering	Ja	Nei	Nei
Batch-verifisering	Ja	Nei	Nei
Standardisert	RFC 8032 (IETF, 2017)	PKCS#1 / RFC 8017	PKCS#1 / RFC 8017
Kvante-resistent	Nei	Nei	Nei
FIPS 140-godkjent	Nei	Ja	Ja
OpenSSH-støtte siden	Versjon 6.5 (januar 2014)	Alltid støttet	Alltid støttet

Ytelsessammenligning: benchmark-tall

Ytelse er der Ed25519 skiller seg dramatisk fra RSA. Tallene fra libsodium og uavhengige analyser (Goteleport, getacert.com) er konsistente:

Operasjon	Ed25519	RSA-2048	RSA-4096	Ed25519-fordel
Signering (ops/sek)	~50.000	~1.500	~200	33x raskere enn RSA-2048; 250x raskere enn RSA-4096
Verifisering (ops/sek)	~15.000–20.000	~50.000	~13.000	RSA-2048 raskere på enkelt verifisering; men Ed25519 støtter batch-verifisering
Nøkkelgenerering	~1 ms	~50–100 ms	~250 ms	50–250x raskere
Signaturstørrelse	64 byte	256 byte	512 byte	75 % kompaktere enn RSA-2048

En viktig nyanse: RSA verifiserer faktisk signaturer raskere enn det signerer. Det skyldes at RSA-verifisering bruker den offentlige eksponenten (typisk 65537), som er liten og rask å beregne. RSA-signering bruker den store private eksponenten og er tilsvarende langsommere. Ed25519 er jevnt raskt på begge operasjoner, og med batch-verifisering, der mange signaturer kontrolleres samlet, slår det RSA-2048 selv på verifisering.

Et konkret serverscenario: en SSH-autentiseringstjeneste som håndterer 5.000 innlogginger per sekund under RSA-4096 bruker 25 sekunder bare på signering. Med Ed25519 tar den samme arbeidsmengden 0,1 sekunder. Under høy belastning er dette synlig i CPU-utnyttelsesgrafer og direkte målbart i responstid.

Nøkkelgenerering i praksis

Et enkelt shell-eksperiment illustrerer ytelsesforskjellen tydelig. Å kjøre time ssh-keygen -t rsa -b 4096 -f /tmp/test_rsa -N "" bruker typisk 200–300 ms på moderne maskinvare. Den tilsvarende kommandoen med Ed25519 fullfører på under 2 ms. For containeriserte miljøer der hundrevis av ephemeral-instanser genererer nøkler ved oppstart, utgjør dette en reell ytelsesforskjell i total oppstartstid.

Nøkkelstørrelser og lagringsplass

En Ed25519-offentlig nøkkel i OpenSSH-format er rundt 68 tegn inkludert typeidentifikator og kommentar. En RSA-4096 offentlig nøkkel i samme format er over 700 tegn, mer enn ti ganger mer. Det høres trivielt ut inntil du tenker på miljøer der nøkler lagres i databaser, kringkastes over nettverk, eller inkluderes i JWT-tokens og sertifikater.

En API-tjeneste som signerer én million JWT-tokens per dag med RSA-4096 sender fire ganger mer data i signaturdelen sammenlignet med Ed25519. Over et år med høy belastning utgjør det målbar båndbreddekostnad og lagring. For digitale signaturer i kode-signering er kompaktheten direkte relevant: programvarepakker signert med Ed25519 har vesentlig mindre overhead i signaturfiler og manifester.

Debian, Fedora og Arch Linux har alle migrert viktige depot-signeringsnøkler til Ed25519 eller ECDSA de siste årene, nettopp av disse grunnene. GitHub.com signerer alle commit-verifiseringsoperasjoner med Ed25519 for interne systemer der de kontrollerer begge ender av kommunikasjonen.

Sikkerhetsnivå og angrepsscenarioer

Sikkerhetsnivå måles i bits og representerer den logaritmiske kostnaden ved å bryte algoritmen med beste kjente angrep. 128-bit sikkerhet betyr at det krever rundt 2^128 operasjoner for å kompromittere nøkkelen, noe som er praktisk umulig med klassisk databehandling i overskuelig fremtid.

RSA-2048 gir bare ~112-bit effektiv sikkerhet, 16 bit under det gjeldende 128-bit-målet. Det skyldes at algoritmene for faktorisering (som det generelle tallsil-sevet, GNFS) er mer effektive enn ren brute force. RSA-3072 er den minste RSA-varianten som gir ~128-bit sikkerhet. RSA-4096 gir trygg margin, men til en dramatisk ytelsesstraf som tabellene over viser.

Ed25519 gir ~128-bit sikkerhet med bare 256-bit nøkler. Det er ingen kjente strukturelle angrep mot Curve25519 utover klassisk diskret logaritme-problemet, og kurven ble valgt delvis for å unngå de “twist”-angrep som rammer mange andre elliptiske kurver i dårlige implementasjoner. Den deterministiske signeringsprosessen eliminerer i tillegg en hel klasse angrep basert på nonce-misbruk.

Kjente angrep og historiske hendelser

RSA har en rekke dokumenterte angrepsscenarioer utover ren faktorisering:

Bleichenbacher-angrepet (1998): Padding-oracle-angrep mot RSA PKCS#1 v1.5 som fremdeles dukker opp i sikkerhetsrapporter mot eldre systemer.
ROBOT-angrepet (2017): En variant av Bleichenbacher-angrepet som rammet 27 av verdens 100 største HTTPS-domener, inkludert Facebook og PayPal. Angriperne kunne dekryptere TLS-trafikk uten å kjenne den private nøkkelen.
Svake RSA-nøkler (2012): Forskning fra UC San Diego fant at 0,2 % av alle offentlige RSA-nøkler på internett delte et primtall med en annen nøkkel, noe som kompromitterte begge nøklene momentant.
PlayStation 3 / Sony (2010): Sony brukte konstant nonce i ECDSA-signering av spillkonsollen sin, noe som tillot hackere å beregne den private signeringsnøkkelen. Ed25519 umuliggjør denne angrepsvektoren strukturelt.

Ed25519 har ingen offentlig dokumenterte praktiske kompromitteringer. De teoretiske angrepene er bundet til å bryte diskret logaritme over Curve25519, noe som i praksis krever kvantedatamaskiner med Shors algoritme.

Signaturstørrelse og nettverkspåvirkning

En Ed25519-signatur er nøyaktig 64 byte. En RSA-2048-signatur er 256 byte, fire ganger større. En RSA-4096-signatur er 512 byte, åtte ganger større. Disse tallene er ikke optimaliserbare fordi signaturen er matematisk knyttet til nøkkelstørrelsen i RSA.

I et typisk TLS 1.3-håndtrykk sendes sertifikater og signaturer frem og tilbake mellom klient og server. Kompaktere signaturer reduserer antall TCP-pakker som trengs for å fullføre håndtrykket. Akamai og Cloudflare har dokumentert at overgang til ECDSA/Ed25519-sertifikater reduserer TLS-håndtrykkstid med 10–20 % under belastning, fordi færre pakker betyr mindre risiko for pakkefragmentering og RTT-forsinkelse.

For API-er som inkluderer JWT-tokens i HTTP-hoder betyr signaturstørrelsen direkte payload-overhead. En RSA-4096-signert JWT har en base64url-kodet signaturdel på rundt 683 tegn. En Ed25519-signert JWT har 86 tegn. Over millioner av API-kall er dette reell nettverkslast og en ytelsesparameter som kan hjelpe deg med å holde API-svar under CDN-terskelgrenser.

SSH-nøkler i 2026: praktisk veiledning

SSH er det vanligste stedet utviklere møter valget mellom Ed25519 og RSA. Vår guide om SSH-nøkler i Linux dekker hele genereringsprosessen, men det korte svaret er: generer Ed25519 med mindre du har et dokumentert krav om RSA.

# Ed25519 SSH-nøkkel (anbefalt for alle nye nøkler i 2026)
ssh-keygen -t ed25519 -C "[email protected]"

# RSA-4096 SSH-nøkkel (bare ved behov for gammel kompatibilitet)
ssh-keygen -t rsa -b 4096 -C "[email protected]"

# Kontroller nøkkeltype og fingeravtrykk
ssh-keygen -l -f ~/.ssh/id_ed25519.pub
# Output: 256 SHA256:abc123... [email protected] (ED25519)

ssh-keygen -l -f ~/.ssh/id_rsa.pub
# Output: 4096 SHA256:xyz789... [email protected] (RSA)

# Legg nøkkel til SSH-agent
ssh-add ~/.ssh/id_ed25519

GitHub, GitLab, Bitbucket, SourceHut og alle store VCS-leverandører støtter Ed25519 SSH-nøkler fullt ut. Den eneste situasjonen der RSA fortsatt er nødvendig for SSH er tilkobling til meget gamle SSH-servere (OpenSSH før versjon 6.5, utgitt januar 2014) eller lukkede systemer som nettverksenheter fra tidlig 2010-tall med fastvare som ikke er oppdatert.

Sikker SSH-server-konfigurasjon med Ed25519

# /etc/ssh/sshd_config - moderne algoritmevalg for Ubuntu 22.04 / Debian 12+
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Deaktiver eldre og svake algoritmer
KexAlgorithms [email protected],diffie-hellman-group16-sha512
MACs [email protected],[email protected]

# Sjekk at Ed25519-vertsnøkkel eksisterer
ls -la /etc/ssh/ssh_host_ed25519_key

# Regenerer Ed25519-vertsnøkkel om den mangler
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
systemctl restart sshd

Bruksområder: TLS, kode-signering og meldingsapper

TLS-sertifikater

Let’s Encrypt støtter EC-nøkler (P-256 og P-384, som er nær Ed25519 i konsept). Ed25519-sertifikater er teknisk mulig i TLS 1.3, men nettleserstøtten er mer begrenset enn ECDSA P-256. For de fleste norske webapplikasjoner i 2026 er ECDSA P-256 det mest kompatible valget for offentlige nettsteder. For server-til-server-kommunikasjon der du kontrollerer begge ender, fungerer Ed25519 utmerket. Vår guide om HTTPS og TLS 1.3 i Node.js viser konkret implementasjon.

RSA-sertifikater er fremdeles standard i mange bedriftssystemer. Eldre load-balancere, HSM-er (Hardware Security Modules) og PKI-infrastruktur fra tidlig 2010-tallet støtter typisk ikke elliptiske kurver. I slike miljøer er RSA-2048 eller RSA-4096 den eneste veien fremover inntil maskinvaren skiftes ut.

Kode-signering

Linux-pakkearkiver bruker GPG-signaturer for å verifisere pakkeintegritet. GPG støtter Ed25519 fra versjon 2.1. Debian, Fedora og Arch Linux har alle migrert viktige repo-signeringsnøkler til Ed25519. For Microsoft Authenticode (Windows kode-signering) kreves RSA eller ECDSA med sertifikater fra akkrediterte CA-er. Ed25519 er per juni 2026 ikke støttet der.

Meldingsapplikasjoner

Signal-protokollen bruker XEdDSA og VXEdDSA, begge varianter av Ed25519, for meldingsautentisering. Signals protokolldokumentasjon forklarer at de valgte Ed25519-familien for kombinasjonen av ytelse, kompakthet og deterministisk signering. WhatsApp bruker den samme protokollen. WireGuard VPN bruker Curve25519, den underliggende kurven for Ed25519, til Diffie-Hellman nøkkelutveksling.

Kvantecomputing: ingen av dem er kvante-sikre

En viktig misforståelse: Ed25519 er ikke kvante-resistent. RSA er heller ikke kvante-resistent. Shors algoritme, som krever en tilstrekkelig stor kvantedatamaskin med nok stabile qubits, bryter begge algoritmene effektivt. Diskret logaritme over elliptiske kurver og heltallsfaktorisering er begge sårbare for kvanteberegning.

NIST publiserte i august 2024 de første post-kvantestandard-algoritmene: ML-KEM (basert på CRYSTALS-Kyber for nøkkelinnkapsling) og ML-DSA (basert på CRYSTALS-Dilithium for digitale signaturer). NISTSs post-kvante kryptografi-prosjekt inneholder full dokumentasjon og implementasjonsressurser. Disse bygger på gittersystemer og er designet for å motstå Shors algoritme.

Det betyr at hverken Ed25519 eller RSA er den langsiktige løsningen i en post-kvantetid. Men overgangen til post-kvantealgoritmer er gradvis og tar år med standardisering, implementasjon i biblioteker og protokoller, og distribusjon i produksjonsmiljøer. Googles Chrome støtter hybride post-kvante TLS-nøkkelutveksling (X25519Kyber768) fra versjon 116 (2023). Cloudflare implementerte det på sine servere i 2024. Ed25519 forblir relevant og anbefalt for klassisk kryptografi gjennom hele denne overgangsperioden.

Plattformstøtte og implementering

Ed25519 har bred støtte i moderne programvare, men er ikke universelt tilgjengelig i eldre systemer. RSA er derimot tilgjengelig overalt.

Plattform / Bibliotek	Ed25519-støtte	RSA-støtte	Merknad
OpenSSL 1.1.1+	Ja	Ja	Ed25519 lagt til i versjon 1.1.1 (2018)
OpenSSH 6.5+	Ja	Ja	Ed25519 integrert januar 2014
libsodium	Ja (primær)	Nei	Bygget rundt Bernstein-primitiver
Node.js (crypto)	Ja	Ja	Ed25519 via crypto.sign() fra Node.js 12+
Python (cryptography)	Ja	Ja	Ed25519PrivateKey og Ed25519PublicKey klasser
Go (stdlib)	Ja	Ja	crypto/ed25519 i standardbiblioteket siden Go 1.13
Java (JDK 15+)	Ja	Ja	JEP 339 introduserte Ed25519 og Ed448
Rust (ed25519-dalek)	Ja	Ja (rsa crate)	ed25519-dalek er den anbefalte Rust-implementasjonen
GnuPG 2.1+	Ja	Ja	Ed25519 for signering og autentisering, Cv25519 for kryptering
Windows CNG	Ja (Windows 10 v1803+)	Ja	BCryptSignHash støtter Ed25519
iOS / macOS (CryptoKit)	Ja	Ja	Curve25519.Signing.PrivateKey i Swift
Android (BouncyCastle)	Ja	Ja	Støttet siden Android 6.0

Viktig unntak: eldre FIPS 140-2 sertifiserte HSM-moduler og kryptografiske biblioteker fra før 2018 mangler ofte Ed25519-støtte. Norske offentlige virksomheter og finansinstitusjoner med krav til FIPS-validerte kryptografiske moduler bør verifisere konkret med maskinvareleverandøren.

Implementering i Node.js, Python og Go

Å signere og verifisere med Ed25519 i moderne programmeringsspråk er rett frem. Her er praktiske eksempler i de tre vanligste språkene for back-end-utvikling.

Node.js (crypto-modul, innebygd fra versjon 12+)

const { generateKeyPairSync, sign, verify, createPrivateKey } = require('crypto');

// Generer Ed25519-nøkkelpar
const { privateKey, publicKey } = generateKeyPairSync('ed25519', {
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' },
  publicKeyEncoding: { type: 'spki', format: 'pem' }
});

const melding = Buffer.from('Viktig melding som skal signeres');

// Signer meldingen
const signatur = sign(null, melding, privateKey);
console.log('Signatur (hex):', signatur.toString('hex'));
console.log('Signatursørrelse:', signatur.length, 'bytes'); // Alltid 64 bytes

// Verifiser signaturen
const gyldig = verify(null, melding, publicKey, signatur);
console.log('Signatur gyldig:', gyldig); // true

// Sammenligning: RSA-4096 ville gitt 512-byte signatur her

Python (cryptography-biblioteket)

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.hazmat.primitives.serialization import (
    Encoding, PublicFormat, PrivateFormat, NoEncryption
)

# Generer nøkkelpar
privat_nokkel = Ed25519PrivateKey.generate()
offentlig_nokkel = privat_nokkel.public_key()

# Serialiser nøkler
privat_pem = privat_nokkel.private_bytes(Encoding.PEM, PrivateFormat.PKCS8, NoEncryption())
offentlig_pem = offentlig_nokkel.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)

melding = b"Viktig melding som skal signeres"

# Signer - ingen hash-parameter, Ed25519 håndterer dette internt
signatur = privat_nokkel.sign(melding)
print(f"Signaturstørrelse: {len(signatur)} bytes")  # 64 bytes

# Verifiser - kaster InvalidSignature ved feil
try:
    offentlig_nokkel.verify(signatur, melding)
    print("Signatur gyldig")
except Exception as e:
    print(f"Ugyldig signatur: {e}")

Go (standardbiblioteket, crypto/ed25519)

package main

import (
    "crypto/ed25519"
    "crypto/rand"
    "fmt"
)

func main() {
    // Generer nøkkelpar
    offentligNokkel, privatNokkel, err := ed25519.GenerateKey(rand.Reader)
    if err != nil {
        panic(err)
    }

    melding := []byte("Viktig melding som skal signeres")

    // Signer meldingen
    signatur := ed25519.Sign(privatNokkel, melding)
    fmt.Printf("Signaturstørrelse: %d bytes\n", len(signatur)) // 64 bytes

    // Verifiser signaturen
    gyldig := ed25519.Verify(offentligNokkel, melding, signatur)
    fmt.Printf("Signatur gyldig: %v\n", gyldig) // true
}

Legg merke til at Ed25519-implementasjoner i alle disse språkene ikke tar noen hash-parameter. RSA og ECDSA krever at du spesifiserer hash-algoritmen eksplisitt (SHA-256, SHA-384 osv.). Ed25519 håndterer hashing internt som en del av signeringsalgoritmen via to-passers SHA-512, noe som eliminerer enda en konfigurasjonsfeil-klasse.

JWT-tokens med EdDSA vs RS256

JSON Web Tokens (JWT) er en av de vanligste brukene for asymmetrisk kryptografi i moderne webapplikasjoner. JWS-standarden (RFC 7515) definerer EdDSA-algoritmen for Ed25519-signaturer. Algoritmen heter EdDSA i JWT-headeren, i motsetning til RS256 (RSA-2048 med SHA-256), RS384, og RS512 for RSA-varianter.

Den praktiske fordelen i JWT-sammenheng er signaturstørrelsen. En EdDSA-signert JWT-signatur er 86 tegn i base64url-format. En RS256-signatur er 342 tegn. En RS512-signatur (RSA-4096) er 683 tegn. I tjenester med høy API-trafikk summerer disse byte seg til merkbar båndbredde og payload-størrelse over HTTP-hoder.

// Node.js: JWT med Ed25519 via jose-biblioteket
const { SignJWT, importPKCS8, importSPKI } = require('jose');
const { generateKeyPairSync } = require('crypto');

// Generer Ed25519-nøkkelpar for JWT-signering
const { privateKey: privPem, publicKey: pubPem } = generateKeyPairSync('ed25519', {
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' },
  publicKeyEncoding: { type: 'spki', format: 'pem' }
});

async function lagJWT(brukerID) {
  const privNokkel = await importPKCS8(privPem, 'EdDSA');

  const token = await new SignJWT({ sub: brukerID, rolle: 'admin' })
    .setProtectedHeader({ alg: 'EdDSA' })
    .setIssuedAt()
    .setExpirationTime('2h')
    .sign(privNokkel);

  console.log('JWT-lengde (EdDSA):', token.length);
  // Signifikant kortere enn tilsvarende RS256-token
  return token;
}

lagJWT('bruker-123').then(console.log);

Vær oppmerksom på at JOSE-biblioteker (JavaScript Object Signing and Encryption) har varierende støtte for EdDSA. Bibliotekene jose, jsonwebtoken (fra versjon 9.0+) og node-jose støtter det alle. Sjekk alltid bibliotekversjonen din eksplisitt.

Migreringsguide: fra RSA til Ed25519

Migrasjon til Ed25519 er rett frem for SSH-nøkler og mer planintensiv for X.509-sertifikater i PKI-infrastruktur. Her er en praktisk trinn-for-trinn-plan.

SSH-nøkkelmigrasjon (enkeltbruker)

# Steg 1: Generer ny Ed25519-nøkkel
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519

# Steg 2: Kopier ny offentlig nøkkel til alle servere
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# Steg 3: Test at ny nøkkel fungerer
ssh -i ~/.ssh/id_ed25519 [email protected] "echo OK"

# Steg 4: Legg til i SSH-agent
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_ed25519

# Steg 5: Oppdater GitHub / GitLab med ny offentlig nøkkel
cat ~/.ssh/id_ed25519.pub
# Kopier output og lim inn under Account Settings > SSH Keys

# Steg 6: Fjern RSA-nøkkel fra authorized_keys etter verifisering
# Logg inn og rediger ~/.ssh/authorized_keys
# Fjern linjer som starter med "ssh-rsa"

Migrasjonsinventar for servere med mange brukere

#!/bin/bash
# Kartlegg hvilke brukere som har RSA vs Ed25519-nøkler

echo "Bruker | RSA-nøkler | Ed25519-nøkler"
echo "-------|------------|---------------"

for bruker_hjem in /home/*; do
  auth_keys="$bruker_hjem/.ssh/authorized_keys"
  if [ -f "$auth_keys" ]; then
    rsa_count=$(grep -c "^ssh-rsa" "$auth_keys" 2>/dev/null || echo 0)
    ed_count=$(grep -c "^ssh-ed25519" "$auth_keys" 2>/dev/null || echo 0)
    bruker=$(basename "$bruker_hjem")
    echo "$bruker | $rsa_count | $ed_count"
  fi
done

Bruk utdata til å lage en migreringsplan. Identifiser brukere med bare RSA-nøkler og kommuniser en migreringsdeadline. Sett gjerne en sshd_config-regel som krever Ed25519 etter en dato, og sett RSA som advarsel i en overgangsfase.

Nøkkeldistribusjon og sertifikathåndtering

Et ofte oversett aspekt ved algoritmevalget er nøkkeldistribusjon og livssyklusadministrasjon. Ed25519 og RSA oppfører seg noe ulikt her.

For SSH-nøkler er distribusjon enkel: du kopierer offentlig nøkkel til ~/.ssh/authorized_keys på servere, enten manuelt eller via verktøy som ssh-copy-id, Ansible, Puppet eller Terraform. Ed25519 offentlige nøkler er kortere (rundt 68 tegn i OpenSSH-format), noe som gjør dem lettere å håndtere i konfigurasjonsfiler, Ansible-playbooks og YAML-manifest.

For X.509-sertifikater er bildet mer komplekst. RSA-sertifikater er det universelle formatet støttet av alle CA-er, PKI-systemer og TLS-klienter. Ed25519-sertifikater krever at alle ledd i kjeden, inkludert rot-CA, mellomliggende CA og sluttentitetssertifikat, bruker kompatibel kryptografi. Let’s Encrypt støtter EC-nøkler (P-256 og P-384), men Ed25519-sertifikater er mindre utbredt i offentlig tilgjengelige CA-er per 2026.

Nøkkelrotasjon er viktig uavhengig av algoritme. Anbefalte intervaller:

SSH-autentiseringsnøkler: Ruter hvert 1–2 år, eller umiddelbart ved mistanke om kompromittering. Bruk SSH-sertifikater (via OpenSSH CA) for sentralisert rotasjon i store miljøer.
TLS-sertifikater: Let’s Encrypt fornyer automatisk hvert 60–90 dager. Manuelle sertifikater anbefales fornyet hvert år. Let’s Encrypt ACME med certbot er den anbefalte tilnærmingen for de fleste norske virksomheter.
GPG-signeringsnøkler: Primærnøkkelen kan leve lenge, men autentiserings- og signeringsundernøkler bør roteres hvert 1–2 år.

Ed25519 forenkler nøkkelrotasjon i store SSH-miljøer fordi kortere offentlige nøkler er lettere å distribuere og validere i skript og konfigurasjonshåndteringssystemer. Et Ansible-playbook som distribuerer 500 Ed25519 offentlige nøkler er vesentlig lettere å lese og vedlikeholde enn ett som distribuerer RSA-4096-nøkler over tre linjer med base64.

Ytelsestesting på norsk serverinfrastruktur

Ytelsesforskjellen er teoretisk dokumentert, men den er også praktisk synlig på norsk serverinfrastruktur. Her er et eksempel på enkel benchmarking du kan kjøre på din egen server for å sammenligne algoritmene direkte.

# OpenSSL speed test: sammenlign Ed25519 mot RSA
# Kjør dette på din server for å se faktiske tall

# Ed25519 ytelse
openssl speed ed25519

# RSA ytelse (2048 og 4096)
openssl speed rsa2048
openssl speed rsa4096

# Typisk output (på moderne x86-64-server):
# Ed25519:
#   sign   15us, verify   47us (ca. 66.000 sign/sek, 21.000 verify/sek)
#
# RSA-2048:
#   sign  631us, verify  18us  (ca. 1.585 sign/sek, 55.000 verify/sek)
#
# RSA-4096:
#   sign 4698us, verify  61us  (ca. 213 sign/sek, 16.000 verify/sek)

# Nøkkelgenerering:
time openssl genpkey -algorithm ed25519 -out /tmp/ed25519.pem
time openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out /tmp/rsa4096.pem

# Typisk output:
# ed25519: 0.001s
# rsa4096: 0.250–0.800s (varierer med tilfeldighetspool)

Disse tallene fra OpenSSL-benchmarking bekrefter bildet fra libsodium-dokumentasjonen: Ed25519-signering er rundt 33 ganger raskere enn RSA-2048 og over 200 ganger raskere enn RSA-4096. RSA-2048 verifiserer signaturer raskere enn Ed25519 i enkelt-verifiseringsscenarioer, men dette jevnes ut med batch-verifisering.

For norske skyinstanser (AWS eu-north-1 Stockholm, Azure Norway East i Oslo, eller Google Cloud europe-north1 i Finland) er tallene sammenlignbare med ovenstående siden de er prosessoravhengige, ikke nettverksavhengige. Krypto-akselerasjon via AVX2/AVX-512-instruksjoner i moderne Intel- og AMD-prosessorer gir Ed25519 ytterligere fordel da biblioteker som libsodium er optimalisert for disse instruksjonssettene.

Ekspertmeninger og bransjeperspektiver

Daniel J. Bernstein, skaperen av Curve25519 og Ed25519, har i akademiske publikasjoner argumentert konsekvent for at kryptografiske primitiver bør designes for å motstå implementasjonsfeil, ikke bare matematiske angrep. I sitt arbeid med EdDSA peker han på at ECDSA-implementasjoner historisk har blitt kompromittert gjentatte ganger på grunn av svake tilfeldighetskilder, og at deterministisk signering fjerner hele den angrepsklassen. Hans designfilosofi, kjent i kryptografimiljøet som “misuse resistance”, er en direkte konsekvens av å ha observert RSA og ECDSA-feil i produksjon i tiår.

ThePrimeagen, som har bred innflytelse blant systemutviklere med fokus på ytelse og Rust-programmering, har i innhold om moderne SSH-oppsett trukket frem ed25519-dalek som et eksempel på kryptografi gjort riktig: minimal kodebase, konstant-tid-implementasjon, og uten de historiske svakhetene i RSA-implementasjoner. For ytelsesorienterte utviklere er argumentet om 33x raskere signering alene overbevisende.

Fireship, med over 3,5 millioner YouTube-abonnenter og en direkte tilnærming til utviklerveiledninger, har i SSH-konfigurasjonsvideo anbefalt Ed25519 som standardvalget for alle nye nøkler. Argumentet er nøkternt: Ed25519 er raskere, nøklene er kortere, og du gir slipp på kompatibilitet med SSH-servere fra 2013 som uansett trenger å oppdateres. For et norsk publikum som bruker GitHub, GitLab eller Bitbucket er det allerede ingen praktisk grunn til å velge RSA for SSH.

Bruce Schneier, en av de mest siterte kryptosikkerhetsekspertene globalt, har i skrifter om kryptografisk agilitet påpekt at enkle primitiver med klare sikkerhetsbevis er å foretrekke fremfor komplekse systemer med mange konfigurasjonsmuligheter der feil valg svekker sikkerheten drastisk. RSA har mange slike konfigurasjonsparametre: nøkkelstørrelse, padding-skjema (PKCS#1 v1.5 vs OAEP vs PSS), hash-algoritme, og ikke minst PRNG-kvalitet. Ed25519 fjerner de fleste av disse variablene.

Anbefalinger for ulike brukstilfeller

Her er direkte anbefalinger fordelt på scenario. Velg algoritme basert på faktiske krav, ikke vane eller det som var standard i 2015.

Brukstilfelle	Anbefalt algoritme	Begrunnelse
Nye SSH-nøkler (personlig)	Ed25519	Raskere, kortere nøkkel, 128-bit sikkerhet. Støttet av alle moderne servere.
Nye SSH-nøkler (bedrift, moderne infrastruktur)	Ed25519	Identisk med personlig bruk. Kun RSA om eldre nettverksenheter krever det.
CI/CD-systemer (GitHub Actions, CircleCI)	Ed25519	1 ms nøkkelgenerering vs 250 ms for RSA-4096, merkbart i container-bootstrap.
TLS-sertifikater (offentlig webserver)	ECDSA P-256	Best nettleserstøtte i 2026. Ed25519 for server-til-server er OK.
TLS-sertifikater (eldre enterprise PKI)	RSA-2048 minimum, RSA-4096 foretrukket	HSM- og compliance-krav tvinger RSA i mange bedriftsinfrastrukturer.
GPG/PGP-nøkkel	Ed25519 + Cv25519	GnuPG 2.1+ anbefaler dette som standardoppsett for signering og kryptering.
Kode-signering (Linux-pakker)	Ed25519	Debian, Arch og Fedora bruker dette.
Kode-signering (Windows Authenticode)	RSA-2048 / ECDSA P-256	Ed25519 støttes ikke av Microsoft CA-er per juni 2026.
JWT-tokens (server-til-server API)	Ed25519 (EdDSA algoritme)	86 tegn signatur i base64url vs 683 tegn for RSA-4096. Reell båndbreddebesparelse.
FIPS 140-2/3-regulerte systemer	RSA-3072 eller ECDSA P-384	Ed25519 er ikke i FIPS-godkjent algoritme-settet.
Post-kvante fremtidssikring	ML-DSA (CRYSTALS-Dilithium)	Hverken Ed25519 eller RSA er kvante-resistente. Begynn planlegging av hybrid implementasjon.

Fordeler og ulemper

Ed25519

Fordeler	Ulemper
~50.000 signaturer per sekund	Ikke FIPS 140-godkjent
128-bit sikkerhet med 256-bit nøkkel	Ikke støttet på SSH-servere fra før 2014
64-byte signaturer (svært kompakte)	Ikke støttet for Windows Authenticode kode-signering
Deterministisk signering (ingen nonce-angrep)	Ikke standard i Java før JDK 15
Nøkkelgenerering på ~1 ms	Begrenset støtte i eldre HSM-maskinvare
Konstant-tid-implementasjon (sidekanal-resistent)	Ikke kvante-resistent
Støttet av Signal, WireGuard, GitHub, GitLab
Batch-verifisering mulig

RSA

Fordeler	Ulemper
Universell kompatibilitet (alle systemer)	RSA-2048 gir bare ~112-bit sikkerhet
FIPS 140-2/3 godkjent	RSA-4096 er ~250x tregere enn Ed25519 på signering
Støttet i Windows Authenticode	Store nøkler og signaturer (512 byte for RSA-4096)
Bredt støttet i PKI og X.509-infrastruktur	Historisk sårbar for padding-oracle-angrep (Bleichenbacher, ROBOT)
Bred HSM-støtte, inkludert eldre modeller	Krever sterk tilfeldighet for sikker signering
RSA-verifisering er rask	Ikke kvante-resistent
	Nøkkelstørrelse må økes over tid etter hvert som beregningskraft vokser

Konklusjonen: hvilket valg gir data grunnlag for?

Dataene peker entydig i én retning: for alle nye implementasjoner der kompatibilitetskrav ikke tvinger RSA, er Ed25519 det riktige valget i 2026. Den er 33 ganger raskere enn RSA-2048 på signering, produserer signaturer som er 75 % kompaktere, genererer nøkler 250 ganger raskere, og eliminerer en hel angrepsklasse gjennom deterministisk design.

RSA er ikke øyeblikkelig farlig i RSA-2048 eller RSA-4096-format. Det er fremdeles akseptabelt for FIPS-regulerte miljøer, Windows Authenticode, og eldre systemer du ikke kan oppgradere. Men det er ikke det du installerer i et nytt system i 2026 uten god grunn.

Den viktigste presiseringen: hverken Ed25519 eller RSA er fremtidssikret mot kvantedatamaskiner. Begge vil til slutt erstattes av post-kvante standarder som ML-DSA. I overgangsfasen er Ed25519 det beste klassiske valget, primært fordi det er enklere å implementere korrekt, gir bedre ytelse, og bringer færre historiske angrepsflater med seg inn i nye systemer. Start planleggingen av hybride post-kvante løsninger nå, men bruk Ed25519 for all klassisk kryptografi frem til de standardene er bredt distribuert i alle protokoller og plattformer du støtter.

For norske virksomheter under NIS2/Digitalsikkerhetsloven: ingen av algoritmene diskvalifiseres per i dag, men NSM og ENISA sin retning mot moderne algoritmer er klar. Ed25519 representerer den retningen i klassisk kryptografi.

Relatert dekning

Disse artiklene utfyller sammenligningen mellom Ed25519 og RSA:

SSH-nøkkel i Linux: sikker innlogging i 10 steg [2026] – Komplett guide til generering, distribusjon og sikring av SSH-nøkler i Linux
Digitale signaturer forklart: hashfunksjoner og asymmetrisk kryptografi – Grunnlaget for asymmetrisk kryptografi og hvordan signaturer faktisk fungerer
HTTPS og TLS 1.3 i Node.js: 12 steg [2026] – Implementer sikker transport med TLS 1.3 og moderne nøkler i Node.js
scrypt Passordhashing i Node.js: 11 Steg – Sikrere passordlagring med moderne hashing-algoritmer
Kryptografi: hashfunksjoner, SHA og digital tillit – Pillarside for kryptografi med oversikt over algoritmer og konsepter

Ofte stilte spørsmål (FAQ)

Er Ed25519 sikrere enn RSA-4096?

For praktiske formål i 2026, ja. Ed25519 gir ~128-bit sikkerhet med en 256-bit nøkkel, tilsvarende sikkerhetsnivå som RSA-3072. RSA-4096 gir noe mer enn 128-bit sikkerhet, men på bekostning av dramatisk lavere ytelse. Strukturelt er Ed25519 mer robust mot implementasjonsfeil på grunn av deterministisk signering og konstant-tid-implementasjoner. Den eneste situasjonen der RSA-4096 er å foretrekke over Ed25519 er i FIPS-regulerte miljøer der FIPS-godkjenning er et absolutt krav.

Støtter GitHub Ed25519 SSH-nøkler?

Ja, fullt ut. GitHub støtter Ed25519 SSH-nøkler. Du legger til nøkkelen under Settings → SSH and GPG keys på github.com. GitLab, Bitbucket, Codeberg og alle store Git-hostingtjenester støtter det tilsvarende. Ed25519 er faktisk det GitHub anbefaler for nye SSH-nøkler i sin offisielle dokumentasjon per 2026.

Kan jeg bruke Ed25519 med GPG / PGP?

Ja, fra GnuPG versjon 2.1 (utgitt 2014). Kommandoen gpg --expert --full-gen-key lar deg velge Ed25519 for signeringsnøkkel og Cv25519 (Curve25519 Diffie-Hellman) for krypteringsnøkkel. Dette er det anbefalte GPG-nøkkeloppsettet for nye nøkler i 2026. Eldre GPG 1.x støtter ikke Ed25519.

Hvilken RSA-nøkkelstørrelse er trygg i 2026?

RSA-2048 er teknisk sett fortsatt trygt i 2026, men gir bare ~112-bit sikkerhet. NIST anbefaler RSA-3072 som minimum for nye implementasjoner med 128-bit sikkerhetsnivå. RSA-2048 planlegges avviklet for mange brukstilfeller etter 2030 i NISTSs retningslinjer. Hvis du bruker RSA, velg RSA-4096 for trygg margin, men vær klar over ytelsesstraffen.

Er Ed25519 kvante-resistent?

Nei. Ed25519 er basert på diskret logaritme over elliptisk kurve, som Shors algoritme på en tilstrekkelig stor kvantedatamaskin kan bryte. Det samme gjelder RSA. For kvante-resistent kryptografi peker NIST til ML-DSA (CRYSTALS-Dilithium) og ML-KEM (CRYSTALS-Kyber), standardisert i august 2024. Ed25519 er det beste valget for klassisk kryptografi i overgangsperioden frem til post-kvante standarder er bredt tilgjengelig.

Hva er forskjellen mellom Ed25519 og ECDSA?

Begge er elliptiske kurve-signatursystemer, men med ulike kurver og signeringsmekanismer. ECDSA (brukt med secp256k1 i Bitcoin og P-256/P-384 i TLS) krever en tilfeldig nonce per signatur og er sårbar hvis tilfeldighetskilden er svak. PlayStation 3 ble kompromittert via nettopp dette. Ed25519 bruker EdDSA og genererer nonce deterministisk, noe som eliminerer den angrepsklassen. Ed25519 er generelt raskere og tryggere å implementere enn ECDSA.

Hva skjer med eksisterende RSA-nøkler?

De forblir gyldige inntil du aktivt tilbakekaller eller sletter dem. Det er ingen grunn til å kaste dem umiddelbart. Anbefalt fremgangsmåte: generer Ed25519-nøkler, distribuer dem til alle servere og tjenester, verifiser at de fungerer, og fjern deretter de gamle RSA-nøklene i en kontrollert prosess. For SSH-servere med mange brukere: kjør inventarskriptet i migreringsguiden over for å identifisere hvem som bruker RSA og kommuniser en migreringsdeadline.

Hva er XEdDSA som Signal bruker?

XEdDSA (Extended EdDSA) er en variant av Ed25519 utviklet av Signal Foundation. Den lar deg bruke Curve25519 Diffie-Hellman-nøkler (brukt i X3DH nøkkelutveksling) til også å produsere EdDSA-signaturer. Dette er nyttig fordi Signal allerede bruker Curve25519-nøkler til kryptering i Double Ratchet-protokollen, og XEdDSA lar de samme nøklene brukes til autentisering uten å generere ekstra nøkkelpar. Det er en elegant løsning som holder nøkkeladministrasjonen minimal.

Ed25519 vs RSA: 33x raskere signaturer, 128-bit sikkerhet [2026]