Bitcoin bruker den. TLS 1.3 bruker den ikke. Passnøkler stoler på den ene, kryptobørser stoler på den andre. secp256k1 og P-256 (også kalt secp256r1) er begge 256-bits elliptiske kurver med rundt 128 bits klassisk sikkerhet, men de to kurvene har helt ulik historie, ulikt tillitsgrunnlag og ulik ytelse i praksis. For norske og nordiske utviklere som bygger alt fra lommebok-integrasjoner til passordløs innlogging med FIDO2, er valget mellom disse to kurvene sjelden tilfeldig. Denne sammenligningen går gjennom ytelsestall, sikkerhetsnivå, standardstøtte og hvilken kurve du bør velge til hvilket formål, med tall hentet fra ferske benchmarks og bransjerapporter fra 2025 og 2026.
Spørsmålet dukker stadig oftere opp i norske utviklerteam, ikke minst fordi finansteknologi-selskaper i Oslo og Stockholm nå bygger produkter som spenner over begge verdener samtidig: en bank-app kan trenge P-256 for sin TLS-tilkobling og WebAuthn-innlogging, samtidig som den samme appen tilbyr kryptovaluta-lommebok med secp256k1 under panseret. Den doble virkeligheten gjør det ekstra viktig å forstå hvor de to kurvene faktisk skiller seg, og hvor forskjellen i praksis er null.
Hva er secp256k1 og P-256?
Begge kurvene er såkalte Weierstrass-kurver over et 256-bits primtallsfelt, men de kommer fra ulike standardiseringsmiljøer. secp256k1 ble definert av Standards for Efficient Cryptography Group (SEC) i standarden SEC 2, og fikk sitt gjennombrudd da Satoshi Nakamoto valgte den som signaturkurve for Bitcoin i 2009. Ethereum og de fleste andre store kryptovalutaer fulgte etter, og i dag er secp256k1 nærmest synonymt med blokkjede-signaturer.
P-256, også kjent som secp256r1 eller NIST P-256, ble publisert av det amerikanske standardiseringsorganet NIST og er i dag formalisert i FIPS 186-5. Kurven er default-valget i nesten alle generelle kryptobiblioteker: OpenSSL, BoringSSL, NSS, Java sin JCA og nettleserens innebygde WebCrypto API. W3Cs retningslinjer for kryptografi i webstandarder fra 2026 peker på P-256, P-384 og P-521 som “de mest brukte og anbefalte kurvene” for generell bruk på nett, ifølge W3Cs offisielle sikkerhetsveiledning.
Den matematiske forskjellen ligger i kurveligningen. secp256k1 har parametrene a = 0 og b = 7, en uvanlig enkel form som muliggjør effektive optimaliseringer via såkalt endomorfi-basert regning. P-256 har derimot parametre som ble generert gjennom en prosess NIST aldri fullt ut har dokumentert, noe som i årevis har gitt grobunn for mistanke i deler av kryptomiljøet.
Begge kurvene tilhører samme familie av kryptografi, kalt elliptisk kurve-kryptografi (ECC), som ble foreslått uavhengig av Neal Koblitz og Victor Miller på 1980-tallet. Fordelen med ECC fremfor eldre RSA-baserte systemer er at man oppnår samme sikkerhetsnivå med langt kortere nøkler. En 256-bits ECC-nøkkel gir omtrent samme beskyttelse som en 3072-bits RSA-nøkkel, noe som gjør signaturer raskere å generere, mindre å lagre og billigere å overføre over nettverk. Det er nettopp derfor både Bitcoin-utviklerne og internettstandardene landet på 256-bits kurver da de skulle velge sin foretrukne signaturmetode, selv om de valgte hver sin variant.
Teknisk spesifikasjonstabell: secp256k1 mot P-256
Tabellen under oppsummerer de viktigste tekniske og praktiske forskjellene mellom kurvene, basert på offentlige standarddokumenter og bransjemålinger.
| Egenskap | secp256k1 | P-256 (secp256r1) |
|---|---|---|
| Standardiseringsorgan | SEC (Standards for Efficient Cryptography) | NIST, FIPS 186-5 |
| Nøkkellengde | 256 bit | 256 bit |
| Klassisk sikkerhetsnivå | ~128 bit | ~128 bit |
| Kurveparametre | a = 0, b = 7 (enkel form) | Egne, ikke fullt dokumenterte parametre |
| FIPS-godkjent | Nei | Ja |
| Hovedbruk | Bitcoin, Ethereum, kryptovaluta-signaturer | TLS, WebAuthn/passnøkler, offentlig sektor |
| Referansebibliotek | libsecp256k1 (Bitcoin Core) | OpenSSL, BoringSSL, NSS |
| Andel av TLS ECDSA-håndtrykk | Under 0,03 % | Rundt 42 % av ECDSA-håndtrykk i målte datasett |
| Andel i e-post/SMTP ECDH | Under 0,03 % | Opptil 99,2 % ifølge arxiv-målingen |
| Kvante-sårbarhet (estimerte qubits) | Rundt 1 200 logiske qubits | 1 193 logiske qubits |
| Maskinvarestøtte | Begrenset i HSM-er og smartkort | Utbredt i HSM-er, smartkort og TPM-er |
| Tillitshistorikk | Uavhengig generert, ingen kjent bakdør-mistanke | Skepsis pga. NISTs rolle i Dual_EC_DRBG-saken |
Ytelsesbenchmark: signering og verifisering
Når det gjelder rå hastighet, viser flere uavhengige målinger fra 2025 og 2026 at secp256k1 har et lite, men konsekvent forsprang. En sammenligning publisert av Voltaire/TEVM-prosjektet, kjørt på en MacBook Pro M1 med Node.js 20, målte følgende gjennomsnittlige operasjonstider: nøkkelutledning tok 0,50 millisekunder for secp256k1 mot 0,55 millisekunder for P-256, en forskjell på rundt 10 prosent. Signering tok 1,25 millisekunder mot 1,30 millisekunder (4 prosent raskere for secp256k1), og verifisering endte på 2,50 mot 2,60 millisekunder, ifølge TEVMs offentlige sammenligningsdokument.
Forskjellen blir tydeligere når man sammenligner de mest optimaliserte bibliotekene direkte. libsecp256k1, som er Bitcoin Core sitt herdede referansebibliotek, signerte på rundt 0,50 millisekunder mot 0,60 millisekunder for OpenSSLs P-256-implementasjon, en forbedring på cirka 20 prosent. Ved verifisering var forspranget mindre, men fortsatt målbart: 1,00 millisekund mot 1,10 millisekund, altså rundt 10 prosent raskere for secp256k1. Konklusjonen fra samme kilde oppsummerer det treffende: P-256 vinner på maskinvarestøtte, secp256k1 vinner på programvareytelse.
Et akademisk forpublisert notat fra oktober 2025 målte gjennomstrømning i signaturer per sekund på en gitt testplattform. Der endte Ed25519 øverst med rundt 39 683 signaturer per sekund, fulgt av secp256k1 med omtrent 18 904 signaturer per sekund, mens den etterkvante algoritmen ML-DSA-44 landet på 14 451 signaturer per sekund. P-256 lå lavere enn secp256k1 i samme tabell, med høyere ventetid per operasjon under referanseimplementasjonen som ble testet.
| Benchmark-kilde | Operasjon | secp256k1 | P-256 | Forskjell |
|---|---|---|---|---|
| TEVM (MacBook M1, Node 20) | Nøkkelutledning | 0,50 ms | 0,55 ms | ~10 % raskere |
| TEVM (MacBook M1, Node 20) | Signering | 1,25 ms | 1,30 ms | ~4 % raskere |
| TEVM (MacBook M1, Node 20) | Verifisering | 2,50 ms | 2,60 ms | ~4 % raskere |
| libsecp256k1 vs OpenSSL | Signering | 0,50 ms | 0,60 ms | ~20 % raskere |
| libsecp256k1 vs OpenSSL | Verifisering | 1,00 ms | 1,10 ms | ~10 % raskere |
| Akademisk preprint (2025) | Gjennomstrømning | 18 904 sign./sek | Lavere i samme tabell | secp256k1 foran |
Forklaringen på hvorfor secp256k1 gjør det bedre i rene programvarebenchmarks handler om kurvens matematiske form. Fordi a = 0, kan implementasjoner som libsecp256k1 bruke såkalte endomorfi-triks som kutter antall multiplikasjoner nødvendig for skalarmultiplikasjon. Et teknisk sammendrag fra tidlig 2026 peker på at nye skalarmultiplikasjons-algoritmer, som forhåndsberegning med M-ær metode, har gitt opptil 59 prosent hastighetsforbedring på secp256k1 i enkelte oppsett, samtidig som minnebruken går ned. Dette er investeringer som Bitcoin-økosystemet har lagt mye ressurser i over flere år, mens generelle P-256-biblioteker prioriterer konstant-tid-sikkerhet og bred kompatibilitet fremfor maksimal rå hastighet.
Sidekanalangrep og implementasjonssikkerhet
Rå hastighet forteller bare halve historien. Det som ofte avgjør om en kryptografisk implementasjon faktisk er trygg i produksjon, er motstand mot sidekanalangrep, altså angrep som utnytter informasjon som lekker gjennom strømforbruk, cache-oppførsel eller tidsforskjeller i utførelsen, fremfor å angripe selve matematikken. libsecp256k1 har vært gjenstand for eksepsjonelt grundig gransking nettopp fordi svakheter her kan bety direkte tap av kryptovaluta. Biblioteket bruker konstant-tid skalarmultiplikasjon som standard, og Bitcoin Core-teamet har over flere år fjernet og forhindret varianttider som kunne avsløre private nøkler gjennom cache-timing.
OpenSSLs P-256-implementasjon har hatt en lignende modningsreise. Etter flere historiske sårbarheter knyttet til ikke-konstant-tid skalarmultiplikasjon på 2010-tallet, innførte OpenSSL en dedikert, konstant-tid P-256-implementasjon som i dag brukes som standard i de fleste distribusjoner. Begge kurvene har med andre ord kommet til et punkt der de mest brukte bibliotekene er herdet mot de vanligste klassene av sidekanalangrep, men det betyr ikke at enhver implementasjon andre steder automatisk er trygg. Et eget poeng her er at kvaliteten på implementasjonen, ikke kurven i seg selv, ofte er den faktoren som avgjør om et system faktisk blir kompromittert. Dårlig skrevet kode kan gjøre selv den tryggeste kurven sårbar, mens en godt herdet implementasjon av en eldre kurve kan holde tett i årevis.
Sikkerhetsnivå og tillit: Dual_EC_DRBG-skyggen
Rent matematisk gir begge kurvene omtrent samme klassiske sikkerhetsnivå, rundt 128 bit mot brute force-angrep med dagens datamaskiner. Ingen praktiske kryptoanalytiske angrep er kjent mot noen av kurvene per 2026. Forskjellen ligger ikke i matematikken, men i tilliten til prosessen bak parametrene.
Saken om Dual_EC_DRBG, en tilfeldighetsgenerator NIST standardiserte og som senere ble avslørt gjennom Snowden-dokumentene til å inneholde en sannsynlig bakdør fra det amerikanske sikkerhetsbyrået NSA, skapte varig mistanke mot NIST-relaterte kurver generelt, inkludert P-256. Ingen konkret bakdør er noen gang påvist i selve P-256-parametrene, og store standardiseringsorganer anbefaler fortsatt kurven uten forbehold. W3C fremhever P-256 sammen med P-384 og P-521 som de mest brukte og anbefalte valgene for generell nettkryptografi.
Likevel er skepsisen reell nok til at Bitcoin-miljøet aktivt valgte bort NIST-kurver da Nakamoto designet Bitcoin. secp256k1 ble generert gjennom en åpen, deterministisk prosess uten skjulte parametre, noe som har gjort kurven til et symbol på uavhengighet fra statlig kontrollerte standarder i kryptovaluta-verdenen. Denne tillitsdebatten er i praksis mer sosiopolitisk enn teknisk: de fleste tradisjonelle utviklingsmiljøer er fullt komfortable med P-256, mens personvern- og desentraliseringsorienterte miljøer foretrekker uavhengig genererte alternativer som secp256k1.
Kvantetrussel: er én av kurvene tryggere på lang sikt?
Her er svaret enkelt: nei. Begge kurvene er like sårbare for en fremtidig kvantedatamaskin som kjører Shors algoritme. En analyse fra 2026 basert på Chevignard-metoden anslår at det trengs rundt 1 193 logiske qubits for å bryte P-256, ned fra tidligere estimater på over 2 000 qubits, ifølge PostQuantum.com sin gjennomgang av forskningen. Fordi secp256k1 også er en 256-bits kurve over et primtallsfelt med lignende aritmetiske egenskaper, ligger estimatet for å bryte den svært nært, rundt 1 200 logiske qubits ifølge samme kilde.
Konsekvensen er at både Bitcoin-signaturer og TLS-forbindelser som bruker disse kurvene, står øverst på listen over kryptografi som må migreres når feiltolerante kvantedatamaskiner blir en realitet. Ingen fysisk kvantedatamaskin er i nærheten av å true noen av kurvene i dag, men NIST har allerede standardisert etterkvante alternativer som ML-KEM og ML-DSA, og migrasjonsplanlegging pågår i både bank-, betalings- og kryptovaluta-sektoren. For lesere som følger med på Bitcoin spesifikt, er det verdt å merke seg at nettopp denne kvantetrusselen har vært tema i egne forslag om å sikre eksisterende BTC-beholdninger før en eventuell kvante-gjennombrudd.
Bruksområder: hvem bruker hvilken kurve?
Fordelingen mellom de to kurvene i den virkelige verden er slående ulik. Målinger av faktiske TLS-håndtrykk viser at NIST P-256 dominerer nesten totalt utenfor kryptovaluta-nisjen. En storskala kartlegging av TLS i e-post-økosystemet fant at secp256r1 (P-256) ble brukt i opptil 99,2 prosent av alle ECDH-håndtrykk for enkelte protokoller, mens kurver som secp256k1 og sect163r2 til sammen utgjorde under 0,03 prosent, ifølge den akademiske målingen på arXiv. En annen presentasjon om tilstanden for elliptisk kurve-kryptografi i virkelige protokoller fant at P-256 sto for rundt 42 prosent av ECDSA-håndtrykk i TLS generelt, og hele 97 prosent av ECC-håndtrykkene i et utvalg av e-post-relatert trafikk.
secp256k1 sin dominans finner man i stedet i blokkjede-verdenen. Bitcoin bruker kurven for alle sine ECDSA- og Schnorr-signaturer, Ethereum bruker den for kontonøkler på lag 1, og de fleste lag 2-løsninger og kryptobørser arver dette valget videre. W3Cs kryptografiveiledning fra 2026 nevner eksplisitt secp256k1 som kurven “brukt i Bitcoin og andre kryptovalutaer”, i kontrast til NIST-kurvene som brukes i mainstream nettstandarder.
Passnøkler og WebAuthn/FIDO2 er et eget kapittel der P-256 er selve fundamentet. Nesten alle testede implementasjoner av plattform- og roaming-autentikatorer bruker P-256-baserte ECDSA-nøkler som standard eller sterkt anbefalt kurve. Dette har fått ekstra vekt i 2025 og 2026 fordi passnøkler har hatt en eksplosiv vekst: ifølge MojoAuths rapport om passordløs autentisering økte bruken av passnøkler (FIDO2/WebAuthn) med 412 prosent i løpet av 2025, og ble dermed den raskest voksende autentiseringsmetoden, se MojoAuths fullstendige rapport. En egen kartlegging av passnøkkel-adopsjon i 2026 rapporterer at rundt 90 prosent av nettlesere og plattformer nå er klare for passnøkler, ifølge State of Passkeys-rapporten.
Hvor passer Ed25519 og X25519 inn i bildet?
Ingen sammenligning av elliptiske kurver er fullstendig uten å nevne Edwards-kurve-familien, siden Ed25519 og X25519 stadig oftere dukker opp som et tredje alternativ ved siden av secp256k1 og P-256. Ed25519, brukt til signaturer, og X25519, brukt til nøkkelutveksling, er begge bygget på Curve25519 og er designet spesifikt for å unngå mange av implementasjonsfellene som rammer eldre Weierstrass-kurver som P-256. I ren ytelse er Ed25519 ofte raskest av alle tre, med rundt 39 683 signaturer per sekund i det tidligere nevnte akademiske testet, klart foran både secp256k1 og P-256.
Grunnen til at verken Bitcoin eller de fleste TLS-implementasjoner byttet direkte til Ed25519 handler om historisk timing og bakoverkompatibilitet, ikke om at Ed25519 er teknisk underlegen. Bitcoin var allerede etablert med secp256k1 lenge før Ed25519 ble standardisert i RFC 8032, og TLS-økosystemet har måttet balansere støtte for eldre klienter som kun forstår NIST-kurver. Nyere protokoller som SSH og Signal-protokollen har derimot i stor grad gått rett til Curve25519-familien, nettopp fordi de ikke bar med seg samme historiske forpliktelse. For lesere som vurderer et helt nytt system uten bindinger til verken Bitcoin eller eldre TLS-klienter, er Ed25519 og X25519 ofte et sterkere tredje alternativ enn begge kurvene i denne sammenligningen.
Fem konkrete bruksområder og anbefalinger
Valget mellom secp256k1 og P-256 avhenger nesten alltid av hva systemet skal integrere med, ikke bare av rå ytelse. Her er fem konkrete scenarier norske utviklingsteam møter i praksis.
- Lommebok- og børsintegrasjon for kryptovaluta: Hvis systemet skal signere Bitcoin- eller Ethereum-transaksjoner, er secp256k1 obligatorisk. Det finnes ikke noe reelt valg her fordi protokollene selv krever denne kurven, og libsecp256k1 er godt herdet mot sidekanalangrep etter over ti år med skarp gransking fra Bitcoin Core-utviklerne.
- Passordløs innlogging med FIDO2/passnøkler: Her er P-256 standardvalget i praksis. De fleste autentikator-brikker og operativsystem-implementasjoner av WebAuthn bruker P-256, så et forsøk på å tvinge inn secp256k1 vil skape kompatibilitetsproblemer med eksisterende maskinvare.
- TLS-tilkoblinger og offentlig sektor i Norge: Norske offentlige systemer som må følge FIPS-relaterte krav eller NSMs grunnprinsipper for IKT-sikkerhet, bør holde seg til P-256 fordi det er den eneste av de to som er formelt validert under FIPS 186-5.
- Høy-frekvens signaturverifisering i node-infrastruktur: For blokkjede-noder som verifiserer tusenvis av signaturer per sekund, gir secp256k1 sammen med libsecp256k1 en målbar ytelsesgevinst, spesielt ved batch-verifisering av mange transaksjoner samtidig.
- Nye prosjekter uten eksisterende bindinger: Har du et helt nytt system uten krav fra tredjepartsprotokoller, er P-256 ofte det tryggeste valget rent økosystemmessig, ganske enkelt fordi flere HSM-er, skytjenester og biblioteker støtter den ut av boksen.
Regulatoriske hensyn i Norge og Norden
For norske og nordiske organisasjoner er det ikke bare teknisk ytelse som styrer kurvevalget. Nasjonal sikkerhetsmyndighet (NSM) sine grunnprinsipper for IKT-sikkerhet legger vekt på bruk av godkjente og internasjonalt anerkjente kryptografiske standarder i offentlig sektor, noe som i praksis peker mot NIST-godkjente algoritmer som P-256 fremfor secp256k1 for systemer som håndterer personopplysninger eller kritisk infrastruktur. Finanstilsynet og tilsvarende myndigheter i Sverige og Danmark stiller lignende krav til banker og betalingsforetak som bygger kundevendte systemer, noe som forklarer hvorfor nordiske BankID- og signeringstjenester konsekvent har landet på FIPS-kompatible kurver.
Samtidig opererer et voksende antall nordiske fintech- og kryptoselskaper i et regulatorisk grenseland der de må tilfredsstille både tradisjonelle finanskrav og kryptovaluta-spesifikke protokollkrav samtidig. Et selskap som tilbyr forvaltning av kryptovaluta til norske kunder må for eksempel bruke secp256k1 for selve blokkjede-transaksjonene, samtidig som hele den kundevendte plattformen, inkludert innlogging og API-kommunikasjon, som regel må bygges på P-256 eller tilsvarende NIST-godkjente kurver for å tilfredsstille generelle IT-sikkerhetskrav fra tilsynsmyndighetene. Denne todelingen er trolig den klareste praktiske illustrasjonen av hvorfor spørsmålet “hvilken kurve er best” sjelden har ett riktig svar i nordisk sammenheng.
Bibliotekstøtte og prisbilde
P-256 er tilgjengelig som førsteklasses funksjon i praktisk talt alle allmenne kryptobiblioteker: OpenSSL, BoringSSL, Mozillas NSS, Javas innebygde JCA og nettleserens WebCrypto API støtter kurven direkte, ofte som standardvalg. Dette gjør P-256 til det mest kostnadseffektive valget for generelle utviklingsteam, fordi ingen tredjepartsavhengigheter kreves og maskinvareakselerasjon i HSM-er og smartkort som regel allerede finnes.
secp256k1 støttes også i OpenSSL, men flaggskip-implementasjonen er libsecp256k1, et spesialisert og svært herdet bibliotek utviklet av Bitcoin Core-miljøet. Biblioteket er gratis og open source, men krever at teamet tar inn en ekstra avhengighet utover det som følger med standard TLS-stabler. For team som allerede jobber med blokkjede-integrasjoner er dette ikke et reelt merarbeid, siden biblioteket uansett er en forutsetning for å snakke med Bitcoin- eller Ethereum-nettverket.
| Løsning | Lisenskostnad | Vedlikeholdsansvar | Typisk bruksscenario |
|---|---|---|---|
| OpenSSL (P-256) | Gratis, Apache-lisens | OpenSSL-prosjektet, bred bransjestøtte | TLS, generell webkryptografi |
| BoringSSL (P-256) | Gratis, Google-vedlikeholdt | Chrome, interne Google-tjenester | |
| Nettleser WebCrypto API (P-256) | Gratis, innebygd | Nettleserleverandør | Passnøkler, WebAuthn i nettleser |
| libsecp256k1 (secp256k1) | Gratis, MIT-lisens | Bitcoin Core-bidragsytere | Blokkjede-noder, lommebøker |
| Kommersiell HSM med FIPS-modus | Fra noen tusen til over hundre tusen kroner per enhet | Maskinvareleverandør | Bank, offentlig sektor, regulert finans |
Kodeeksempel: generere nøkkelpar med begge kurvene
For å illustrere hvor likt de to kurvene faktisk brukes i praksis fra et utviklerperspektiv, viser eksempelet under hvordan man genererer nøkkelpar med Node.js sitt innebygde crypto-modul for begge kurvene.
const crypto = require('node:crypto');
// P-256 (secp256r1) - standard i TLS og WebAuthn
const p256KeyPair = crypto.generateKeyPairSync('ec', {
namedCurve: 'P-256',
});
// secp256k1 - standard i Bitcoin og Ethereum
const secp256k1KeyPair = crypto.generateKeyPairSync('ec', {
namedCurve: 'secp256k1',
});
console.log('P-256 offentlig nøkkel:', p256KeyPair.publicKey.export({ type: 'spki', format: 'pem' }));
console.log('secp256k1 offentlig nøkkel:', secp256k1KeyPair.publicKey.export({ type: 'spki', format: 'pem' }));API-et er identisk fra utviklersiden, forskjellen ligger utelukkende i hvilken navngitt kurve som sendes inn. Dette er en av grunnene til at valget mellom kurvene sjelden handler om utviklingskompleksitet, og nesten alltid om hvilket økosystem systemet må snakke med.
Verktøy og økosystem for utviklere
Verktøystøtten rundt de to kurvene reflekterer bruksmønstrene deres. For P-256 finnes det et bredt utvalg av feilsøkingsverktøy, sertifikatinspeksjon og debuggere som er innebygd i eksisterende TLS-verktøy som OpenSSL sin kommandolinje, Wiresharks TLS-dekryptering og nettleserens egne utviklerverktøy for å inspisere sertifikatkjeder. En utvikler som feilsøker et TLS-håndtrykk med P-256 har et modent, tiår langt økosystem av dokumentasjon og feilsøkingsguider å støtte seg på.
For secp256k1 er verktøylandskapet mer spesialisert, men til gjengjeld svært dypt innenfor sitt felt. Bitcoin Core leverer egne testverktøy for signaturvalidering, og økosystemet rundt Ethereum har verktøy som Foundry og Hardhat som gjør det enkelt å generere, teste og feilsøke secp256k1-signaturer i utviklingsmiljø før de sendes til hovednettet. Blokkkjedeutforskere som Etherscan og mempool.space gir også utviklere direkte innsyn i hvordan signaturer faktisk validerer på nettverksnivå, noe som ikke har noen direkte parallell i P-256-verdenen fordi TLS-håndtrykk ikke er offentlig søkbare på samme måte.
Et konkret utviklingspoeng er testing under kontinuerlig integrasjon. Fordi secp256k1-relaterte feil kan bety direkte tap av midler, har store deler av bransjen standardisert på automatiserte test-suiter som kjører tusenvis av kjente signatur/nøkkel-par gjennom hver eneste kodeendring i libsecp256k1. P-256-implementasjoner i generelle TLS-biblioteker testes typisk gjennom bredere interoperabilitetstester på tvers av mange algoritmer samtidig, siden P-256 sjelden er det eneste kritiske elementet i en gitt sikkerhetsstack.
Fem virkelige eksempler fra bransjen
For å konkretisere forskjellen mellom de to kurvene i praksis, er det verdt å se på hvordan konkrete systemer faktisk har valgt.
- Bitcoin Core: Bruker secp256k1 for alle ECDSA-signaturer siden lansering i 2009, og siden Taproot-oppgraderingen også for Schnorr-signaturer på samme kurve.
- Ethereum-kontonøkler: All signering av transaksjoner på lag 1 bruker secp256k1, arvet direkte fra Bitcoins design.
- Apple og Google sine passnøkkel-implementasjoner: Plattform-autentikatorer i iOS, Android og de store nettleserne bruker som hovedregel P-256-baserte ECDSA-nøkler for WebAuthn-akkrediteringer.
- TLS-sertifikater fra store sertifikatutstedere: De fleste ECDSA-baserte TLS-sertifikater som utstedes i dag bruker P-256, ettersom det er kurven med bredest klientstøtte på tvers av eldre og nyere nettlesere.
- Norske BankID- og signeringsløsninger: Offentlige og regulerte norske signeringstjenester holder seg til FIPS-godkjente kurver som P-256, i tråd med krav fra NSMs grunnprinsipper for IKT-sikkerhet til statlige og kommunale systemer.
Migreringsguide: bytte kurve i et eksisterende system
Å bytte elliptisk kurve i produksjon er ikke en triviell øvelse, fordi nøkler, signaturer og protokollavtaler ofte er hardkodet mot én bestemt kurve. Her er stegene et team typisk må gjennom.
- Kartlegg alle steder i kodebasen der elliptisk kurve-kryptografi brukes, inkludert TLS-konfigurasjon, JWT-signering og eventuelle blokkjede-integrasjoner.
- Identifiser om kurven er bestemt av en ekstern protokoll (som Bitcoin eller WebAuthn) eller om den er et internt designvalg som faktisk kan endres.
- Test kompatibilitet med eksisterende klienter og HSM-er før du bytter, siden ikke alle eldre nettlesere eller smartkort støtter begge kurvene likt.
- Generer nye nøkkelpar på målkurven i et isolert testmiljø, og verifiser signaturer mot både gamle og nye nøkler i en overgangsperiode.
- Rull ut støtte for begge kurver parallelt der det er mulig, slik at eksisterende klienter ikke bryter mens nye klienter migrerer over.
- Oppdater sertifikatkjeder og eventuelle CA-utstedte sertifikater til å bruke den nye kurven, med vanlig sertifikatrotasjon som ramme.
- Fjern støtte for den gamle kurven først når telemetri viser at ingen aktive klienter lenger bruker den.
- Dokumenter valget grundig, spesielt begrunnelsen for hvorfor kurven ble byttet, slik at fremtidige sikkerhetsrevisjoner forstår kontekst uten å måtte spore opp gamle beslutninger manuelt.
Et viktig poeng her er at de færreste team faktisk migrerer mellom secp256k1 og P-256 i én og samme applikasjon, siden valget som regel er diktert av protokollen systemet skal snakke med. Den vanligste migreringen i praksis er heller innføring av støtte for begge kurver samtidig, for eksempel en betalingsplattform som må signere både TLS-trafikk med P-256 og Bitcoin-transaksjoner med secp256k1 i samme kodebase.
En vanlig fallgruve underveis er å anta at signaturformatene er kompatible på tvers av kurver bare fordi begge bruker ECDSA. Det stemmer ikke. En ECDSA-signatur er alltid knyttet til den spesifikke kurven nøkkelen ble generert på, og et forsøk på å verifisere en secp256k1-signatur mot en P-256 offentlig nøkkel vil alltid feile, uansett hvor korrekt signaturen ellers er. Team som bygger brofunksjonalitet mellom blokkjede-systemer og tradisjonell IT-infrastruktur bør derfor teste eksplisitt for denne feilklassen i sin egen kodebase, ettersom feilmeldingene fra de fleste kryptobiblioteker ikke alltid gjør det tydelig at årsaken er feil kurve fremfor en ugyldig signatur.
Historikk og sikkerhetsrevisjoner
Begge kurvene har nå over et tiår med produksjonsbruk bak seg, noe som gir et godt datagrunnlag for å vurdere faktisk track record fremfor bare teoretisk sikkerhet. secp256k1 har vært i kontinuerlig bruk siden Bitcoins lansering i januar 2009, og libsecp256k1 spesifikt har gjennomgått flere runder ekstern revisjon finansiert av blant annet Blockstream og andre store aktører i Bitcoin-økosystemet. Ingen kritisk svakhet i selve kurvematematikken er noensinne funnet i denne perioden. De sikkerhetshendelsene som har rammet kryptovaluta-brukere har nesten uten unntak vært knyttet til svak tilfeldighetsgenerering ved nøkkelgenerering, phishing eller kompromitterte lommebok-applikasjoner, ikke svakheter i selve secp256k1-kurven.
P-256 har en enda lengre historie, med opprinnelse tilbake til NISTs kurvepublikasjoner på 1990-tallet, og brukes i dag i alt fra bankkort til statlige ID-løsninger over hele verden. Kurven har overlevd flere tiår med kryptoanalytisk gransking fra akademia uten at noen har funnet en praktisk vei til å bryte den raskere enn generisk brute force skulle tilsi. Den vedvarende skepsisen mot kurven handler, som nevnt, om opprinnelsesprosessen og ikke om dokumenterte svakheter som er funnet i ettertid. For et sikkerhetsteam som skal vurdere risiko, er det verdt å skille tydelig mellom teoretisk tillitsrisiko og faktisk, påvist sårbarhet, noe begge kurvene i praksis mangler etter flere tiår kombinert i produksjon.
Fordeler og ulemper med secp256k1
secp256k1 har klare styrker innenfor sitt naturlige bruksområde, men også åpenbare begrensninger utenfor det.
- Fordel: Målbart raskere i optimalisert programvare, med opptil 20 prosent raskere signering mot OpenSSLs P-256 i direkte sammenligning.
- Fordel: Uavhengig generert uten NIST-involvering, noe som fjerner tillitsspørsmålet knyttet til Dual_EC_DRBG-historikken.
- Fordel: Enorm og moden verktøykasse innen blokkjede-utvikling, med libsecp256k1 som svært godt gransket referanseimplementasjon.
- Ulempe: Ikke FIPS-godkjent, noe som utelukker kurven fra mange regulerte offentlige og finansielle systemer.
- Ulempe: Vesentlig svakere maskinvarestøtte i HSM-er og smartkort sammenlignet med P-256.
- Ulempe: Praktisk talt fraværende i generell TLS-trafikk, noe som gjør interoperabilitet med eksisterende webinfrastruktur vanskeligere.
Fordeler og ulemper med P-256
- Fordel: FIPS 186-5-godkjent og akseptert i praktisk talt alle regulerte miljøer, inkludert offentlig sektor.
- Fordel: Dominerende i TLS, med opptil 99,2 prosent bruk i enkelte målte protokoll-kategorier og bred maskinvareakselerasjon.
- Fordel: Selve fundamentet for WebAuthn og passnøkler, en kategori som vokste 412 prosent i bruk gjennom 2025.
- Ulempe: Målbart tregere enn secp256k1 i optimaliserte programvarebenchmarks, om enn med en forskjell på bare 4 til 20 prosent avhengig av implementasjon.
- Ulempe: Fortsatt et tillitsspørsmål for deler av sikkerhetsmiljøet på grunn av NISTs historikk med Dual_EC_DRBG.
- Ulempe: Ubrukelig for direkte integrasjon mot Bitcoin- eller Ethereum-protokollen, som krever secp256k1 spesifikt.
Prisbilde: hva koster det å implementere hver kurve?
Selve kryptografien er gratis i begge tilfeller, siden både OpenSSL og libsecp256k1 er åpen kildekode uten lisenskostnad. Den reelle kostnadsforskjellen ligger i infrastruktur og drift rundt kurvene.
For P-256 kan team som trenger FIPS-validert maskinvare regne med kostnader fra rundt 5 000 til over 150 000 kroner per HSM-enhet, avhengig av leverandør og gjennomstrømningskrav, siden maskinvaren allerede er utbredt og konkurransen mellom leverandører er stor. Skytjenester som AWS KMS og Azure Key Vault tilbyr også P-256-signering som en betal-per-bruk-tjeneste, typisk priset i brøkdeler av en krone per signeringsoperasjon.
For secp256k1 er den direkte maskinvarekostnaden ofte lavere fordi de fleste implementasjoner kjører i ren programvare på standard servere, men team må i stedet regne inn kostnaden ved å drifte og granske en mer spesialisert kodebase, samt eventuelt betale for revisjon av lommebok-infrastruktur fra sikkerhetsselskaper som spesialiserer seg på blokkjede-revisjon, noe som ofte koster mer enn en generisk kryptografi-revisjon nettopp fordi feil her kan koste tapte midler direkte.
Skytjenesteleverandørenes prising er også verdt å nevne, siden mange norske og nordiske selskaper i praksis håndterer nøklene sine gjennom en administrert tjeneste fremfor å drifte egen HSM-maskinvare. AWS KMS, Azure Key Vault og Google Cloud KMS støtter alle P-256 som en av standardkurvene for administrerte nøkler, typisk priset per nøkkel per måned pluss en liten sum per signeringsoperasjon. Ingen av de tre store skyleverandørene tilbyr i dag secp256k1 som en innebygd administrert nøkkeltype i sine KMS-tjenester på samme måte, noe som betyr at team som trenger secp256k1-signering i skyen som regel må drifte egen infrastruktur eller bruke spesialiserte tjenester fra blokkjede-fokuserte leverandører, noe som legger til et ekstra driftslag sammenlignet med den native KMS-støtten P-256 har.
Verdikt: hvilken kurve bør du velge?
Basert på tallene over er konklusjonen tydelig: dette er ikke et spørsmål om hvilken kurve som er “best” i vakuum, men om hvilket økosystem applikasjonen din skal snakke med. Skal du bygge noe som helst mot Bitcoin eller Ethereum, er secp256k1 det eneste reelle valget, og du får i tillegg en målbar ytelsesgevinst på mellom 4 og 20 prosent avhengig av operasjon og bibliotek. Skal du derimot bygge TLS-tjenester, passnøkkel-støtte eller noe som må være FIPS-kompatibelt, er P-256 det opplagte valget, understøttet av en enorm andel av dagens internett-trafikk og en eksplosiv vekst i passnøkkel-adopsjon.
Sikkerhetsmessig er de to kurvene i praksis likeverdige mot dagens klassiske datamaskiner, og begge er like eksponert mot en fremtidig kvantedatamaskin med rundt 1 200 logiske qubits nødvendig for å bryte hver av dem. Tillitsdebatten rundt NIST vil trolig aldri forsvinne helt, men den bør ikke alene styre et teknisk valg der protokollkrav og økosystemstøtte i praksis avgjør saken for de aller fleste utviklere.
For norske utviklingsteam som skal ta denne beslutningen i praksis, kan valget forenkles til tre spørsmål. Må systemet snakke direkte med en eksisterende blokkjede-protokoll? Da er svaret secp256k1, uten unntak. Må systemet være FIPS-kompatibelt, integrere med WebAuthn, eller snakke med eksisterende TLS-infrastruktur og HSM-er? Da er svaret P-256. Har systemet ingen av disse bindingene og skal bygges fra bunnen av med moderne krav til enkel og sikker implementasjon? Da er det verdt å også vurdere Ed25519 og X25519 som et tredje, ofte enda raskere og enklere alternativ, før man lander på en av de to kurvene i denne sammenligningen. Uansett hvilken vei man velger, er den viktigste enkeltfaktoren for faktisk sikkerhet i produksjon kvaliteten på implementasjonen og nøkkelhåndteringen rundt kurven, ikke kurven i seg selv.
Ofte stilte spørsmål
Er secp256k1 raskere enn P-256?
Ja, i optimaliserte programvarebenchmarks er secp256k1 mellom 4 og 20 prosent raskere enn P-256, avhengig av hvilke biblioteker som sammenlignes og hvilken operasjon som måles.
Kan jeg bruke secp256k1 til TLS?
Teknisk sett er det mulig i enkelte biblioteker, men kurven har svært begrenset klientstøtte i nettlesere og TLS-stabler, og utgjør under 0,03 prosent av målt ECC-bruk i TLS-håndtrykk i dag.
Hvorfor valgte Bitcoin secp256k1 fremfor en NIST-kurve?
Nakamoto valgte en kurve generert utenfor NISTs kontroll for å unngå enhver mistanke om skjulte svakheter, et valg som fikk økt symbolsk betydning etter at Dual_EC_DRBG-saken avslørte en sannsynlig bakdør i en annen NIST-standardisert algoritme.
Er P-256 usikker på grunn av Dual_EC_DRBG-saken?
Nei, det finnes ingen påvist bakdør i selve P-256-kurven, og store standardiseringsorganer som W3C anbefaler den fortsatt som en av de mest pålitelige ECC-kurvene tilgjengelig.
Hvilken kurve bruker passnøkler (WebAuthn)?
De aller fleste passnøkkel-implementasjoner bruker P-256-baserte ECDSA-nøkler som standard, understøttet av bred maskinvarestøtte i telefoner, nettlesere og sikkerhetsbrikker.
Er noen av kurvene trygge mot kvantedatamaskiner?
Nei, verken secp256k1 eller P-256 gir noen beskyttelse mot en fremtidig, tilstrekkelig kraftig kvantedatamaskin. Begge krever rundt 1 200 logiske qubits for å bli brutt med Shors algoritme, og begge regnes som høyprioriterte kandidater for migrering til etterkvante alternativer som ML-KEM og ML-DSA.
Kan jeg konvertere en secp256k1-nøkkel til P-256?
Nei, nøkler er matematisk bundet til kurven de ble generert på. Det finnes ingen sikker eller meningsfull måte å konvertere et nøkkelpar fra én kurve til en annen, du må generere et helt nytt nøkkelpar på målkurven.
Bruker Ethereum 2.0 fortsatt secp256k1?
Ja, kontonøkler på Ethereum lag 1 bruker fortsatt secp256k1 for signering av transaksjoner, mens validator-nøkler i konsensuslaget benytter en annen kurve (BLS12-381) til aggregerte signaturer, noe som er et eget tema utenfor denne sammenligningen.
Er Ed25519 et bedre valg enn både secp256k1 og P-256?
For helt nye systemer uten eksisterende protokollbindinger er Ed25519 ofte det raskeste og enkleste alternativet å implementere trygt, med målt gjennomstrømning på rundt 39 683 signaturer per sekund i akademiske tester. Ulempen er at Ed25519 mangler den brede maskinvarestøtten P-256 har og den direkte protokollkompatibiliteten secp256k1 har med Bitcoin og Ethereum.
