Hver gang en nettleser åpner en HTTPS-tilkobling, avgjøres noe i bakgrunnen som de færreste tenker på: hvilken elliptisk kurve som brukes til å utveksle nøkler. To kurver dominerer i 2026, X25519 (Curve25519) og P-256 (secp256r1, ofte kalt NIST P-256). Valget mellom dem påvirker alt fra batteritid på mobil til om en norsk bank oppfyller FIPS-krav, og det avgjør nå også hvor raskt en tjeneste kan gå over til post-kvantesikker kryptering.
Denne sammenligningen går gjennom ytelsestall fra tre uavhengige kilder, spesifikasjonene side om side, hva de to kurvene koster å drifte i AWS, Google Cloud og Azure, og hvorfor IETF-forslaget om hybrid nøkkelutveksling gjør spørsmålet mer presserende enn før. Kort sagt: X25519 vinner på fart og enkel sikker implementasjon, P-256 vinner på compliance og HSM-støtte.
Vi har tidligere sett på nærliggende valg som ECDHE mot RSA i TLS 1.2 og ECDSA mot Ed25519 for signering. Denne artikkelen går et hakk dypere og sammenligner selve kurvene som ligger bak nøkkelutvekslingen, ikke bare protokollene og algoritmene som bruker dem.
Hva er X25519 og P-256?
X25519 er en Diffie-Hellman-nøkkelutvekslingsfunksjon bygget på Curve25519, en Montgomery-kurve som kryptografen Daniel J. Bernstein publiserte i 2006. Kurven ble senere standardisert av IETF i RFC 7748 sammen med den beslektede X448-kurven. X25519 brukes utelukkende til nøkkelutveksling (ECDH), mens signering på samme kurvefamilie håndteres av søsteralgoritmen Ed25519, som vi har sammenlignet med RSA tidligere.
P-256, også kjent som secp256r1 eller NIST P-256, er en Weierstrass-kurve som National Institute of Standards and Technology standardiserte allerede i 1999 gjennom FIPS 186. Den brukes både til nøkkelutveksling (ECDHE) og signering (ECDSA), og er kurven de fleste offentlige sertifikatmyndigheter og myndighetssystemer bygger rundt. Begge kurvene gir omtrent 128-bit klassisk sikkerhetsnivå, men de kommer fra to helt ulike designfilosofier, og det er den forskjellen som styrer alt fra ytelse til hvor lett det er å implementere dem trygt. P-256 fikk sitt gjennombrudd i en periode der Weierstrass-kurver var den dominerende formen i standardiseringsmiljøene, lenge før Curve25519 i det hele tatt eksisterte, og den brede tidlige adopsjonen er en viktig grunn til at kurven fortsatt er standardvalget i så mange eldre systemer.
Norske utviklere møter valget oftest i tre situasjoner: når TLS-biblioteket i en server eller app skal konfigureres, når en sky-KMS-tjeneste skal velge nøkkeltype, og når en ny tjeneste skal forberedes for hybrid post-kvantekryptering. I alle tre tilfeller er svaret sjeldent «den ene er alltid best». Det avhenger av maskinvare, regelverk og hvilke biblioteker som allerede finnes i stacken.
Begge kurvene brukes nesten alltid i kombinasjon med en ephemeral nøkkelutveksling, altså at et nytt nøkkelpar genereres for hver tilkobling i stedet for å gjenbruke samme nøkkel over tid. Det er dette som kalles ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) i TLS-sammenheng, og som gir egenskapen forward secrecy: selv om en angriper senere stjeler serverens langsiktige signeringsnøkkel, kan de ikke dekryptere gammel trafikk som allerede er logget. Både X25519 og P-256 støtter dette, og forskjellen mellom dem påvirker ikke forward secrecy-egenskapen i seg selv, kun ytelsen og implementasjonsrisikoen underveis.
Matematisk grunnlag: Montgomery-kurve mot Weierstrass-kurve
Kurveform og skalarmultiplikasjon
X25519 bruker en Montgomery-kurveform, som gjør at skalarmultiplikasjon (kjerneoperasjonen i nøkkelutveksling) kan implementeres med Montgomery-stigen, en algoritme med et fast, forutsigbart mønster av addisjoner og doblinger uansett hvilken privatnøkkel som brukes. P-256 er derimot en Weierstrass-kurve, og standard implementasjoner må ta hensyn til flere spesialtilfeller, som punktet i det uendelige og additiv identitet, noe som historisk har gjort trygge implementasjoner vanskeligere å skrive.
En praktisk konsekvens av Montgomery-formen er at X25519 kun trenger x-koordinaten til et punkt for å regne ut delt hemmelighet, ikke hele punktet. Det forenkler både matematikken og kodebasen betraktelig sammenlignet med en generell Weierstrass-implementasjon, som må håndtere både x- og y-koordinat og en rekke fortegnsregler underveis. Bernstein designet også Curve25519 spesifikt for å unngå kjente svake klasser av kurver, som kurver med lav embedding-grad eller uheldige twist-egenskaper, noe som gjør at biblioteker sjeldnere trenger ekstra sjekker rundt input-validering enn tilsvarende P-256-kode.
Sidekanal-egenskaper i praksis
Prosjektet SafeCurves, som evaluerer elliptiske kurver mot en rekke sikkerhetskriterier utover ren nøkkellengde, plasserer Curve25519 blant kurvene som består flest av kriteriene for sidekanal-motstand og robust implementasjon. P-256 stryker på flere av disse punktene, ikke fordi den er matematisk svakere, men fordi den enkle referanseimplementasjonen er lettere å gjøre feil med. Dette er også grunnen til at store aktører som OpenSSH og WireGuard bygget rundt X25519 fra dag én, mens P-256 primært lever videre i systemer som er bundet av eldre standarder eller FIPS-sertifisering.
Ytelse i praksis: tre uavhengige benchmark-kilder
Påstander om at «X25519 er raskere» blir mer troverdige når flere uavhengige målinger peker samme vei. Her er tre kilder som alle sammenligner de to kurvene direkte.
Et USENIX Security 2024-studie (Zhang et al., «ENG25519») målte en DNS-over-TLS-server bygget på OpenSSL og fant at X25519 håndterte 1.366 tilkoblinger per sekund mot 1.260 for P-256, en forskjell på rundt 8 prosent. Ved toppbelastning behandlet samme oppsett 234.875 forespørsler i minuttet med X25519 mot 206.275 med P-256, en forskjell på nesten 14 prosent. Sykluser telt med SUPERCOP-verktøyet, som er standardreferansen for kurvebenchmarks siden Bernsteins opprinnelige arbeid, viser omtrent 110.000 til 160.000 CPU-sykler per skalarmultiplikasjon for X25519 mot 180.000 til 250.000 for P-256 på sammenlignbar x86-64-maskinvare. Det tilsvarer at X25519 er om lag halvannen gang raskere i selve kjerneoperasjonen. OpenSSL sine egne speed-benchmarks på moderne server-CPU-er bekrefter mønsteret med ECDH-tider på 25 til 35 mikrosekunder for X25519 mot 50 til 65 mikrosekunder for P-256, altså opp mot dobbelt så raskt i mikrobenchmarks.
| Kilde | Måling | X25519 | P-256 | Forskjell |
|---|---|---|---|---|
| USENIX Security 2024 (ENG25519) | Tilkoblinger/sekund | 1.366 | 1.260 | +8 % |
| USENIX Security 2024 (ENG25519) | Forespørsler/minutt ved toppbelastning | 234.875 | 206.275 | +14 % |
| SUPERCOP-referansebenchmark | CPU-sykler per skalarmultiplikasjon | 110.000–160.000 | 180.000–250.000 | ~1,5x raskere |
| OpenSSL speed (server-CPU) | ECDH-operasjonstid | 25–35 µs | 50–65 µs | ~2x raskere |
Forskjellen krymper når man måler hele håndtrykket i stedet for kun kurveoperasjonen. Et studie fra 2026 som sammenlignet klassisk, hybrid og ren post-kvante nøkkelutveksling fant at tiden fra klientforespørsel til ferdig håndtrykk lå i et smalt bånd på 5,253 til 6,495 millisekunder i median, med bare 0,1 til 0,9 millisekunder forskjell mellom konfigurasjonene. Effektstørrelsen ble rapportert til 0,03–0,33, altså neglisjerbar til liten. Poenget er enkelt: mikrobenchmarks favoriserer X25519 tydelig, men den reelle forskjellen en sluttbruker merker på en vanlig nettside er minimal, fordi TLS-håndtrykket bare er én liten del av en full sidelasting.
Der forskjellen faktisk teller er på serversiden, i skala. En lastbalanserer eller CDN-node som terminerer titusenvis av nye TLS-tilkoblinger hvert sekund, bruker en betydelig andel av CPU-budsjettet sitt nettopp på nøkkelutveksling. Legges 8 til 14 prosent ekstra gjennomstrømning til grunn, kan det bety at en operatør trenger merkbart færre servernoder for å håndtere samme trafikkmengde, eller kan bruke den frigjorte CPU-tiden på andre oppgaver som komprimering eller applikasjonslogikk. Det er denne skaleringseffekten, mer enn opplevelsen for en enkelt bruker, som har fått store nettverksoperatører til å prioritere X25519 først i gruppelisten sin.
Sikkerhetsnivå og motstand mot sidekanalangrep
Begge kurvene gir rundt 128-bit klassisk sikkerhet, og ingen kjent klassisk angrepsteknikk bryter den ene raskere enn den andre. Til sammenligning tilsvarer 128-bit sikkerhet at et brute force-angrep i praksis er umulig med kjent klassisk datakraft, uansett hvor mange år eller hvor store databehandlingssentre en angriper har til rådighet. Det som skiller kurvene i praksis, er hvor lett det er å skru seg selv i foten. X25519 er designet slik at Montgomery-stigen naturlig kjører i konstant tid, uavhengig av hvilke bit som er satt i privatnøkkelen. Det gjør det vanskeligere å lekke nøkkelinformasjon via cache-timing eller strømforbruk, selv i en enkel implementasjon skrevet av et team uten dyp kryptografierfaring.
P-256 krever mer disiplin. Referanseimplementasjoner må eksplisitt håndtere spesialtilfeller i punktaddisjon, og flere historiske sårbarheter i ECDSA- og ECDH-biblioteker har kommet nettopp fra slurv i disse spesialtilfellene, ikke fra svakheter i selve kurven. Store biblioteker som OpenSSL og BoringSSL har i dag konstant-tids P-256-implementasjoner, men det har tatt år med sikkerhetsoppdateringer å komme dit.
Ingen av kurvene overlever et stort nok kvantekjørende system. Shors algoritme løser det diskrete logaritmeproblemet på elliptiske kurver effektivt, og det gjelder like fullt for X25519 som for P-256. Det er nettopp derfor bransjen nå kombinerer begge kurvene med gitterbasert kryptografi som ML-KEM i stedet for å bytte ut den ene klassiske kurven med den andre. En klassisk kurve alene, uansett hvilken, er ikke lenger nok som langsiktig sikkerhetsplan. For den som vil se hvordan tilsvarende resonnement slår ut på signeringssiden, dekker vi det i sammenligningen av ML-DSA mot ECDSA.
Virkelige hendelser: hvorfor sidekanalsikkerhet betyr noe
Diskusjonen om sidekanalmotstand er ikke bare teoretisk. I 2019 offentliggjorde et forskerteam Minerva-angrepet, som utnyttet små, målbare tidsforskjeller i hvordan flere populære biblioteker genererte den midlertidige nonce-verdien i ECDSA-signering på nettopp P-256-kurven. Biblioteker som OpenJDK, Libgcrypt, MatrixSSL og programvaren i enkelte smartkort ble berørt, og i verste fall kunne en angriper som observerte nok signeringsoperasjoner regne seg frem til den private nøkkelen. Feilen lå ikke i selve P-256-kurven, men i hvordan biblioteker rundt den implementerte tidskritiske operasjoner, akkurat det poenget SafeCurves-kriteriene forsøker å fange opp på forhånd.
Slike hendelser er en del av grunnen til at X25519 og Ed25519 har fått fotfeste så raskt siden midten av 2010-tallet. Når kurveformen i seg selv gjør det vanskeligere å skrive kode med variabel kjøretid, forsvinner en hel kategori av mulige implementasjonsfeil før koden i det hele tatt skrives. Det betyr ikke at X25519-biblioteker er immune mot feil, men angrepsflaten for nettopp denne typen sidekanallekkasje er mindre. For team uten dedikert kryptografiekspertise i huset er dette en praktisk fordel som teller minst like mye som rene ytelsestall.
Det finnes også en driftsside av dette som sjelden nevnes: revisjon og etterlevelse. Når et sikkerhetsteam skal dokumentere hvorfor en gitt kurve er trygg å bruke i produksjon, er det enklere å vise til at Curve25519 er designet fra bunnen av for å unngå kjente svakhetsklasser, enn å måtte forklare hvorfor en spesifikk implementasjon av en generell Weierstrass-kurve er trygg. Dette er ikke et argument mot P-256 som matematisk objekt, men et argument for at valget av kurve også er et valg om hvor mye implementasjonsrisiko organisasjonen tar på seg, noe som bør veies inn ved siden av rene ytelsestall og compliance-krav.
Spesifikasjoner side om side
Tabellen under samler de tekniske spesifikasjonene som avgjør hvilken kurve som passer et gitt system. Den er ment som oppslagsverk, verdt å lagre eller bokmerke neste gang en TLS-konfigurasjon eller et kurvevalg skal dokumenteres i et arkitekturnotat.
| Egenskap | X25519 | P-256 / secp256r1 |
|---|---|---|
| Kurvetype | Montgomery-kurve | Weierstrass-kurve (kort form) |
| Standard | RFC 7748 (IETF) | FIPS 186 (NIST) |
| Publiseringsår | 2006 (Bernstein), RFC 2016 | 1999–2000 |
| Offentlig nøkkelstørrelse | 32 byte | 65 byte (ukomprimert) |
| Privat nøkkelstørrelse | 32 byte | 32 byte |
| Delt hemmelighet | 32 byte | 32 byte |
| Klassisk sikkerhetsnivå | ~128 bit | ~128 bit |
| Bruksområde | Kun nøkkelutveksling (ECDH) | Nøkkelutveksling (ECDHE) og signering (ECDSA) |
| Signeringssøster | Ed25519 | ECDSA på P-256 |
| TLS 1.3 gruppe-ID (IANA) | 0x001D | 0x0017 |
| Hybrid PQC-gruppe (ML-KEM-768) | X25519MLKEM768 (0x11EC) | SecP256r1MLKEM768 (0x11EB) |
| Nøkkeldeling i hybridmodus | ~1.216 byte | ~1.249 byte |
| Offentlig CA-sertifikatstøtte | Nei (kun via Ed25519 for signatur, ikke for TLS-sertifikater) | Ja, standard i Let’s Encrypt og øvrige CA-er |
Nøkkelgenerering i praksis
Forskjellen mellom kurvene blir konkret så snart man genererer nøkler fra kommandolinjen. Med OpenSSL, som er standardverktøyet i de fleste Linux-distribusjoner, tar begge kommandoene under et brøkdels sekund, men syntaksen avslører hvor mye enklere X25519 er å be om riktig.
# Generer et X25519-nøkkelpar
openssl genpkey -algorithm X25519 -out x25519_private.pem
openssl pkey -in x25519_private.pem -pubout -out x25519_public.pem
# Generer et P-256-nøkkelpar
openssl ecparam -name prime256v1 -genkey -noout -out p256_private.pem
openssl ec -in p256_private.pem -pubout -out p256_public.pemLegg merke til at P-256 fortsatt omtales med sitt eldre navn prime256v1 i mange verktøy, en rest fra tiden før NIST-navngivningen ble standard i praksis. Den offentlige X25519-nøkkelen kommer alltid ut som nøyaktig 32 byte, kodet rett frem, mens P-256 sin offentlige nøkkel som standard er 65 byte i ukomprimert form (eller 33 byte komprimert), fordi Weierstrass-representasjonen krever et ekstra formatbyte og enten begge koordinater eller ett fortegnsbit. Denne forskjellen i format er en direkte konsekvens av kurveformen beskrevet tidligere, og den er også grunnen til at X25519-nøkler er enklere å bake inn i kompakte binærprotokoller som WireGuard sin konfigurasjonsfil.
De fleste utviklere møter aldri disse kommandolinjeverktøyene direkte, men via et TLS-bibliotek som håndterer nøkkelgenerering automatisk for hver tilkobling. Poenget med å vise dem her er å synliggjøre hvor mye enklere API-overflaten til X25519 er, med kun én rå nøkkelverdi å holde styr på, sammenlignet med P-256 sin mer forgrenede representasjon med flere gyldige kodinger av samme punkt. Biblioteker som håndterer feil kodingen kan i verste fall akseptere ugyldige eller manipulerte offentlige nøkler, noe som har vært roten til flere reelle sårbarheter i implementasjoner som ikke validerte punktet riktig før bruk. X25519 sin enklere kodede representasjon reduserer også denne klassen av valideringsfeil, selv om den ikke fjerner behovet for korrekt validering helt.
Støtte i nettlesere og TLS-biblioteker i 2026
Klassisk X25519 har det som kildene omtaler som universell støtte i alle moderne nettlesere, og det samme gjelder P-256. Forskjellen dukker opp når hybrid post-kvante nøkkelutveksling kommer inn i bildet. Chrome la til støtte for hybridgrupper i versjon 124 i mai 2024, med X25519MLKEM768 påslått som standard, og forsterket dette videre i Chrome 131. Firefox fulgte etter i versjon 124/128 samme år. Det tempoet er raskt etter bransjestandard: store TLS-endringer bruker normalt flere år på å gå fra spesifikasjon til standard i alle store nettlesere samtidig, mens hybrid PQC-støtten gikk fra utkast til reell utrulling på under to år, drevet av bekymringen for «høst nå, dekrypter senere»-angrep mot langsiktig sensitiv trafikk. Chromium-prosjektets egen dokumentasjon beskriver hvordan gruppevalget forhandles under håndtrykket, mens Cloudflare har dokumentert utrullingen av hybrid nøkkelutveksling på sitt globale nettverk.
På bibliotek-siden la wolfSSL og mbedTLS til hybrid TLS med både X25519MLKEM768 og SecP256r1MLKEM768 i løpet av 2025. Java-økosystemet fikk støtte via Bouncy Castle 1.78 samme år. OpenSSL 3.5 setter X25519MLKEM768 som produksjonsstandard, med SecP256r1MLKEM768 tilgjengelig som alternativ for miljøer som krever NIST-kurver.
| Programvare | Klassisk X25519 | Klassisk P-256 | Standard hybrid-gruppe |
|---|---|---|---|
| Chrome / Chromium (fra v124, mai 2024) | Ja | Ja | X25519MLKEM768 |
| Firefox (fra v124/128, 2024) | Ja | Ja | X25519MLKEM768 |
| Edge | Ja | Ja | X25519MLKEM768 |
| OpenSSL 3.5 | Ja | Ja | X25519MLKEM768 |
| wolfSSL (2025-utgave) | Ja | Ja | Begge tilgjengelig |
| mbedTLS (2025-utgave) | Ja | Ja | Begge tilgjengelig |
| Bouncy Castle 1.78 (Java) | Ja | Ja | Begge tilgjengelig |
| lighttpd 1.4.77 (jan. 2025) | Ja, først i gruppelisten | Ja, nummer to | Anbefalt rekkefølge: X25519:P-256:P-384:X448 |
Hybrid post-kvantekryptering: X25519MLKEM768 mot SecP256r1MLKEM768
IETFs TLS-arbeidsgruppe vedtok utkastet «draft-ietf-tls-ecdhe-mlkem» i mars 2025, og det hadde nådd status som nesten ferdig eller ferdig RFC innen august 2026. Dokumentet definerer tre hybridgrupper som kombinerer ML-KEM, standardisert av NIST i FIPS 203, med hver sin klassiske kurve: X25519MLKEM768, SecP256r1MLKEM768 og SecP384r1MLKEM1024. De to første er de som betyr mest for vanlige webtjenester.
Et ytelsesstudie fra 2025 målte brukertid per tilkobling for de to gruppene. Ved CCA-sikkerhet brukte X25519MLKEM768 721,81 mikrosekunder (±15,74) mot 953,15 mikrosekunder (±19,64) for SecP256r1MLKEM768. Ved CPA-sikkerhet var tallene 174,89 mikrosekunder (±1,38) mot 229,46 mikrosekunder (±0,88). I begge tilfeller er X25519-varianten klart raskere, i samme størrelsesorden som forskjellen mellom de klassiske kurvene alene. Nøkkeldelingen som sendes over nettet er derimot nesten identisk i størrelse, rundt 1.216 byte for X25519MLKEM768 mot 1.249 byte for SecP256r1MLKEM768, så nettverksoverhead er ikke det som avgjør valget.
Adopsjonstall fra august 2026 viser at rundt 52 prosent av observert TLS-trafikk nå bruker hybrid ML-KEM-basert nøkkelutveksling, med X25519MLKEM768 som det klart mest brukte alternativet. Ren ML-KEM uten klassisk kurve er ikke standard i noen større nettleser, nettopp fordi hybridmodellen gir et sikkerhetsnett: selv om ML-KEM mot formodning skulle vise seg svak, står den klassiske kurven fortsatt igjen som beskyttelse, og motsatt.
Denne «binde begge sammen»-strategien har en praktisk konsekvens for utviklere: å aktivere hybridgruppen krever ikke at man velger bort den klassiske kurven man allerede stoler på. Et system som i dag kjører ren X25519 kan legge til X25519MLKEM768 som et tillegg i gruppelisten uten å fjerne noe, og vil automatisk falle tilbake til klassisk X25519 for klienter som ennå ikke støtter hybridmodusen. Samme logikk gjelder for et system bygget rundt P-256, der SecP256r1MLKEM768 kan legges til uten å bryte kompatibilitet bakover. Dette gradvise, additive mønsteret er en av grunnene til at adopsjonen har gått raskere enn ved tidligere store TLS-endringer, siden ingen tjeneste har vært tvunget til å velge mellom gammelt og nytt på én gang.
IETF- og NIST-standardene bak kurvene
X25519 er formalisert i RFC 7748 fra IETF, mens grunnlaget for TLS 1.3 som protokoll ligger i RFC 8446. P-256 stammer fra NIST-standarden FIPS 186, som også dekker ECDSA-signering, og kurven inngår i IANAs offisielle liste over «anbefalte» TLS 1.3-grupper sammen med X25519, P-384 og X448.
Denne doble anbefalingen forklarer hvorfor serverprogramvare som lighttpd, i versjon 1.4.77 fra januar 2025, satte gruppelisten til nettopp «X25519:P-256:P-384:X448». Begge kurvene regnes som førsteklasses valg av standardiseringsorganene, men rekkefølgen server- og bibliotekutviklere velger sier mye om hvor bransjen faktisk lener seg. X25519 kommer nesten alltid først når utviklerne selv får bestemme, mens P-256 beholder plassen som nummer to, primært av kompatibilitetshensyn og for miljøer bundet av NIST-godkjente kurver i regelverk som FIPS 140-2/3.
Det er verdt å merke seg at NIST selv ikke har forsøkt å fase ut P-256. Standarden lever videre side om side med anbefalingene om Curve25519 og Curve448 som IETF publiserte gjennom RFC 7748, og de to standardiseringsmiljøene har i praksis konvergert mot en modell der begge kurvefamilier er akseptable, avhengig av kontekst. Det samme mønsteret gjentar seg nå med hybride PQC-grupper: IETF definerer flere varianter i stedet for å velge én vinner, nettopp fordi ulike bransjer og jurisdiksjoner har ulike krav til hvilken klassisk kurve som må inngå.
Priser: hva koster de to kurvene i skyen?
Kurvene i seg selv koster ingenting, men hvilken kurve en tjeneste velger avgjør hvilke administrerte nøkkelhåndteringstjenester som faktisk kan brukes, og det slår ut i fakturaen. AWS KMS støtter ECC_NIST_P256, P384, P521 og SECG_P256K1, og la til Ed25519-signering (ECC_NIST_EDWARDS25519) i 2025. X25519 som eget nøkkelspek er derimot ikke dokumentert i AWS KMS. Google Cloud KMS støtter både EC_SIGN_P256_SHA256 og EC_SIGN_ED25519, men heller ikke her er X25519 oppført som eget algoritmevalg. Azure Key Vault dekker ECC-nøkler under kategorien «avanserte nøkkeltyper», men har ingen dokumentert støtte for verken Ed25519 eller X25519.
Dette skillet overrasker gjerne team som antar at «nyere og raskere» automatisk betyr «tilgjengelig overalt». I praksis er det motsatt for administrerte nøkkeltjenester: P-256 har vært del av skyleverandørenes tilbud siden de første KMS-produktene lanserte for over ti år siden, mens Ed25519 først kom inn i AWS KMS og Google Cloud KMS i løpet av 2025, og X25519 fortsatt mangler helt som eget nøkkelspek hos alle tre store leverandørene. Årsaken handler trolig om at X25519 primært brukes til efemær nøkkelutveksling som genereres på nytt for hver tilkobling, noe som gjør det mindre naturlig å lagre som en langvarig KMS-forvaltet nøkkel sammenlignet med en signeringsnøkkel som skal gjenbrukes over tid.
| Tjeneste | Pris | Støtter P-256 | Støtter Ed25519 | Støtter X25519 |
|---|---|---|---|---|
| AWS KMS | $0,15 per 10.000 asymmetriske operasjoner + $1/mnd per nøkkel | Ja | Ja (fra 2025) | Nei |
| Google Cloud KMS | $0,03 per 10.000 operasjoner + $0,06/mnd per nøkkelversjon | Ja | Ja | Nei |
| Azure Key Vault (avanserte nøkler) | $0,15 per 10.000 transaksjoner | Ja | Nei | Nei |
| Google Cloud HSM | $2,50/mnd per nøkkelversjon (0–2.000), $1,00/mnd derover | Ja | Nei | Nei |
| Let’s Encrypt / offentlige CA-er | Gratis | Ja (standard for ECDSA-sertifikater) | Nei | Ikke aktuelt (kun nøkkelutveksling) |
Det gir et praktisk mønster: skal en tjeneste ha nøkler forvaltet av en administrert sky-KMS eller en offentlig HSM, er P-256 nesten alltid det trygge valget i dag, siden det er den ene kurven alle fire store tjenestene støtter uten unntak. X25519 lever primært på applikasjonsnivå, i selve TLS-håndtrykket, ikke som en lagret nøkkeltype i en sky-tjeneste. Merk også at ingen offentlig sertifikatmyndighet, inkludert Let’s Encrypt, utsteder Ed25519-sertifikater for TLS i produksjon per 2026. RSA og ECDSA på P-256 er fortsatt det som brukes for selve sertifikatet, selv når TLS-håndtrykket bak sertifikatet forhandler X25519 eller en hybridgruppe.
Et regneeksempel gjør prisforskjellen konkret. En tjeneste som utfører 10 millioner signerings- eller verifiseringsoperasjoner med P-256 i måneden gjennom AWS KMS betaler 10.000.000 delt på 10.000 ganger $0,15, altså $150 i måneden, pluss $1 per lagret nøkkel. Samme volum i Google Cloud KMS lander på 10.000.000 delt på 10.000 ganger $0,03, altså $30 i måneden, pluss $0,06 per nøkkelversjon. Siden X25519 ikke er et eget nøkkelspek i noen av disse tjenestene, finnes det ikke noe tilsvarende regnestykke for X25519 alene. All bruk av X25519 skjer i stedet direkte i applikasjonens TLS-stack, uten noen målbar sky-kostnad utover selve compute-tiden, som allerede er lavere enn for P-256 ifølge benchmarkene over.
Fem praktiske brukstilfeller
Valget mellom kurvene handler sjelden om ren kryptografisk styrke, men om hvilket miljø tjenesten skal kjøre i. Under følger fem konkrete situasjoner der svaret peker tydelig i en retning.
- Mobilapper og batteridrevne enheter. Lavere sykkeltall per operasjon betyr mindre strømforbruk per TLS-tilkobling. Apper som gjør hyppige API-kall over mobilnett drar nytte av X25519 sin lavere CPU-kostnad, spesielt på eldre telefonmaskinvare uten AES-NI-lignende akselerasjon for kurveoperasjoner.
- Offentlig sektor og regulerte bransjer. Norske banker, helseforetak og statlige systemer som er bundet av FIPS 140-2/3-sertifisering eller tilsvarende krav, må som regel holde seg til P-256, siden det er kurven som er eksplisitt godkjent i disse rammeverkene og støttet i alle sertifiserte HSM-er. Et anskaffelseskrav som viser til en spesifikk NIST-standard vil nesten alltid peke på P-256 fremfor X25519, rett og slett fordi standarden ble skrevet før Curve25519 fantes som alternativ.
- CDN-er og edge-nettverk. Globale nettverk som terminerer millioner av TLS-tilkoblinger i sekundet velger hybrid X25519MLKEM768 som standard for nye tilkoblinger, nettopp fordi den lille ytelsesgevinsten multipliseres over enormt volum, samtidig som hybridmodellen fremtidssikrer trafikken mot kvantedatamaskiner.
- IoT og innebygde enheter. Med begrenset CPU og minne er X25519 sin enkle, konstant-tids referanseimplementasjon lettere å porte trygt til mikrokontrollere enn en fullverdig P-256-implementasjon med alle spesialtilfeller.
- SSH og VPN. Protokoller som WireGuard og moderne SSH-implementasjoner er bygget rundt X25519 fra bunnen av, både for ytelsen og fordi det reduserer angrepsflaten sammenlignet med en generell elliptisk kurve-bibliotek som må støtte mange kurvetyper samtidig. WireGuard sin protokolldesign lar seg i praksis ikke rekonfigurere til P-256 uten å endre selve protokollspesifikasjonen, siden hele håndtrykket er bygget rundt Curve25519 sine spesifikke egenskaper.
Migreringsguide: fra P-256 til X25519 i produksjon
En migrering handler sjelden om å fjerne P-256 helt, men om å endre rekkefølgen på hvilken kurve som forhandles først. Slik gjør du det uten å bryte kompatibilitet med eldre klienter. Prosessen tar normalt en til to timer for et enkelt system, men overvåkingsperioden i etterkant bør vare i uker, ikke dager, siden trafikkmønstre og gamle klienter ofte varierer gjennom en hel forretningssyklus.
- Kartlegg hvilke klienter som faktisk kobler til tjenesten i dag, og sjekk om noen av dem mangler X25519-støtte. De aller fleste moderne nettlesere og biblioteker fra de siste fem årene støtter begge kurvene.
- Oppdater TLS-konfigurasjonen i webserveren (Nginx, Apache, HAProxy eller tilsvarende) slik at gruppelisten settes til «X25519:P-256:P-384», med X25519 først. Behold P-256 i listen for å unngå å stenge ute eldre klienter.
- Test håndtrykket med verktøy som
openssl s_client -groups X25519for å bekrefte at serveren faktisk forhandler X25519 når klienten tilbyr det. - Verifiser at eventuell sky-KMS eller HSM som er koblet til sertifikatets private nøkkel fortsatt bruker P-256 eller RSA, siden dette er separat fra hvilken kurve TLS-håndtrykket forhandler.
- Oppgrader TLS-biblioteket til en versjon som støtter hybrid nøkkelutveksling, som OpenSSL 3.5 eller nyere, hvis tjenesten skal forberedes for post-kvantesikkerhet.
- Aktiver hybridgruppen X25519MLKEM768 ved siden av klassisk X25519, slik at klienter som støtter post-kvantesikker nøkkelutveksling får det automatisk, mens eldre klienter faller tilbake til klassisk X25519 eller P-256.
- Overvåk feilrater og håndtrykkstatistikk i minst to uker etter endringen. En brå økning i TLS-feil kan tyde på at et internt system eller en gammel klient ikke støtter den nye gruppelisten.
- Dokumenter endringen i tjenestens sikkerhetsarkitektur, spesielt hvis tjenesten er underlagt revisjon eller compliance-krav som eksplisitt nevner godkjente kurver.
Kodeeksempelet under viser en typisk Nginx-konfigurasjon som prioriterer X25519 og hybrid nøkkelutveksling foran P-256, uten å fjerne kompatibilitet.
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:P-256:P-384;
ssl_prefer_server_ciphers off;Samme prinsipp gjelder uansett hvilken webserver eller lastbalanserer som er i bruk. HAProxy, Apache og de fleste moderne API-gatewayer har tilsvarende direktiver for å sette rekkefølgen på TLS-grupper, og syntaksen ligner ofte på Nginx-eksempelet over selv om nøyaktig direktivnavn varierer. Det viktigste er ikke hvilket verktøy som konfigureres, men at rekkefølgen testes eksplisitt etterpå i stedet for å anta at endringen virker som forventet.
Fordeler og ulemper
Ingen av kurvene er et universelt riktig valg. Listen under samler opp funnene fra hele sammenligningen i en kortversjon, tenkt som en sjekkliste når et team skal begrunne valget sitt overfor en arkitektkomité eller en revisor.
X25519, fordeler:
- Opptil dobbelt så raskt i mikrobenchmarks, og 8–14 prosent raskere målt i faktisk tilkoblingsgjennomstrømning.
- Enklere å implementere trygt, med lavere risiko for sidekanallekkasjer i praksis.
- Standard i moderne biblioteker og protokoller som WireGuard, SSH og de fleste nettlesere.
- Danner grunnlaget for X25519MLKEM768, den mest brukte hybride post-kvantegruppen i 2026.
X25519, ulemper:
- Ikke støttet som eget nøkkelspek i AWS KMS, Google Cloud KMS eller Azure Key Vault.
- Ikke godkjent for offentlige TLS-sertifikater hos Let’s Encrypt eller andre store CA-er.
- Mangler formell plass i enkelte eldre FIPS-baserte compliance-rammeverk.
P-256, fordeler:
- Støttet i praktisk talt alle sky-KMS-tjenester, HSM-er og offentlige sertifikatmyndigheter.
- Kreves eller anbefales eksplisitt i mange regulerte bransjer og offentlige anskaffelser.
- Moden, godt revidert kodebase i store TLS-biblioteker etter to tiår i produksjon.
P-256, ulemper:
- Målbart tregere enn X25519 i alle tre benchmark-kildene over.
- Weierstrass-formen krever flere spesialtilfeller i implementasjonen, noe som historisk har ført til sårbarheter i enkelte biblioteker.
- Den tilhørende hybridgruppen SecP256r1MLKEM768 er målbart tregere enn X25519MLKEM768 i 2025-studiet nevnt over.
Verdikt: hvilken kurve bør du velge?
For de fleste nye webtjenester, mobilapper og interne systemer er svaret X25519, satt først i gruppelisten med P-256 som fallback for eldre klienter. Tallene er entydige: 8 til 14 prosent høyere gjennomstrømning i reelle serverbenchmarks, og opptil dobbelt så rask kurveoperasjon i mikrobenchmarks, uten at det koster noe i sikkerhet. Kombinert med hybridgruppen X25519MLKEM768, som allerede står for majoriteten av de 52 prosent hybride TLS-håndtrykk observert i august 2026, er X25519 også den kurven som peker fremover mot en post-kvantesikker verden.
P-256 forblir riktig valg når en sky-KMS, HSM eller offentlig sertifikat er involvert, siden det fortsatt er den eneste av de to kurvene som er universelt støttet i AWS KMS, Google Cloud KMS, Azure Key Vault og hos alle store CA-er. De to kurvene utelukker ikke hverandre. De fleste produksjonssystemer i 2026 bruker faktisk begge samtidig, X25519 i selve TLS-håndtrykket og P-256 eller RSA bak sertifikatets signatur, og det er trolig den mest fremtidsrettede kombinasjonen frem til hybride post-kvantegrupper er like modne som de klassiske kurvene er i dag.
Den bredere linjen er den samme som går igjen i resten av kryptografifaget: klassiske algoritmer fases sjelden ut brått, de legges i lag oppå hverandre inntil det nye laget har bevist seg over tid. Har du ikke satt deg inn i hvordan denne samme logikken gjelder for gitterbasert nøkkelutveksling generelt, er det en god start å lese gjennomgangen av ML-KEM mot RSA, eller kryptografi-arkivet for en bredere oversikt over hashfunksjoner og digital tillit.
Det korte svaret, oppsummert i ett avsnitt: prioriter X25519 i TLS-håndtrykket der biblioteket tillater det, aktiver hybridgruppen X25519MLKEM768 hvis stacken støtter post-kvantesikkerhet, behold P-256 som fallback for eldre klienter, og bruk P-256 eller RSA der en sky-KMS, HSM eller offentlig sertifikat er en del av kjeden. Ingen andre kombinasjoner gir like god dekning av både ytelse, kompatibilitet og fremtidig kvantesikkerhet med dagens verktøy.
Ofte stilte spørsmål
Er X25519 sikrere enn P-256?
Begge gir omtrent 128-bit klassisk sikkerhet, så den ene er ikke matematisk sikrere enn den andre mot kjente klassiske angrep. Forskjellen ligger i implementasjonsrisiko, der X25519 sin designfilosofi gjør det vanskeligere å introdusere sidekanalsårbarheter ved en feil i koden.
Kan jeg bruke X25519 til å signere sertifikater?
Nei. X25519 er kun designet for nøkkelutveksling. Signering på samme kurvefamilie gjøres med Ed25519, men offentlige sertifikatmyndigheter som Let’s Encrypt utsteder ikke Ed25519-sertifikater for TLS i produksjon per 2026, så P-256 eller RSA må fortsatt brukes til selve sertifikatet.
Hvorfor støtter ikke AWS KMS X25519?
AWS KMS støtter i dag ECC_NIST_P256, P384, P521, SECG_P256K1 og Ed25519 for signering, men har ikke lagt til X25519 som eget nøkkelspek. Siden X25519 hovedsakelig brukes direkte i TLS-håndtrykket fremfor som en lagret KMS-nøkkel, er behovet mindre presserende enn for signeringsalgoritmer.
Hva er forskjellen mellom X25519MLKEM768 og SecP256r1MLKEM768?
Begge er hybride TLS 1.3-grupper som kombinerer ML-KEM-768 med en klassisk kurve, X25519 i det ene tilfellet og P-256 i det andre. X25519-varianten er raskere i målte studier, mens P-256-varianten finnes for miljøer som må holde seg til NIST-godkjente kurver.
Må jeg bytte kurve før kvantedatamaskiner blir en reell trussel?
Det haster mest for data som må forbli hemmelig i mange år fremover, siden en angriper kan lagre kryptert trafikk i dag og dekryptere den senere når en tilstrekkelig kraftig kvantedatamaskin finnes. Dette kalles gjerne «høst nå, dekrypter senere», og det er spesielt relevant for helsedata, forretningshemmeligheter og myndighetskommunikasjon med lang levetid. For slik trafikk bør hybridgrupper som X25519MLKEM768 aktiveres nå, ikke vente til kvantetrusselen er akutt.
Påvirker valget av kurve nettsidens lastetid merkbart?
For en enkelt bruker, nesten ikke. Studier viser forskjeller på 0,1 til 0,9 millisekunder i selve håndtrykket. Forskjellen blir først merkbar i stor skala, hos tjenester som håndterer millioner av tilkoblinger i sekundet, der selv brøkdeler av et millisekund per håndtrykk multipliseres til betydelig CPU- og strømforbruk. For de fleste norske virksomheter, som håndterer et langt lavere trafikkvolum enn globale CDN-er, bør derfor kurvevalg først og fremst styres av compliance-krav og biblioteksstøtte, ikke av jakten på millisekunder.
Kan begge kurvene brukes samtidig i samme tjeneste?
Ja, og det er faktisk vanlig praksis. En moderne TLS-konfigurasjon lister gjerne opp både X25519 og P-256 i prioritert rekkefølge, slik at serveren forhandler den raskeste kurven klienten støtter, samtidig som eldre klienter som kun kjenner P-256 fortsatt kan koble til.
Hvilken kurve bruker norske offentlige tjenester i dag?
Systemer underlagt strenge sertifiseringskrav, som helsesektoren og finansnæringen, holder seg oftest til P-256, siden det er kurven som er eksplisitt dekket av FIPS 140-2/3 og tilsvarende rammeverk brukt i offentlige anskaffelser. Nyere, mindre regulerte tjenester velger i økende grad X25519 først i gruppelisten, med P-256 som fallback, samme mønster som i resten av bransjen internasjonalt.
