To elliptiske kurver bærer det meste av kryptovaluta-verdenens signaturtrafikk. secp256k1 sikrer hver Bitcoin- og Ethereum-transaksjon siden 2009, mens Ed25519 driver Solana, Cardano og Monero. Forskjellen handler ikke bare om hvilken blokkjede du bruker. Den handler om signaturstørrelse, hastighet og hvor lett det er å skyte deg selv i foten med en dårlig tilfeldighetsgenerator. Ifølge benchmarks fra Crypto++-biblioteket er Ed25519 20 til 30 ganger raskere enn ECDSA på secp256k1 i klassiske C++-implementasjoner. Samtidig viser en 2026-benchmark med noble/curves i JavaScript at secp256k1 faktisk signerer litt raskere i optimaliserte moderne biblioteker. Denne artikkelen går gjennom tallene, bruksområdene, prisene i skytjenester og maskinvarelommebøker, og hva du bør velge i 2026, uansett om du bygger en ny tjeneste eller vedlikeholder en eksisterende.
Hva er secp256k1 og Ed25519?
secp256k1 er en 256-bit elliptisk Koblitz-kurve definert i Certicoms standard SEC 2 fra 2000. Den ble opprinnelig laget for generell bruk, men fikk sitt store gjennombrudd da Satoshi Nakamoto valgte den til Bitcoin i 2009. Kurven brukes med ECDSA-signaturskjemaet (Elliptic Curve Digital Signature Algorithm), og siden 2021 også med Schnorr-signaturer gjennom Bitcoins Taproot-oppgradering (BIP-340). Ethereum har brukt secp256k1 for kontosignaturer siden lanseringen i 2015, og de fleste EVM-kompatible kjeder har arvet samme valg.
Ed25519 er en implementasjon av EdDSA (Edwards-curve Digital Signature Algorithm) på en twisted Edwards-kurve kalt Curve25519. Den ble designet av Daniel J. Bernstein og medforfattere, og beskrevet i papiret “High-speed high-security signatures” fra 2011. Skjemaet ble senere standardisert av IETF i RFC 8032. Ed25519 ble bygget fra bunnen av for å unngå klassiske implementasjonsfeil i ECDSA, og det gjenspeiles i designvalgene: faste signaturstørrelser, deterministisk noncegenerering og innebygd støtte for batch-verifisering.
Hvorfor heter kurvene det de heter?
Navnet secp256k1 er ikke tilfeldig valgt. Det følger navnekonvensjonen i Certicoms SEC 2-standard: “sec” for Standards for Efficient Cryptography, “p” for at kurven er definert over et primtallsfelt (prime field), “256” for nøkkellengden i bit, “k” for at det er en Koblitz-kurve, og “1” fordi den er den første slike kurven i settet. Koblitz-kurver har spesielle algebraiske egenskaper som gjør enkelte regneoperasjoner raskere, noe som var attraktivt for tidlige smartkort- og innebygde systemer lenge før Bitcoin fantes.
Ed25519 er oppkalt mer direkte: “Ed” for Edwards-kurve og “25519” for primtallet 2^255 – 19, som definerer det underliggende feltet kurven opererer over. Samme tallkonstruksjon gjenfinnes i Curve25519, som brukes til nøkkelutveksling (X25519), mens Ed25519 er signaturvarianten bygget på den beslektede twisted Edwards-formen av samme kurve. Begge ble beskrevet av Daniel J. Bernstein, som også står bak en rekke andre mye brukte kryptografiske primitiver, deriblant ChaCha20-strømchifferet.
Matematisk oppbygning: Weierstrass mot Edwards-kurver
secp256k1 er en short Weierstrass-kurve, definert av likningen y² = x³ + 7 over et primtallsfelt. Denne kurveformen er den klassiske standarden i kryptografi, men punktaddisjon på en Weierstrass-kurve krever spesialtilfeller (blant annet når to punkter er like eller motsatte), noe som gjør implementasjonen mer sårbar for feil og sidekanalangrep hvis den ikke gjøres riktig.
Ed25519 bruker en twisted Edwards-kurve, hvor punktaddisjon er “komplett”: samme formel fungerer for alle punktpar uten spesialtilfeller. Det gjør det vesentlig vanskeligere å introdusere sidekanalsårbarheter ved et uhell. En studie på Bitcoin-sikkerhet med twisted Edwards-kurver, publisert i akademiske kanaler i 2024-2025, peker på at aritmetikk på CurveEd25519 krever rundt 7 feltmultiplikasjoner per nøkkeloperasjon, mot rundt 12 for secp256k1. Det er en direkte forklaring på hvorfor Ed25519 vinner de fleste rå ytelsestester. Analyseprosjektet SafeCurves, som vurderer elliptiske kurver mot en liste av kjente designfeil, rangerer Curve25519/Ed25519 gjennomgående bedre enn secp256k1 på kriterier knyttet til implementasjonssikkerhet, selv om begge oppfyller kravene til grunnleggende diskret-logaritme-sikkerhet.
Nøkkel- og signaturstørrelser sammenlignet
Den mest praktiske forskjellen mellom kurvene handler om hvor mange byte du må lagre og overføre. Ed25519 har faste, forutsigbare størrelser. secp256k1-signaturer bruker DER-koding og varierer noe i lengde, noe som kompliserer parsing i visse implementasjoner. Tabellen under oppsummerer de viktigste tekniske parameterne.
| Egenskap | secp256k1 | Ed25519 |
|---|---|---|
| Kurvetype | Short Weierstrass | Twisted Edwards |
| Sikkerhetsnivå | ~128-bit | ~128-bit (2^125,8 konservativt, DJB) |
| Offentlig nøkkel (komprimert) | 33 byte | 32 byte |
| Offentlig nøkkel (ukomprimert) | 65 byte | Finnes ikke, alltid komprimert |
| Privat nøkkel / seed | 32 byte | 32-byte seed |
| Signaturstørrelse | ~70-72 byte (DER, variabel) | 64 byte (fast) |
| Signaturskjema | ECDSA, samt Schnorr (BIP-340) | EdDSA (RFC 8032) |
| Noncegenerering | Krever sikker RNG per signatur | Deterministisk, avledet fra nøkkel og melding |
| Batch-verifisering | Begrenset (Schnorr støtter det, ECDSA ikke) | Innebygd støtte |
| Feltmultiplikasjoner per operasjon | ~12 | ~7 |
| Standardisert i | SEC 2 (Certicom, 2000) | RFC 8032 (IETF, 2015) |
| Bruk i SSH | ecdsa-sha2-nistp256/384/521 (sjeldnere brukt) | ssh-ed25519 (støttet siden OpenSSH 6.5, 2014) |
| Kjent svakhetsklasse | Signaturmalleability, RNG-avhengighet | Ingen kjent nonce-relatert svakhet |
68-72 byte offentlig nøkkel pluss variabel signatur høres kanskje ikke ut som mye, men multiplisert med millioner av transaksjoner blir forskjellen målbar i lagringsplass og båndbredde. En SSH-nøkkelsammenligning fra 2026 viser at Ed25519 gir omtrent 68 byte offentlig nøkkel i SSH-format mot rundt 91 byte for ECDSA P-256/secp256k1, inkludert format-overhead.
Ytelse: signering og verifisering i praksis
Benchmarktall for elliptiske kurver varierer kraftig med implementasjon, prosessor og optimaliseringsnivå. Derfor er det viktig å se på flere uavhengige kilder i stedet for ett enkelt tall. Under er tre kilder som gir et bredere bilde.
| Kilde | Plattform | secp256k1/secp256r1 | Ed25519 |
|---|---|---|---|
| Crypto++ wiki | Intel Core i5-6400 @ 2,7 GHz | Signering: 0,515 ms/op (~1 940 op/s). Verifisering: 1,805 ms/op (~554 op/s) | Signering: 0,018 ms/op (~55 000 op/s). Verifisering: 0,049 ms/op (~20 400 op/s) |
| Crypto++ wiki | ARMv8 Cortex-A53 @ 1,2 GHz | Signering: 5,420 ms/op (~184 op/s). Verifisering: 16,393 ms/op (~61 op/s) | Signering: 0,213 ms/op (~4 690 op/s). Verifisering: 0,541 ms/op (~1 850 op/s) |
| noble/curves (JS, 2026) | Moderne Node.js-runtime | Signering: 7 182 op/s (139 μs). Verifisering: 1 188 op/s (841 μs) | Signering: 6 849 op/s (145 μs). Verifisering: 1 400 op/s (713 μs) |
| Bernstein et al., originalpaper | Referansemaskinvare, 2011 | Ikke oppgitt | Signering: ~100 000 meldinger/sek. Verifisering: ~71 000 signaturer/sek |
Bildet er ikke entydig. Crypto++-tallene viser en forskjell på 20-30 ganger i Ed25519s favør, og det stemmer med at kurven krever færre feltmultiplikasjoner. Men noble/curves-benchmarken fra 2026, kjørt i samme JavaScript-kodebase for begge kurvene, viser at secp256k1 faktisk signerer rundt 5 prosent raskere enn Ed25519 i den implementasjonen, mens Ed25519 verifiserer omtrent 18 prosent raskere. Konklusjonen er at moderne, godt optimaliserte biblioteker jevner ut mye av den historiske ytelsesforskjellen. Den store fordelen for Ed25519 ligger ikke nødvendigvis i rå hastighet på toppmoderne maskinvare, men i eldre eller ressursbegrenset maskinvare (som ARM-brikker i IoT-enheter), hvor forskjellen fortsatt er stor.
ARMv8 Cortex-A53-tallene fra Crypto++ illustrerer poenget godt: der Ed25519 signerer på 0,213 millisekund, bruker secp256k1/secp256r1 hele 5,42 millisekund, en faktor på over 25. På en server med rikelig CPU-kraft merkes ikke forskjellen i praksis for enkeltsignaturer, men på en billig IoT-enhet, en smarttelefon som validerer mange signaturer i bakgrunnen, eller en validator-node som skal verifisere tusenvis av transaksjoner per sekund, blir forskjellen fort avgjørende for hvilken maskinvare man i det hele tatt trenger å kjøpe inn.
Sikkerhetsnivå og designfilosofi
Begge kurvene regnes som å gi omtrent 128-bit klassisk sikkerhet, på linje med AES-128 og RSA-3072. Ingen praktisk angrep har brutt selve den matematiske hardheten i noen av kurvene siden de ble tatt i bruk. NIST FIPS 186-5, den gjeldende standarden for digitale signaturer, godkjenner både Edwards-kurve-baserte skjemaer (EdDSA) og klassisk ECDSA for føderal bruk i USA, noe som i praksis legitimerer begge tilnærmingene på myndighetsnivå.
Det finnes likevel en nyanseforskjell i hvordan sikkerhetsmarginen regnes. Bernstein og medforfatterne bruker et konservativt anslag på 2^125,8 operasjoner for å bryte Ed25519, litt under det runde 128-bit-tallet man ofte ser referert. secp256k1s sikkerhetsmargin regnes tradisjonelt som ren 128-bit basert på kurvens gruppeorden. I praksis er forskjellen null i noen reell forstand: begge tallene er så store (over 10^37) at ingen tenkelig datamaskin, klassisk eller kvante innen overskuelig fremtid, kommer i nærheten av å knekke dem gjennom brute force. Forskjellen er akademisk presisjon, ikke et praktisk sikkerhetsproblem for noen av kurvene.
Forskjellen ligger i designfilosofi. secp256k1 ble laget for generell ECC-bruk før Bitcoin fantes, og ECDSA-skjemaet som brukes sammen med den stiller strenge krav til hvordan en implementasjon håndterer den hemmelige nonce-verdien k for hver signatur. Ed25519 ble designet spesifikt for å eliminere denne klassen av feil ved å gjøre nonce-genereringen deterministisk: den avledes fra en hash av privatnøkkelen og meldingen, ikke fra en ekstern tilfeldighetskilde. Det gjør Ed25519 til det kryptografer kaller et “misbruksresistent” design, altså et skjema som er vanskeligere å implementere feil, ikke bare matematisk sterkere.
Kjente svakheter: noncegjenbruk og signaturmalleability
ECDSA på secp256k1 har en velkjent akilleshæl: hvis den samme nonce-verdien k gjenbrukes for to forskjellige signaturer med samme privatnøkkel, kan en angriper regne ut privatnøkkelen direkte fra de to signaturene. Dette er ikke en teoretisk risiko. Svake eller forutsigbare tilfeldighetsgeneratorer i enkelte Android Bitcoin-lommebøker i 2013 førte til reelle tap av midler fordi nonce-verdier ble gjenbrukt eller delvis forutsigbare. Problemet ligger ikke i selve secp256k1-kurven, men i hvor mye implementasjonen er avhengig av en korrekt fungerende RNG for hver eneste signatur.
secp256k1-signaturer hadde også historisk et malleability-problem: samme signatur kunne representeres på flere gyldige måter (blant annet fordi (r, s) og (r, -s mod n) begge er gyldige), noe som gjorde det mulig å endre en transaksjons-ID uten å ugyldiggjøre signaturen. Bitcoin løste dette gradvis gjennom BIP-62 og senere fullstendig med SegWit i 2017. Ed25519 unngår denne klassen av problemer fordi EdDSA-signaturer er strengere definert, med faste byte-representasjoner og ingen tilsvarende tvetydighet i kodingen.
Et institusjonelt lommebok-selskap som Cobo har i sin 2025-sammenligning av kurvene plassert implementasjonsrisiko som “høyere” for secp256k1 og “lavere” for Ed25519, nettopp med henvisning til den deterministiske noncehåndteringen. Det betyr ikke at secp256k1 er usikker når den implementeres riktig. Bitcoin Core og de fleste seriøse lommebokbiblioteker bruker deterministiske ECDSA-varianter (RFC 6979) nettopp for å eliminere denne risikoen manuelt, siden ECDSA-standarden selv ikke krever det.
RFC 6979 løser problemet ved å avlede nonce-verdien deterministisk fra privatnøkkelen og meldingen, akkurat slik EdDSA gjør fra starten. Forskjellen er at det er valgfritt for secp256k1/ECDSA-implementasjoner, mens det er obligatorisk i Ed25519-spesifikasjonen. Bitcoin Core, Ethereums go-ethereum-klient og de fleste moderne lommebokbiblioteker har alle adoptert RFC 6979 som standard i dag, noe som i praksis lukker mye av gapet mellom kurvene på nettopp dette punktet. Eldre eller mindre reviderte biblioteker kan likevel fortsatt mangle denne beskyttelsen, og det er nettopp her forskjellen i design mellom de to skjemaene får praktisk betydning.
Kodeeksempel: nøkkelgenerering og signering
Den praktiske forskjellen mellom de to kurvene blir tydelig når man ser på faktisk kode. Under er to minimale eksempler i Node.js med biblioteket @noble/curves, som implementerer begge kurvene i samme kodebase og dermed egner seg godt til direkte sammenligning.
// secp256k1 med @noble/curves
import { secp256k1 } from '@noble/curves/secp256k1';
const privateKey = secp256k1.utils.randomPrivateKey();
const publicKey = secp256k1.getPublicKey(privateKey);
const message = new TextEncoder().encode('hei shattered.io');
const messageHash = await crypto.subtle.digest('SHA-256', message);
const signature = secp256k1.sign(new Uint8Array(messageHash), privateKey);
const isValid = secp256k1.verify(signature, new Uint8Array(messageHash), publicKey);
console.log('Offentlig nøkkel:', publicKey.length, 'byte');
console.log('Signatur:', signature.toCompactRawBytes().length, 'byte');
console.log('Gyldig:', isValid);// Ed25519 med @noble/curves
import { ed25519 } from '@noble/curves/ed25519';
const privateKey = ed25519.utils.randomPrivateKey();
const publicKey = ed25519.getPublicKey(privateKey);
const message = new TextEncoder().encode('hei shattered.io');
// Ingen separat hash nødvendig, Ed25519 signerer rå meldingen direkte
const signature = ed25519.sign(message, privateKey);
const isValid = ed25519.verify(signature, message, publicKey);
console.log('Offentlig nøkkel:', publicKey.length, 'byte');
console.log('Signatur:', signature.length, 'byte');
console.log('Gyldig:', isValid);Legg merke til to praktiske forskjeller i koden selv. secp256k1-eksempelet må først hashe meldingen manuelt med SHA-256 før signering, mens Ed25519 tar imot den rå meldingen direkte og håndterer hashing internt som en del av signaturskjemaet (RFC 8032 bruker SHA-512). Det gjør Ed25519-koden noe kortere og fjerner en potensiell feilkilde: en utvikler kan i teorien hashe meldingen med feil algoritme eller glemme det helt i en secp256k1-implementasjon, noe som er strukturelt umulig med Ed25519. Ferdig kompilert vil publicKey.length alltid være 32 for Ed25519, mens secp256k1 returnerer 33 byte i komprimert format, akkurat som tabellen tidligere i artikkelen viser.
Utviklerbiblioteker: hvor moden er økosystemet?
Modenheten til biblioteker og verktøy rundt hver kurve er minst like viktig som selve kryptografien når man skal velge i praksis. Begge kurvene har i dag flere reviderte, produksjonsklare implementasjoner på tvers av de vanligste språkene.
| Språk/plattform | secp256k1-bibliotek | Ed25519-bibliotek |
|---|---|---|
| JavaScript/TypeScript | @noble/curves, elliptic.js | @noble/curves, tweetnacl |
| Python | coincurve (bindinger mot libsecp256k1) | PyNaCl (libsodium-bindinger) |
| Rust | secp256k1-crate (Bitcoin Core-bindinger) | ed25519-dalek |
| Go | btcec, go-ethereum/crypto/secp256k1 | golang.org/x/crypto/ed25519 (standardbibliotek) |
| C/C++ | libsecp256k1 (Bitcoin Core) | libsodium, ref10 |
| Blokkjede-spesifikt | ethers.js, web3.py (Ethereum) | @solana/web3.js (Solana) |
libsecp256k1 fra Bitcoin Core regnes som referanseimplementasjonen for secp256k1 og brukes langt utenfor Bitcoin selv, blant annet i Ethereum-klienter. På Ed25519-siden er libsodium det mest brukte biblioteket på tvers av språk, mens ed25519-dalek er standardvalget i Rust-økosystemet og brukes blant annet i Solana-validatorkoden. Ingen av kurvene har et modenhetsproblem i 2026: begge har flere uavhengige, revidert implementasjoner i alle større programmeringsspråk, så biblioteksstøtte er sjelden den avgjørende faktoren i valget.
Et unntak er edge-tilfeller i signaturvalidering. Sikkerhetsforsker Henry de Valence dokumenterte i 2020 hvordan ulike Ed25519-biblioteker historisk validerte signaturer forskjellig i grensetilfeller, blant annet rundt hvorvidt en S-verdi måtte være “kanonisk” kodet. Det kunne i verste fall føre til at to noder i et distribuert system var uenige om hvorvidt en signatur var gyldig, en konsensusrisiko for blokkjeder. Detaljene er beskrevet i “It’s 255:19am”, og problemet er siden adressert i de fleste moderne biblioteker gjennom strengere, standardiserte valideringsregler (ZIP-215 og lignende spesifikasjoner). Poenget er ikke at Ed25519 er farligere enn secp256k1, men at selv “enkle” kryptografiske primitiver kan ha overraskende kanttilfeller når mange uavhengige implementasjoner skal være enige.
Batch-verifisering og skaleringsfordeler
Batch-verifisering lar en server sjekke mange signaturer samtidig med lavere total regnekraft enn å verifisere dem én og én. Ed25519 støtter dette som en innebygd egenskap av designet, og det er en direkte årsak til at høyfrekvente blokkjeder som Solana bruker kurven. Når et Solana-nettverk skal validere titusenvis av transaksjoner i sekundet, betyr batch-verifisering en reell forskjell i hvor mange noder som kan holde tritt med nettverket.
Ren ECDSA på secp256k1 har mer begrenset støtte for batch-verifisering. Bitcoins Schnorr-signaturer (BIP-340), som også bruker secp256k1 som underliggende kurve men et annet signaturskjema, støtter derimot batch-verifisering på samme måte som Ed25519. Det illustrerer et viktig poeng: mye av ytelsesforskjellen handler like mye om signaturskjemaet (ECDSA mot Schnorr mot EdDSA) som om selve kurven. Bitcoin beholder secp256k1 som kurve, men har beveget seg mot Schnorr nettopp for å hente ut noen av de samme fordelene Ed25519 har hatt fra starten.
For en node eller validator som må verifisere tusenvis av signaturer i en enkelt blokk, betyr batch-verifisering i praksis at total CPU-tid ikke skalerer lineært med antall signaturer. I stedet for å utføre full punktmultiplikasjon for hver enkelt signatur, kan flere signaturer kombineres i én felles sjekk med tilfeldige vekter, noe som reduserer det totale antallet dyre kurveoperasjoner betraktelig. Dette er spesielt verdifullt for høyfrekvente nettverk der validering skjer under tidspress, og er en av de tekniske forklaringene på hvorfor Ed25519-baserte kjeder som Solana kan love vesentlig høyere transaksjoner-per-sekund enn secp256k1-baserte kjeder som fortsatt kjører ren ECDSA.
Hvem bruker secp256k1? Bitcoin, Ethereum og EVM-kjeder
secp256k1 er trolig den mest brukte elliptiske kurven i offentlige blokkjeder målt i transaksjonsvolum, rett og slett fordi Bitcoin og Ethereum begge bygger på den.
- Bitcoin har brukt ECDSA på secp256k1 for transaksjonssignaturer siden nettverket startet i januar 2009. Taproot-oppgraderingen i november 2021 la til Schnorr-signaturer (BIP-340), fortsatt på samme kurve, for å hente ut batch-verifisering og bedre personvern.
- Ethereum har brukt secp256k1 for kontosignaturer siden Genesis-blokken i juli 2015, dokumentert i protokollens gule papir og i klientimplementasjoner.
- EVM-kompatible kjeder, inkludert de fleste Layer 2-løsninger og sidekjeder bygget på Ethereums virtuelle maskin, arver secp256k1 for å opprettholde adressekompatibilitet med Ethereum-lommebøker.
- Bitcoin Core-referanseimplementasjonen av secp256k1 er open source og ligger på GitHub, hvor den også brukes av en rekke andre prosjekter som trenger en konstant-tid, revidert secp256k1-implementasjon.
Valget av secp256k1 for disse nettverkene er i praksis låst fast. Å bytte kurve på et etablert nettverk med milliarder av dollar i verdi ville kreve en hard fork og ville ugyldiggjøre eksisterende adresser og signaturlogikk. Forskning på Bitcoin-sikkerhet med twisted Edwards-kurver fra 2024-2025 argumenterer for at Ed25519-lignende kurver ville gitt bedre robusthet, men dette er akademisk forskning, ikke en vedtatt endring. Bitcoin-nettverket bruker fortsatt secp256k1 ECDSA og Schnorr i 2026.
Verdien som er sikret av secp256k1 strekker seg også langt utenfor selve valutaene. Smartkontrakter, DeFi-protokoller, NFT-eierskap og token-standarder på Ethereum og EVM-kompatible kjeder signeres alle med samme kurve, siden alt handler om å signere transaksjoner fra en Ethereum-adresse. Enhver lommebok, børs eller depottjeneste som håndterer Bitcoin eller et EVM-aktivum må derfor implementere secp256k1 korrekt, uansett hvilke andre kurver de eventuelt støtter i tillegg for andre nettverk.
Hvem bruker Ed25519? Solana, Cardano, Monero, SSH og Signal
Ed25519 har blitt standardvalget i mye nyere infrastruktur, spesielt der signeringshastighet, deterministisk sikkerhet eller batch-verifisering veier tungt.
- Solana bruker Ed25519 for kontonøkler og transaksjonssignaturer. Den innebygde batch-verifiseringen er en direkte medvirkende faktor til nettverkets høye gjennomstrømning av transaksjoner.
- Cardano bruker Ed25519/Curve25519-baserte nøkler og signaturer i sin Ouroboros proof-of-stake-protokoll for både blokkproduksjon og transaksjonssignering.
- Monero bygger på EdDSA-konstruksjoner over Edwards/Curve25519-familien for konto- og ringsignaturer, som er sentrale i nettverkets personvernmodell.
- OpenSSH la til støtte for ssh-ed25519-nøkler i versjon 6.5 i 2014, dokumentert i utgivelsesnotatene, og nøkkeltypen har siden blitt et vanlig anbefalt valg i mange Linux-distribusjoner og skyplattformer fremfor RSA og eldre ECDSA-varianter.
- Signal og lignende sikre meldingsprotokoller bruker Ed25519 for identitetsnøkler og signering av meldinger i sine kryptografiske protokoller.
- TLS og X.509 fikk formell støtte for Ed25519 og Ed448 gjennom RFC 8709, som integrerer algoritmene i sertifikater og TLS 1.3-håndtrykk.
Fellesnevneren for disse eksemplene er at de alle er nyere prosjekter eller standarder, bygget etter at Ed25519 var tilgjengelig og godt dokumentert. Ingen av dem hadde en eksisterende brukerbase å ta hensyn til, slik Bitcoin og Ethereum har, og kunne derfor velge fritt basert på tekniske egenskaper alene.
Det er verdt å presisere at Ed25519 ikke er begrenset til blokkjeder eller infrastruktur. RFC 8032-spesifikasjonen definerer algoritmen som en generell signaturprimitiv, og den dukker opp i alt fra pakkesignering i Linux-distribusjoner til autentisering i moderne API-rammeverk. Når et team i 2026 vurderer en ny signeringsmekanisme uten eksisterende bindinger, er Ed25519 ofte forvalget nettopp fordi det er godt dokumentert, bredt implementert og fritt for de historiske implementasjonsfellene som har plaget ECDSA.
Pris og støtte i skytjenester: AWS, Google Cloud og Azure
For utviklere som ikke bygger blokkjeder, men trenger signeringsnøkler i skyen, varierer kurvestøtten mellom leverandørene mer enn man skulle tro. Azure Key Vault støtter for eksempel secp256k1 (kalt P-256K i Microsofts dokumentasjon), men har ikke Ed25519 dokumentert som støttet nøkkeltype per 2026.
| Tjeneste | secp256k1 | Ed25519 | Pris per nøkkel/mnd | Pris per 10 000 signeringer |
|---|---|---|---|---|
| AWS KMS | Ja (ECC_SECG_P256K1) | Ja (ECC_NIST_EDWARDS25519) | $1,00 | $0,15 (asymmetrisk) |
| AWS CloudHSM | Ja | Ja (PureEdDSA, hsm2m.medium) | Timepris $1,60/HSM | Inkludert i timepris |
| Google Cloud KMS (software) | Ja (EC_SIGN_SECP256K1_SHA256) | Ja (EC_SIGN_ED25519) | $0,06 | $0,03 |
| Azure Key Vault (Premium/HSM) | Ja (P-256K) | Ikke dokumentert støttet | $5,00 (ECC HSM, første 250 nøkler) | $0,03 |
| HashiCorp Vault (Transit) | Nei i standard TSE-integrasjon | Ja (Ed25519ph/PureEd25519) | Gratis (selvhostet) | Ikke relevant |
Tallene, hentet fra AWS KMS-dokumentasjonen, Google Cloud KMS-algoritmelisten og Azure Key Vault-dokumentasjonen, viser at AWS og Google prissetter operasjonene likt uavhengig av hvilken kurve du velger. Azure er det store unntaket: her må teamet enten bruke secp256k1 eller bytte leverandør hvis Ed25519 er et hardt krav, noe som er verdt å sjekke tidlig i en arkitekturbeslutning.
For team med høyt signeringsvolum er kostnadsforskjellen mellom leverandørene mer betydelig enn forskjellen mellom kurvene. AWS KMS tar $0,15 per 10 000 asymmetriske operasjoner, fem ganger så mye som Google Cloud KMS sine $0,03, uavhengig av om du bruker secp256k1 eller Ed25519. For et system som signerer titalls millioner ganger i måneden utgjør det reelle summer, og valget av skyleverandør bør derfor vurderes sammen med, ikke isolert fra, valget av kurve. Selvhostet HashiCorp Vault fjerner riktignok per-operasjon-kostnaden helt, men da må teamet selv ta ansvar for drift, oppetid og sikkerhetsoppdateringer av HSM-laget.
Maskinvarelommebøker: hvilke enheter støtter hva
De fleste populære maskinvarelommebøker støtter begge kurvene, med ett viktig unntak for rendyrkede Bitcoin-enheter.
| Enhet | secp256k1 | Ed25519 | Pris (2026) |
|---|---|---|---|
| Ledger Nano S Plus | Ja | Ja | ~$79 |
| Ledger Flex | Ja | Ja | ~$249 |
| Trezor Safe 3 | Ja | Ja | ~$59 |
| Trezor Safe 5 | Ja | Ja | ~$129 |
| Coldcard Mk4 | Ja (Bitcoin-only) | Ikke støttet | ~$157-178 |
| Keystone 3 Pro | Ja | Ikke dokumentert | ~$149 |
Ledger og Trezor er begge generelle multi-mynt-lommebøker og har derfor bygget inn støtte for begge kurvetypene i firmware, dokumentert i deres respektive kryptografibiblioteker. Coldcard er bevisst designet som en Bitcoin-only-enhet med dobbel sikker element, og har derfor ikke behov for å støtte Ed25519 i det hele tatt. Hvis porteføljen din inkluderer både Bitcoin/Ethereum og Solana/Cardano, må du enten velge en enhet som støtter begge kurvetypene, eller bruke separate lommebøker for hver kurvetype.
Fem eksempler fra virkeligheten
Teori er én ting, men det er lettere å forstå valget mellom kurvene gjennom konkrete tilfeller der en av dem allerede har blitt satt på prøve i produksjon.
- Bitcoins Taproot-oppgradering (2021) beholdt secp256k1 som kurve, men byttet fra ren ECDSA til Schnorr-signaturer nettopp for å få batch-verifisering og enklere multisignatur-konstruksjoner, uten å måtte forlate en kurve med over ti års produksjonshistorikk.
- Solanas gjennomstrømning avhenger delvis av at Ed25519-verifisering kan batches effektivt på validatornoder, noe som er en direkte konsekvens av at nettverket ble designet fra 2017 og fremover med Ed25519 som utgangspunkt, ikke lagt til i etterkant.
- OpenSSH sitt skifte til Ed25519 som anbefalt standard fra og med versjon 6.5 i 2014 er et av de klareste eksemplene på en bevisst migrasjon bort fra RSA og ECDSA, drevet av mindre nøkler og enklere, tryggere implementasjon.
- Androids Bitcoin-lommebok-hendelse i 2013, hvor en svak tilfeldighetsgenerator i Androids kryptografi-API førte til gjenbrukte ECDSA-noncer og tap av midler, er fortsatt det mest siterte eksempelet på hvorfor deterministisk noncehåndtering (som Ed25519 har innebygd) er verdifullt.
- Institusjonelle depottjenester som Cobo har i egne sammenligninger fra 2025 pekt på Ed25519 som det tryggere standardvalget for nye interne signeringssystemer, samtidig som de fortsatt må støtte secp256k1 for kundenes Bitcoin- og Ethereum-beholdninger.
Migreringsguide: fra secp256k1 til Ed25519
Hvis du bygger et nytt system, eller vurderer å legge til Ed25519-støtte ved siden av en eksisterende secp256k1-løsning (for eksempel for interne API-nøkler eller SSH-tilgang), er dette stegene som reduserer risikoen for feil underveis.
- Kartlegg alle steder secp256k1 brukes, inkludert biblioteker, KMS-nøkler, SSH-nøkler og eventuelle harde avhengigheter til blokkjeder som krever nettopp den kurven.
- Sjekk om noen avhengigheter er låst til secp256k1, for eksempel Bitcoin- eller Ethereum-adresser, som ikke kan byttes uten å miste tilgang til eksisterende midler.
- Bekreft bibliotek- og plattformstøtte for Ed25519 i alle komponenter, siden enkelte tjenester (som vist i Azure-eksempelet over) mangler støtte helt.
- Generer nye Ed25519-nøkkelpar med et revidert bibliotek som libsodium, noble-curves eller det innebygde Ed25519-API-et i språket ditt.
- Oppdater signerings- og verifiseringskoden til å håndtere de faste 32/64-byte-formatene, som er enklere å validere enn variabel DER-koding.
- Kjør parallell signering i en overgangsperiode, der begge nøkkeltyper er gyldige samtidig, slik at eksisterende klienter ikke brytes.
- Test interoperabilitet mot alle nedstrøms systemer, inkludert eventuelle tredjeparts-API-er som forventer et spesifikt signaturformat.
- Fjern secp256k1-nøkler gradvis først etter at alle klienter og systemer er bekreftet kompatible med Ed25519, og behold en revisjonslogg for hele overgangen.
Legg merke til at dette er en migrering for infrastruktur du selv kontrollerer, som SSH-tilgang, interne API-nøkler eller KMS-oppsett. Det finnes ingen praktisk vei til å migrere en etablert blokkjede som Bitcoin fra secp256k1 til Ed25519 uten en full hard fork, og ingen store nettverk har varslet en slik plan i 2026.
Fordeler og ulemper
Ingen av kurvene er objektivt “best” i alle situasjoner, og en oppsummering av styrker og svakheter gjør det lettere å se hvilken som passer for akkurat ditt prosjekt. Vurderingen under bygger på de tekniske forskjellene, benchmarkene og bruksmønstrene beskrevet tidligere i artikkelen.
secp256k1
- Fordeler: Uunnværlig for Bitcoin- og Ethereum-kompatibilitet, 25 år gammel med bred verktøystøtte, revidert i produksjon i over et tiår, støttes av alle store maskinvarelommebøker og de fleste sky-KMS-tjenester inkludert Azure.
- Ulemper: Variabel signaturstørrelse gir mer kompleks parsing, ECDSA krever en sikker RNG for hver signatur, historisk signaturmalleability måtte løses separat, og biblioteker uten deterministisk nonce (RFC 6979) er sårbare for noncegjenbruk.
Ed25519
- Fordeler: Faste, kompakte 32/64-byte formater, deterministisk noncegenerering eliminerer en hel klasse av implementasjonsfeil, innebygd batch-verifisering, raskere i de fleste klassiske benchmarks, og standardisert gjennom IETF i RFC 8032.
- Ulemper: Ikke støttet i Azure Key Vault per 2026, ikke brukt av Bitcoin eller Ethereum så du kan ikke bruke det til å signere for disse nettverkene, og noe mindre universelt støttet i eldre bedriftsverktøy enn den mer etablerte secp256k1.
Bruksanbefalinger: når velge hvilken kurve
Basert på alt gjennomgått over, her er de konkrete anbefalingene for de vanligste scenarioene et utviklerteam møter i 2026.
- Bygger du en Bitcoin- eller Ethereum-lommebok? secp256k1 er obligatorisk, det finnes ikke noe alternativ siden nettverkene selv krever det.
- Bygger du en ny Layer 1-blokkjede fra bunnen av? Ed25519 gir bedre gjennomstrømning via batch-verifisering, slik Solana har vist i praksis.
- Setter du opp SSH-nøkler for servere? Ed25519 er anbefalt standard siden 2014 og gir mindre, raskere og enklere nøkler enn RSA eller ECDSA.
- Trenger du enterprise-KMS med Azure Key Vault? secp256k1 (P-256K) er det eneste alternativet av de to, siden Ed25519 mangler dokumentert støtte der.
- Bygger du høyfrekvent API-autentisering eller mikrotjenester som signerer mye? Ed25519s deterministiske design og batch-verifisering gjør det til et tryggere og ofte raskere valg enn ECDSA.
- Trenger porteføljen din multi-kurve maskinvarestøtte? Ledger og Trezor dekker begge kurvene i samme enhet, mens Coldcard krever et eget Bitcoin-only-oppsett.
Kvantetrussel og fremtidsutsikter
Verken secp256k1 eller Ed25519 er motstandsdyktige mot en tilstrekkelig stor kvantedatamaskin. Begge er sårbare for Shors algoritme, som i teorien kan bryte den underliggende diskret-logaritme-problemstillingen på elliptiske kurver. Dette gjelder likt for begge kurvene, så valget mellom dem løser ikke kvanteproblemet i noen retning. NIST har allerede standardisert postkvante-alternativer som ML-DSA og SLH-DSA for digitale signaturer, men disse har betydelig større nøkkel- og signaturstørrelser enn både secp256k1 og Ed25519, og migreringen til dem er en helt egen prosess uavhengig av hvilken klassisk kurve man bruker i dag.
For de fleste team i 2026 er kvantetrusselen ikke en grunn til å velge en klassisk kurve fremfor den andre. Den er derimot en grunn til å bygge kryptoagilitet inn i systemet fra starten, slik at en fremtidig overgang til postkvante-signaturer ikke krever en fullstendig omskriving av signeringslogikken.
Bitcoin-miljøet diskuterer allerede egne forslag for å håndtere en fremtidig kvantetrussel mot secp256k1-baserte midler, deriblant ideer om å fryse eller migrere gamle, eksponerte offentlige nøkler før en kvantedatamaskin blir kraftig nok til å true dem. Solana og andre Ed25519-baserte nettverk står overfor akkurat samme grunnleggende problem, siden Curve25519 heller ikke er postkvante-sikker. Ingen av økosystemene har i 2026 gjennomført en fullstendig overgang til postkvante-signaturer, og begge kurvene bør derfor betraktes som et mellomsteg, ikke et endepunkt, i et lengre sikkerhetsperspektiv.
Konklusjon: hvilken kurve vinner i 2026?
Det finnes ikke ett riktig svar, og tallene i denne artikkelen viser hvorfor. Ed25519 vinner på implementasjonssikkerhet takket være deterministisk noncegenerering, vinner på kompakthet med faste 64-byte signaturer mot secp256k1s variable 70-72 byte, og vinner på klassiske benchmarks med opptil 20-30 ganger høyere gjennomstrømning ifølge Crypto++. Men i en moderne, godt optimalisert JavaScript-implementasjon fra 2026 var secp256k1 faktisk raskere til å signere, ifølge noble/curves-tallene, noe som viser at rå hastighet ikke lenger er et automatisk argument for Ed25519.
secp256k1 vinner der det faktisk teller mest for millioner av brukere: kompatibilitet. Bitcoin og Ethereum representerer i praksis all verdi som i dag er sikret med elliptisk kurve-kryptografi i offentlige blokkjeder, og ingen av dem bytter kurve med det første. Hvis du bygger noe nytt uten historiske bindinger, som SSH-infrastruktur, interne signeringssystemer eller en ny blokkjede, peker både sikkerhetsdesign og de fleste ytelsestall mot Ed25519. Hvis du derimot må snakke med eksisterende Bitcoin- eller Ethereum-infrastruktur, er secp256k1 ikke et valg, det er et krav.
Den mest ærlige oppsummeringen er derfor at spørsmålet “hvilken kurve er best” er feil spørsmål. Det riktige spørsmålet er hvilke systemer du allerede må snakke med. For team som starter helt på nytt uten den bindingen, gir Ed25519 i 2026 den beste kombinasjonen av kompakthet, misbruksresistens og bibliotekmodenhet, med det ene forbeholdet at man må sjekke at skytjenesten man planlegger å bruke, som Azure Key Vault, faktisk støtter kurven.
Ofte stilte spørsmål
Hva er den viktigste forskjellen mellom secp256k1 og Ed25519?
secp256k1 er en Weierstrass-kurve brukt med ECDSA, og krever en sikker tilfeldighetsgenerator for hver signatur. Ed25519 er en Edwards-kurve brukt med EdDSA, med deterministisk noncegenerering og faste 64-byte signaturer, noe som gjør den enklere å implementere feilfritt.
Er Ed25519 raskere enn secp256k1?
Som regel, men ikke alltid. Crypto++-benchmarks viser Ed25519 20-30 ganger raskere enn ECDSA på secp256k1/secp256r1. Men i en 2026-benchmark med noble/curves i JavaScript signerte secp256k1 faktisk rundt 5 prosent raskere, mens Ed25519 verifiserte rundt 18 prosent raskere. Resultatet avhenger sterkt av implementasjon og maskinvare.
Hvorfor bruker Bitcoin og Ethereum secp256k1 og ikke Ed25519?
Bitcoin ble lansert i 2009 og Ethereum i 2015, mens Ed25519 først ble beskrevet i 2011 og standardisert av IETF i 2015. Da nettverkene ble designet var secp256k1 det etablerte, veldokumenterte valget. Å bytte kurve nå ville krevd en hard fork og ugyldiggjort eksisterende adresser.
Er secp256k1 mindre sikker enn Ed25519?
Begge gir omtrent 128-bit sikkerhet mot rene matematiske angrep, og ingen praktisk angrep har brutt den underliggende hardheten i noen av kurvene. Forskjellen ligger i implementasjonsrisiko: secp256k1 krever korrekt RNG-håndtering for hver signatur, mens Ed25519s deterministiske design fjerner den risikoen fra utviklerens ansvar.
Kan jeg bruke Ed25519 til Bitcoin-transaksjoner?
Nei. Bitcoin-protokollen krever secp256k1 med ECDSA eller Schnorr-signaturer. Ed25519-signaturer godtas ikke av Bitcoin-nettverket, og det finnes ingen støttet metode for å bruke Ed25519-nøkler til å signere Bitcoin-transaksjoner.
Støtter Ledger og Trezor begge kurvene?
Ja. Både Ledger- og Trezor-enheter støtter secp256k1 og Ed25519 i firmware, dokumentert i deres respektive utviklerbiblioteker. Coldcard, som er en Bitcoin-only-enhet, støtter kun secp256k1.
Er noen av kurvene kvantesikre?
Nei, verken secp256k1 eller Ed25519 er motstandsdyktige mot en stor nok kvantedatamaskin, siden begge er sårbare for Shors algoritme. Postkvante-alternativer som ML-DSA og SLH-DSA finnes allerede standardisert av NIST, men krever egne migreringer uavhengig av hvilken klassisk kurve du bruker i dag.
Bør jeg velge Ed25519 for et nytt prosjekt i 2026?
Hvis prosjektet ikke er bundet av en eksisterende blokkjede som krever secp256k1, er Ed25519 som regel det tryggere og enklere valget takket være deterministisk noncegenerering og faste signaturstørrelser. Sjekk likevel at alle tjenester du er avhengig av, som Azure Key Vault, faktisk støtter kurven før du bygger den inn i arkitekturen. Gjør en rask kartlegging av hele signeringskjeden, fra klient til KMS til eventuell maskinvarelommebok, før du låser valget, siden det er langt billigere å bytte kurve på tegnebrettet enn etter at systemet er i produksjon.
