Nesten hvert eneste HTTPS-oppslag i nettleseren din i dag hviler på en elliptisk kurve. To av de mest brukte, NIST P-256 og NIST P-384, dukker opp overalt fra bankenes API-er til statlige PKI-hierarkier, men de færreste utviklere har faktisk sammenlignet dem tall mot tall. Denne artikkelen går gjennom sikkerhetsnivå, ytelse, pris i skyen og reell bruk, med tall fra offentlige benchmarker og gjeldende standarder, slik at du kan velge riktig kurve for prosjektet ditt i 2026.
Mange utviklere arver kurvevalget fra et standardoppsett i OpenSSL, en Certbot-installasjon eller en skytjenestes forhåndsvalgte innstilling, uten å tenke over hva valget faktisk koster i CPU-tid eller hva det gir i sikkerhetsmargin. Denne guiden går i dybden på begge kurvene: fra den matematiske forskjellen mellom et 256-bits og et 384-bits primtallsfelt, til konkrete kommandoer for å sjekke hvilken kurve et eksisterende sertifikat bruker, og en fullstendig migreringsplan for team som må bytte.
P-256 vs P-384: hvorfor valget av NIST-kurve fortsatt betyr noe i 2026
Elliptisk kurve-kryptografi (ECC) driver størstedelen av dagens TLS-håndtrykk, kodesignering og sertifikatutstedelse. ECC bygger sikkerheten sin på hvor vanskelig det er å løse det diskrete logaritme-problemet på en elliptisk kurve, og NIST publiserte de første standardiserte kurvene allerede på slutten av 1990-tallet. P-256 og P-384 er to av tre “prime”-kurver som fortsatt regnes som gjeldende standard, ved siden av P-521.
Valget mellom dem er ikke akademisk. Et team som setter opp TLS-terminering, en signeringstjeneste for programvare eller en HSM-integrasjon i AWS, Azure eller Google Cloud, må faktisk bestemme seg for en kurve, og den beslutningen påvirker ytelse, kompatibilitet og hvilke compliance-krav systemet oppfyller. CA/Browser Forums Baseline Requirements tillater begge kurvene for offentlig tiltrodde sertifikater, så valget faller i praksis på utvikleren eller sikkerhetsarkitekten.
Samtidig pågår en parallell diskusjon om kvantesikker kryptografi. Ingen av kurvene tåler et tilstrekkelig kraftig kvantedatamaskin, men det endrer ikke at P-256 og P-384 fortsatt dekker nesten all klassisk TLS-trafikk gjennom hele 2026. Denne artikkelen sammenligner dem direkte: sikkerhetsmargin, signeringshastighet, sertifikatstøtte, skypriser og en konkret migreringsguide for team som vurderer å bytte.
Hva er P-256 og P-384? De grunnleggende forskjellene
P-256, også kjent under navnet secp256r1 eller prime256v1, er en Weierstrass-kurve over et primtallsfelt på 256 bit. P-384 (secp384r1) er den samme kurvetypen, men bygget over et felt på 384 bit. Begge er definert i NISTs standard FIPS 186-5, som er den gjeldende versjonen av Digital Signature Standard, og begge er også beskrevet i SEC 2-spesifikasjonen fra Standards for Efficient Cryptography Group.
Den praktiske forskjellen ligger i størrelsen på primtallsmodulusen p, som avgjør hvor vanskelig det er å løse det underliggende matematiske problemet. Jo større felt, desto flere regneoperasjoner kreves for både angriper og legitim bruker. Det gir P-384 et høyere sikkerhetsnivå, men til en pris: hver signering og verifisering krever mer CPU-tid.
FIPS 186-5 fra 2023 var også første gang NIST tok inn Edwards-kurvene Ed25519 og Ed448 i standarden ved siden av de klassiske Weierstrass-kurvene. P-256 og P-384 beholdt likevel plassen sin som de mest brukte valgene i offentlig Web PKI, delvis fordi de har vært tilgjengelige i nesten alle TLS-biblioteker og HSM-er i over et tiår.
Navngivningen kan forvirre nykommere: NIST kaller kurvene P-256 og P-384, mens ANSI X9.62-standarden og OpenSSL bruker navnene prime256v1 og secp384r1 for nøyaktig de samme matematiske parameterne. Det er ikke tre forskjellige kurver, bare tre navn på det samme objektet fra tre ulike standardiseringsorganisasjoner. Når du kjører “openssl ecparam -list_curves”, vil du derfor se prime256v1 og secp384r1 i listen, ikke P-256 og P-384, selv om det er nøyaktig de samme kurvene sertifikatindustrien omtaler med NIST-navnene.
Sikkerhetsnivå: 128 mot 192 bit forklart
P-256 gir et klassisk sikkerhetsnivå på omtrent 128 bit, mens P-384 gir omtrent 192 bit. Tallene tilsvarer grovt sett styrken til AES-128 og AES-192, og de beskriver hvor mange operasjoner en angriper trenger for å knekke kurven med dagens beste kjente algoritmer. Sikkerhetsnivået er ikke det samme som feltstørrelsen i bit, det er en separat beregning basert på gruppens orden.
Verken P-256 eller P-384 tåler Shors algoritme på en tilstrekkelig kraftig kvantedatamaskin. Begge faller i samme kategori som RSA når det gjelder kvantesårbarhet, og ingen av dem regnes som post-kvante kryptografi. Prosjektet SafeCurves, som evaluerer elliptiske kurver mot en rekke sikkerhetskriterier utover ren nøkkelstørrelse, har i årevis pekt på at klassisk sikkerhetsnivå bare er ett av flere kriterier å vurdere ved kurvevalg.
For de fleste kommersielle systemer holder 128-bits sikkerhet lenge, og det er derfor P-256 dominerer offentlig TLS. Der kravene er strengere, typisk i statlig sektor, forsvarsrelaterte systemer eller organisasjoner med lange oppbevaringskrav for signerte data, gir 192-bits margin ekstra trygghet mot fremtidige forbedringer i klassiske angrepsalgoritmer.
Det finnes også en tredje NIST-kurve i samme familie, P-521, med et sikkerhetsnivå på omtrent 256 bit. Den er godkjent i CA/Browser Forums Baseline Requirements på lik linje med P-256 og P-384, men brukes langt sjeldnere i offentlig Web PKI fordi ytelseskostnaden er enda høyere, uten at de fleste trusselmodeller krever den ekstra marginen. P-521 havner dermed mest i nisjer med svært strenge krav, mens den reelle konkurransen i praksis står mellom P-256 og P-384.
Ytelse: signering, verifisering og nøkkelgenerering
Ytelsesforskjellen mellom P-256 og P-384 er betydelig, og den øker med feltstørrelsen. Et offentlig tilgjengelig benchmark fra biblioteket Mirage Crypto viser følgende gjennomstrømning i ett og samme testmiljø:
| Operasjon | P-256 | P-384 | Forskjell |
|---|---|---|---|
| Nøkkelgenerering | 19 365 op/sek | 6 703 op/sek | 2,9x raskere med P-256 |
| Signering | 7 436 op/sek | 3 061 op/sek | 2,4x raskere med P-256 |
| Verifisering | 1 488 op/sek | 544 op/sek | 2,7x raskere med P-256 |
Tallene kommer fra Mirage Crypto sin endringslogg og gjelder ett spesifikt testoppsett, ikke en universell målestokk for alle prosessorer og biblioteker. En separat kilde knyttet til OpenSSLs benchmark-verktøy openssl speed oppgir P-256-signering i området 12 000 til 17 000 operasjoner i sekundet i sitt eget miljø, mens P-384 der lå på rundt 900 signeringer og 1 062 verifiseringer per sekund. Fordi maskinvare, kompilator og OpenSSL-versjon varierer mellom disse målingene, bør du alltid kjøre din egen benchmark på faktisk produksjonsmaskinvare før du velger kurve til en høyfrekvent tjeneste.
Mønsteret er likevel konsistent på tvers av kildene: P-256 er raskere enn P-384 i alle tre operasjonene, typisk med en faktor på 2 til 3 ganger. For et API som signerer titusener av forespørsler per sekund, utgjør det en reell forskjell i antall servere du trenger. For en tjeneste som utsteder noen få sertifikater om dagen, er forskjellen i praksis usynlig for sluttbrukeren.
Årsaken til at ytelsesgapet vokser raskere enn feltstørrelsen skulle tilsi, ligger i hvordan punktmultiplikasjon på en elliptisk kurve fungerer. Hver signering og verifisering krever en rekke gjentatte punktadisjoner og punktdoblinger over det underliggende feltet, og kostnaden per operasjon øker mer enn lineært med antall bit i modulusen. Det er derfor P-384, med halvannen gang så mange bit som P-256, ender opp med en ytelseskostnad på 2 til 3 ganger, ikke bare 1,5 ganger. Moderne CPU-er med dedikert instruksjonssett for store heltallsoperasjoner reduserer forskjellen noe, men fjerner den ikke.
Slik bruker nettet ECDSA-sertifikater i dag
To uavhengige målinger gir et bilde av hvor mye av det offentlige nettet som faktisk bruker ECDSA fremfor RSA. Et utvalg fra SecureMonk i september 2026 talte 2 482 nettsteder med ECDSA-sertifikater, tilsvarende 49,3 prosent, mot 2 427 nettsteder med RSA, tilsvarende 48,2 prosent, og pekte på P-256 som den klart vanligste nøkkeltypen i utvalget. En analyse fra Technology Checker basert på Cloudflare Radar-data for sertifikattransparens rapporterte en ECDSA-andel på 49,7 prosent i juli 2026, opp fra 34,5 prosent i fjerde kvartal 2025 til 42,9 prosent i første kvartal 2026.
| Kilde | Periode | ECDSA-andel | RSA-andel |
|---|---|---|---|
| SecureMonk-utvalg | September 2026 | 49,3 % (2 482 nettsteder) | 48,2 % (2 427 nettsteder) |
| Technology Checker / Cloudflare Radar | Juli 2026 | 49,7 % | 50,3 % |
| Technology Checker / Cloudflare Radar | Q4 2025 → Q1 2026 | 34,5 % → 42,9 % | – |
Ingen av kildene skiller pålitelig mellom P-256- og P-384-andelen innenfor ECDSA-tallene, men begge peker i samme retning: P-256 er standardvalget for offentlige sertifikater, mens P-384 fortsatt er tilgjengelig og brukt, bare i mindre skala. Merk også at “bruker P-384” kan bety flere ulike ting i praksis: at selve sertifikatets offentlige nøkkel er P-384, at CA-en signerer med ECDSA P-384, eller at TLS-håndtrykket bruker en midlertidig ECDHE P-384-nøkkel. Disse tre egenskapene kan variere uavhengig av hverandre i samme forbindelse.
CA/Browser Forum, Let’s Encrypt og sertifikatutstedere
CA/Browser Forums Baseline Requirements, reglene som styrer alle offentlig tiltrodde sertifikatutstedere, godkjenner P-256, P-384 og P-521 for TLS-sertifikater. Det betyr at valget av kurve ikke begrenses av selve reglementet, men av hva den enkelte CA faktisk tilbyr, og hva kunden ber om i sin sertifikatforespørsel (CSR).
Let’s Encrypt, som utsteder gratis sertifikater til en stor andel av nettet, tilbyr både RSA og ECDSA med P-256 og P-384, men tilbyr foreløpig ikke Ed25519 for offentlig tiltrodde sertifikater. Andre store CA-er, blant dem DigiCert, Sectigo, Entrust og Google Trust Services, støtter også ECC generelt gjennom sine utstedelsesprofiler. I praksis velger den som sender inn CSR-en hvilken kurve som skal brukes, så mangfoldet i faktisk bruk avhenger av standardinnstillingene i verktøyene utviklerne bruker, som Certbot, ACME-klienter og interne PKI-systemer.
Store CDN-er og skyleverandører som Cloudflare, AWS og Microsoft Azure støtter begge kurvene i sine edge-nettverk og lastbalanserere. Cloudflares dokumentasjon over cipher suites viser ECDSA-baserte suiter som en del av standardoppsettet for TLS-terminering, noe som gjenspeiler hvor utbredt støtten for både P-256 og P-384 er blitt i moderne infrastruktur.
Nettlesere, operativsystemer og TLS-biblioteker: støtte i praksis
Kompatibilitet er sjelden problemet når du velger mellom P-256 og P-384 i 2026. Begge kurvene har vært en del av TLS-standarden siden TLS 1.2, og RFC 8446 viderefører støtten inn i TLS 1.3 ved å liste secp256r1 og secp384r1 som offisielt støttede grupper for nøkkelutveksling. Alle moderne nettlesere, deriblant Chrome, Firefox, Safari og Edge, håndterer begge kurvene uten ekstra konfigurasjon, og det samme gjelder de vanligste TLS-bibliotekene: OpenSSL, BoringSSL, LibreSSL, Rustls og Go sitt innebygde crypto/tls-pakke.
Utfordringen dukker først opp i randsonene: eldre Android-versjoner, enkelte innebygde systemer med minimalistiske TLS-stakker, og eldre Java-versjoner uten oppdaterte cryptography providers kan mangle god støtte for P-384, spesielt i kombinasjon med bestemte cipher suites. Før du velger P-384 for en tjeneste med et bredt og ukjent spekter av klienter, bør du kartlegge hvilke klienttyper som faktisk kobler seg til, og teste håndtrykket mot dem. For interne systemer der du kontrollerer begge ender av forbindelsen, er dette sjelden et problem i det hele tatt.
Operativsystemenes native kryptografibiblioteker, som Windows CNG, Apples CryptoKit og Linux sin OpenSSL/GnuTLS-stack, har alle støttet begge kurvene i mange år. Det betyr at nesten ingen moderne serverinfrastruktur har en teknisk begrensning som tvinger frem P-256 fremfor P-384, eller omvendt. Valget er derfor i praksis et spørsmål om ytelseskrav og sikkerhetspolicy, ikke om hva plattformen tillater.
Slik sjekker du hvilken kurve et sertifikat bruker
Før du planlegger en migrering, bør du kartlegge hvilken kurve som faktisk er i bruk i dag. OpenSSL gjør dette raskt, både for et eksisterende sertifikat på disk og for et sertifikat servert live over TLS.
# Sjekk kurven i et lokalt sertifikat
openssl x509 -in sertifikat.pem -noout -text | grep -A2 "Public Key Algorithm"
# Sjekk kurven i et sertifikat servert live over TLS
openssl s_client -connect eksempel.no:443 -servername eksempel.no /dev/null \
| openssl x509 -noout -text | grep -A2 "Public Key Algorithm"
# Kort oppsummering av kurvenavn og nøkkelstørrelse
openssl x509 -in sertifikat.pem -noout -pubkey \
| openssl pkey -pubin -text -noout | head -5Utdataen viser enten “prime256v1” (P-256) eller “secp384r1” (P-384) som kurvenavn, sammen med nøkkelstørrelsen i bit. Kjør denne sjekken mot alle produksjonsdomener før du planlegger en migrering, siden det ikke er uvanlig at ulike team i samme organisasjon har valgt forskjellige kurver over tid uten en felles standard.
NSA CNSA 2.0 og amerikanske sikkerhetskrav
NSAs Commercial National Security Algorithm Suite, kjent som CNSA 2.0, legger opp til at nettlesere, servere og skytjenester skal støtte og foretrekke CNSA 2.0-algoritmer innen 2025, og bruke dem utelukkende innen 2033. Suiten er i hovedsak en overgangsplan mot post-kvante algoritmer som ML-KEM og ML-DSA, og den signaliserer at klassisk ECC, inkludert P-256 og P-384, på sikt skal fases ut av høysikkerhetssystemer i amerikansk offentlig sektor.
En sekundærkilde knyttet til NIST IR 8547 hevder at ECDSA og ECDH anbefales utfaset etter 2030 og forbys for amerikansk statlig bruk etter 2035. Dette bør leses som en retningslinje under utvikling snarere enn en ferdig vedtatt frist, og organisasjoner som planlegger langsiktige PKI-investeringer bør sjekke NISTs offisielle publikasjoner direkte før de legger en migreringsplan. Poenget for de fleste ikke-amerikanske virksomheter er likevel klart: tidslinjen for CNSA 2.0 er en indikator på hvor bransjen beveger seg, selv om den formelt bare gjelder amerikanske myndighetssystemer.
I praksis betyr dette at et valg av P-384 i dag ikke er en fremtidssikker løsning i seg selv. Det gir en høyere klassisk sikkerhetsmargin enn P-256, men begge kurvene havner til slutt i samme bøtte når kvanteresistente algoritmer blir obligatoriske. Team som bygger nye systemer nå, bør derfor vurdere hybride løsninger som kombinerer klassisk ECC med post-kvante nøkkelutveksling, fremfor å se valget mellom P-256 og P-384 som en permanent avgjørelse.
FIPS 186-5 og NIST-standardene
FIPS 186-5 er den gjeldende Digital Signature Standard fra NIST og definerer hvilke kurver og signaturalgoritmer som er godkjent for amerikansk statlig bruk, deriblant ECDSA med P-256, P-384 og P-521. Standarden fastsetter også krav til nøkkelgenerering, validering av signaturer og bruk av deterministiske eller godkjente metoder for å generere den tilfeldige verdien k som brukes i hver ECDSA-signatur.
En sentral endring i FIPS 186-5 sammenlignet med tidligere versjoner er at Edwards-kurvene Ed25519 og Ed448 nå er offisielt godkjent ved siden av de tradisjonelle NIST-kurvene. Det gir utviklere et tredje alternativ utenfor P-256/P-384-familien, men adopsjonen i offentlig Web PKI henger fortsatt etter fordi Let’s Encrypt og de fleste andre store CA-er ennå ikke utsteder Ed25519-sertifikater til vanlige nettsteder.
For team som må dokumentere compliance, er FIPS 186-5 fortsatt referansepunktet å vise til når en revisor spør hvilken standard som ligger til grunn for valget av P-256 eller P-384. Standarden er teknologinøytral i den forstand at den ikke pålegger den ene kurven over den andre, den fastsetter bare hvilke som er godkjente, og overlater selve valget til organisasjonens risikovurdering.
Et praktisk poeng mange oversér: selve ECDSA-signaturen krever en tilfeldig verdi, k, for hver signering. Genereres denne verdien svakt eller gjenbrukes den, kan en angriper i verste fall regne ut hele privatnøkkelen, uavhengig av om kurven er P-256 eller P-384. Moderne biblioteker løser dette med deterministisk ECDSA etter RFC 6979, som utleder k fra meldingen og privatnøkkelen i stedet for å stole på en tilfeldighetsgenerator. Sjekk at biblioteket eller HSM-en din faktisk bruker en godkjent metode for k-generering, uansett hvilken kurve du velger, siden en svak implementasjon her er en langt mer realistisk risiko i praksis enn selve valget mellom 128 og 192 bits sikkerhetsnivå.
Skytjenester: pris for P-256- og P-384-nøkler
En av de mest praktiske funnene i denne sammenligningen er at ingen av de store skyleverandørene tar mer betalt for P-384 enn for P-256. Prisen bestemmes av nøkkeltype (symmetrisk eller asymmetrisk) og lagringsklasse (programvare eller HSM), ikke av hvilken NIST-kurve du velger innenfor ECC-kategorien.
| Tjeneste | Nøkkellagring | Pris per operasjon | Prisforskjell P-256 vs P-384 |
|---|---|---|---|
| AWS KMS | 1 USD per nøkkel per måned | 0,15 USD per 10 000 asymmetriske forespørsler | Ingen forskjell |
| Google Cloud KMS (programvare) | 0,06 USD per nøkkelversjon per måned | 0,15 USD per 10 000 operasjoner | Ingen forskjell |
| Google Cloud HSM | 2,50 USD per nøkkelversjon per måned (første 2 000), deretter 1,00 USD | Inkludert i nøkkelprisen | Ingen forskjell, begge kurver i samme kategori |
| Azure Key Vault | Avhenger av tier (Standard/Premium/Managed HSM) | Fakturert per 10 000 transaksjoner | Eksakt beløp varierer per region, ikke separat prissatt per kurve |
AWS oppgir eksplisitt at den faste månedsavgiften på 1 dollar per nøkkel gjelder likt for symmetriske, asymmetriske, HMAC-baserte og importerte nøkler, uavhengig av hvilken kurve eller algoritme som ligger bak. Google Cloud grupperer EC P-256 og EC P-384 sammen i samme prisrad for både programvarebaserte nøkler og HSM-nøkler. Azure Key Vault fakturerer ECC-operasjoner som “avanserte nøkkeltyper” per 10 000 transaksjoner, men prisdokumentasjonen skiller heller ikke der mellom kurvene.
Den praktiske konsekvensen er at kostnad ikke bør være avgjørende når du velger mellom P-256 og P-384 i skyen. Den reelle kostnaden ligger i CPU-tid ved høyt volum og i kompatibilitet med eldre klienter, ikke i selve prislappen fra skyleverandøren.
Det som derimot varierer kraftig i pris, er valget mellom programvarebaserte nøkler og HSM-beskyttede nøkler. Google Cloud HSM koster over 40 ganger mer per nøkkelversjon enn den programvarebaserte varianten (2,50 dollar mot 0,06 dollar i utgangspunktet), og lignende forhold gjelder hos AWS CloudHSM og Azure Managed HSM sammenlignet med deres standard nøkkeltjenester. For de fleste team er derfor spørsmålet om nøkkelen skal ligge i en HSM av compliance-hensyn en langt større budsjettbeslutning enn om den skal være P-256 eller P-384.
Full spesifikasjonstabell: P-256 mot P-384
| Egenskap | P-256 (secp256r1) | P-384 (secp384r1) |
|---|---|---|
| NIST-betegnelse | NIST P-256 | NIST P-384 |
| Feltstørrelse | 256 bit | 384 bit |
| Klassisk sikkerhetsnivå | ~128 bit | ~192 bit |
| Privat nøkkelstørrelse | 32 byte | 48 byte |
| Offentlig nøkkel (ukomprimert) | 65 byte | 97 byte |
| ECDSA-signatur (rå r||s) | Opptil 64 byte | Opptil 96 byte |
| Definert i | FIPS 186-5, SEC 2 | FIPS 186-5, SEC 2 |
| Godkjent av CA/Browser Forum | Ja | Ja |
| Støttet i TLS 1.3 (RFC 8446) | Ja (secp256r1) | Ja (secp384r1) |
| Let’s Encrypt-utstedelse | Ja | Ja |
| Signeringshastighet (relativ) | Basis | ~2,4x tregere |
| Vanligste bruk i Web PKI | Standardvalg for de fleste nettsteder | Systemer med høyere sikkerhetsmarginkrav |
Tabellen oppsummerer hvorfor de to kurvene sjelden konkurrerer direkte om samme bruksområde. P-256 vinner på hastighet og utbredt kompatibilitet, mens P-384 vinner på sikkerhetsmargin per nøkkelbit. RFC 8446, spesifikasjonen for TLS 1.3, lister begge kurvene som støttede grupper for nøkkelutveksling, så protokollnivået legger ingen begrensninger i veien for noen av dem.
Signaturstørrelse og båndbredde i TLS-håndtrykket
Den andre kostnaden ved P-384, utover ren CPU-tid, er størrelsen på nøkler og signaturer. En rå ECDSA-signatur med P-256 er opptil 64 byte (r og s på 32 byte hver), mens den tilsvarende P-384-signaturen er opptil 96 byte. Legger man til ASN.1 DER-koding, som TLS og X.509-sertifikater faktisk bruker, øker begge tallene noe, men forholdet mellom dem holder seg stabilt. Samme mønster gjelder den offentlige nøkkelen: 65 byte ukomprimert for P-256 mot 97 byte for P-384.
For et enkelt TLS-håndtrykk er forskjellen på noen titalls byte irrelevant. Den blir mer synlig i systemer som utfører tusenvis av håndtrykk i sekundet over trege eller mobile nettverk, der hver ekstra byte i det første pakkeutvekslingen kan bety et ekstra rundturssegment på svake forbindelser. IoT-enheter og innebygde systemer med begrenset minne til sertifikatlagring er også et sted der de mindre nøklene og signaturene til P-256 gir en konkret praktisk fordel, utover selve regnekraften. For vanlige nettsteder og API-er betyr denne forskjellen i praksis ingenting sammenlignet med selve CPU-kostnaden diskutert i ytelsesdelen over.
Seks virkelige bruksområder for hver kurve
Følgende eksempler er hentet fra dokumentert, navngitt bruk av de to kurvene i faktiske systemer og standarder:
- Let’s Encrypt utsteder gratis TLS-sertifikater med både P-256 og P-384 til millioner av nettsteder, og er trolig den enkeltstående CA-en som påvirker flest nettsteders kurvevalg globalt.
- CA/Browser Forums Baseline Requirements setter rammene for alle offentlig tiltrodde sertifikater og tillater eksplisitt P-256, P-384 og P-521, noe som gjør begge kurvene til gyldige valg for enhver kommersiell CA.
- AWS KMS, Google Cloud KMS og Azure Key Vault tilbyr begge kurvene til identisk pris, og brukes av tusenvis av virksomheter til TLS-terminering, kodesignering og API-autentisering.
- Historiske CNSA-profiler fra NSA har lagt vekt på sterkere elliptiske kurveparametere enn vanlige kommersielle TLS-standardinnstillinger, noe som har gjort P-384 til et vanlig valg i høysikkerhets-HSM-er og smartkort beregnet for myndighetsbruk.
- TLS 1.3, spesifisert i RFC 8446, definerer secp256r1 og secp384r1 som støttede grupper for nøkkelutveksling, og nesten alle moderne nettlesere og servere støtter begge som en del av standard TLS-stakken.
- Cloudflares edge-nettverk dokumenterer ECDSA-baserte cipher suites som en del av standardkonfigurasjonen for TLS-terminering på tvers av et stort antall nettsteder som ligger bak tjenesten.
Et viktig forbehold: at en organisasjon eller standard støtter eller tillater en kurve, betyr ikke at hver eneste sertifikat eller nøkkel faktisk bruker den. Det faktiske kurvevalget for en gitt CSR bestemmes som regel av abonnenten, altså den som genererer nøkkelparet, ikke av CA-en som signerer sertifikatet. Det er også grunnen til at et enkelt selskap kan ha en blanding av P-256 og P-384 på tvers av forskjellige tjenester, avhengig av hvilket team som satte opp den enkelte integrasjonen og hvilken standard de fulgte på tidspunktet.
Migrasjonsguide: fra P-256 til P-384 i 12 steg
En kurvemigrering er alltid en full nøkkel- og sertifikatutrulling, aldri en in-place konvertering. Du kan ikke omgjøre en eksisterende P-256-privatnøkkel til P-384, du må generere et helt nytt nøkkelpar. Behandle derfor migreringen som en vanlig sertifikatrotasjon med et ekstra steg: å bekrefte at hele kjeden av klienter, proxyer og overvåkingsverktøy faktisk forstår den nye kurven før den gamle nøkkelen trekkes tilbake. Slik gjør du det trygt:
- Kartlegg alle berørte systemer: TLS-terminering, lastbalanserere, API-er, service mesh, mTLS-klienter, kodesignering, HSM-er og skynøkler.
- Sjekk hvilke klienter og biblioteker som faktisk støtter secp384r1, spesielt eldre Java-, .NET- og innebygde systemer.
- Bestem omfanget: bytter du kun servernøkkelen, hele mTLS-oppsettet, eller også CA-ens signeringsnøkkel?
- Generer den nye P-384-nøkkelen på riktig plattform, for eksempel med OpenSSL, AWS KMS, Azure Key Vault eller Google Cloud KMS.
- Registrer nøkkel-ID, opprettelsestidspunkt, plassering, tillatte operasjoner og roteringsplan i et sentralt register.
- Generer en ny CSR fra P-384-nøkkelen og bekreft at CA-en du bruker faktisk støtter kurven i sertifikatprofilen sin.
- Kontroller at Subject Alternative Names, nøkkelbruk og gyldighetsperiode i den nye CSR-en matcher kravene dine.
- Konfigurer HSM- eller KMS-integrasjonen til å peke på den nye nøkkelen fremfor å endre den gamle.
- Rull ut det nye sertifikatet i et testmiljø først, og verifiser TLS-håndtrykk direkte og gjennom lastbalanserere, WAF-er og proxyer.
- Gjør en gradvis produksjonsutrulling via en liten kanari-gruppe, og overvåk håndtrykkfeil, latens, CPU-bruk og HSM-kapasitet.
- For mTLS: utsted nye klientsertifikater og behold tillit til både gammel og ny kurve i en overgangsperiode.
- Behold den gamle P-256-nøkkelen tilgjengelig for rollback frem til alle klienter er bekreftet migrert, og trekk den først da tilbake.
Kommandoene under viser selve nøkkelgenereringen med OpenSSL, som er identisk i struktur for begge kurvene, bare med ulikt kurvenavn:
# Generer en ny P-384 privatnøkkel
openssl ecparam -name secp384r1 -genkey -noout -out p384-nokkel.pem
# Opprett CSR fra den nye nøkkelen
openssl req -new -key p384-nokkel.pem -out p384.csr \
-subj "/CN=eksempel.no"
# Verifiser at CSR-en faktisk bruker riktig kurve
openssl req -in p384.csr -noout -text | grep -A1 "Public Key Algorithm"Mål alltid faktisk signerings- og verifiseringsytelse på egen maskinvare før og etter migreringen. Forskjellen på 2 til 3 ganger tregere P-384-operasjoner betyr lite for et nettsted med moderat trafikk, men kan kreve flere servere for en tjeneste som signerer tusenvis av forespørsler i sekundet.
Fordeler og ulemper: P-256 mot P-384
Ingen av kurvene er objektivt “best”, de representerer to forskjellige punkter på samme avveining mellom hastighet og sikkerhetsmargin. Listene under oppsummerer fordelene og ulempene slik de fremstår basert på tallene i denne artikkelen.
P-256: fordeler og ulemper
- Fordel: 2 til 3 ganger raskere signering, verifisering og nøkkelgenerering enn P-384 i de fleste benchmarker.
- Fordel: bredest mulig kompatibilitet med eldre klienter, nettlesere og innebygde systemer.
- Fordel: standardvalget hos de fleste CA-er og skytjenester, noe som gjør driften enklere.
- Ulempe: lavere sikkerhetsmargin (128 bit) enn P-384, noe som kan være utilstrekkelig for enkelte compliance-krav.
- Ulempe: mindre “fremtidssikker” på papiret dersom klassiske angrepsalgoritmer forbedres raskere enn forventet.
P-384: fordeler og ulemper
- Fordel: høyere klassisk sikkerhetsnivå (192 bit), foretrukket i høyassuranse- og myndighetsprofiler historisk.
- Fordel: godkjent i samme standarder (FIPS 186-5, CA/Browser Forum BR) som P-256, uten ekstra kostnad i skyen.
- Ulempe: 2 til 3 ganger tregere enn P-256 på signering og verifisering ifølge tilgjengelige benchmarker.
- Ulempe: større signaturer og nøkler (opptil 96 byte signatur mot 64 byte for P-256), som øker båndbreddebruk marginalt per håndtrykk.
- Ulempe: mindre utbredt i offentlig Web PKI, noe som kan gi færre optimaliserte implementasjoner i enkelte biblioteker.
Hvilken kurve bør du velge? Bruksscenarier og anbefalinger
Valget avhenger mer av systemets krav enn av en generell “beste” kurve. Start alltid med å spørre hvilket compliance-rammeverk systemet faktisk må dokumenteres mot, om trafikkvolumet er høyt nok til at CPU-kostnaden merkes, og hvilke klienter som skal koble seg til. Her er konkrete anbefalinger for vanlige situasjoner:
- Offentlig nettsted med bred klientkompatibilitet: velg P-256. Det er standardvalget hos Let’s Encrypt og de fleste CA-er, og det gir best ytelse uten kompatibilitetsrisiko.
- Høyvolum API-er og mikrotjenester: velg P-256 for å holde CPU-kostnaden per signering lav, spesielt ved mange tusen forespørsler i sekundet.
- Statlige eller forsvarsrelaterte systemer med krav om høyere sikkerhetsmargin: vurder P-384 i tråd med historiske CNSA-profiler, men følg med på CNSA 2.0-tidslinjen mot post-kvante algoritmer.
- IoT og innebygde enheter med begrenset CPU og strømbudsjett: velg P-256, siden lavere regnekraft direkte gir lengre batterilevetid og raskere respons.
- Kodesignering med lang gyldighetsperiode: vurder P-384 for ekstra sikkerhetsmargin over signaturens levetid, spesielt for programvare som skal driftes i mange år.
- mTLS mellom interne tjenester med moderat trafikk: begge kurvene fungerer godt her, men P-256 er enklere å drifte på tvers av blandede klientbiblioteker.
- Organisasjoner som allerede planlegger post-kvante-migrering: invester heller i pilotering av hybride ML-KEM/ML-DSA-oppsett enn å bruke mye tid på å bytte mellom P-256 og P-384, siden begge uansett skal erstattes på lengre sikt.
Konklusjon: vår vurdering basert på tallene
Tallene peker i en klar retning for de fleste. P-256 er 2 til 3 ganger raskere på signering og verifisering ifølge tilgjengelige benchmarker, koster akkurat det samme som P-384 hos AWS, Google Cloud og Azure, og dekker allerede rundt halvparten av alle TLS-sertifikater ifølge både SecureMonk- og Cloudflare Radar-baserte målinger. For et vanlig nettsted, en offentlig API eller en mikrotjeneste er P-256 fortsatt det fornuftige standardvalget i 2026.
P-384 forblir riktig verktøy når kravet er en dokumentert høyere sikkerhetsmargin, typisk i statlig sektor eller høyassurent infrastruktur der 192-bits klassisk sikkerhet er en eksplisitt policy, ikke bare en vane. Kostnaden i skyen er identisk med P-256, så den eneste reelle prisen du betaler for P-384 er lavere gjennomstrømming per server.
Uansett hvilken kurve du velger i dag, er ingen av dem et permanent svar. NSAs CNSA 2.0-tidslinje og NIST IR 8547 peker begge mot en gradvis utfasing av klassisk ECC til fordel for post-kvante algoritmer i løpet av det neste tiåret. Den mest fremtidsrettede beslutningen er derfor å velge kurven som passer dagens krav best, samtidig som du begynner å teste hybride post-kvante-oppsett parallelt.
Kort oppsummert: mål ytelsen på egen maskinvare, sjekk hvilken kurve produksjonssertifikatene dine faktisk bruker med kommandoene lenger opp i artikkelen, og la sikkerhetskravet, ikke vanen, styre om svaret blir P-256 eller P-384.
Ofte stilte spørsmål om P-256 og P-384
Er P-384 sikrere enn P-256?
Ja, målt i klassisk sikkerhetsnivå. P-384 gir omtrent 192 bits sikkerhet mot omtrent 128 bit for P-256. Ingen av dem er sikre mot et tilstrekkelig kraftig kvantedatamaskin, siden begge er sårbare for Shors algoritme.
Koster P-384 mer enn P-256 i AWS, Google Cloud eller Azure?
Nei. AWS KMS, Google Cloud KMS og Google Cloud HSM prissetter P-256 og P-384 likt innenfor samme nøkkelkategori. Azure Key Vault fakturerer ECC-operasjoner per 10 000 transaksjoner uavhengig av hvilken kurve som brukes.
Hvor mye tregere er P-384 enn P-256?
Ifølge en offentlig Mirage Crypto-benchmark er P-256 omtrent 2,4 ganger raskere på signering og 2,7 ganger raskere på verifisering enn P-384 i samme testmiljø. Eksakte tall varierer med maskinvare og bibliotek, så mål alltid selv før du tar en beslutning for et høyvolumsystem.
Støtter Let’s Encrypt P-384?
Ja. Let’s Encrypt utsteder sertifikater med både P-256 og P-384, i tillegg til RSA. De tilbyr foreløpig ikke Ed25519 for offentlig tiltrodde sertifikater.
Kan jeg konvertere en eksisterende P-256-nøkkel til P-384?
Nei. Du må generere et helt nytt nøkkelpar på P-384-kurven, opprette en ny CSR og få utstedt et nytt sertifikat. Den gamle P-256-nøkkelen kan beholdes for rollback frem til migreringen er fullført.
Er P-256 eller P-384 kvantesikre?
Nei, ingen av dem. Begge er klassiske elliptiske kurver som faller for Shors algoritme på en tilstrekkelig kraftig kvantedatamaskin. Post-kvante alternativer som ML-KEM og ML-DSA er utviklet spesifikt for å stå imot dette, og NSAs CNSA 2.0-plan legger opp til en gradvis overgang dit innen 2033 for amerikanske myndighetssystemer.
Hvilken kurve bruker de fleste nettsteder i dag?
P-256 er den klart vanligste ECDSA-kurven i offentlig Web PKI ifølge både SecureMonk-utvalget fra september 2026 og Technology Checkers analyse av Cloudflare Radar-data. Samlet lå ECDSA-andelen av alle TLS-sertifikater på rundt 49 til 50 prosent i disse målingene, med RSA som den andre store gruppen.
Bør nye prosjekter bruke Ed25519 i stedet for P-256 eller P-384?
For interne systemer og SSH-nøkler er Ed25519 ofte et godt alternativ og allerede godkjent i FIPS 186-5. For offentlig tiltrodde TLS-sertifikater er støtten foreløpig begrenset, siden Let’s Encrypt og de fleste store CA-er ennå ikke utsteder Ed25519-sertifikater, så P-256 eller P-384 er fortsatt det praktiske valget for nettvendte tjenester i 2026.
Hva er P-521, og bør jeg bruke den i stedet for P-256 eller P-384?
P-521 er den tredje NIST-kurven i samme familie, med et sikkerhetsnivå på omtrent 256 bit. Den er godkjent i CA/Browser Forums Baseline Requirements på lik linje med P-256 og P-384, men brukes langt sjeldnere i praksis fordi ytelseskostnaden er enda høyere, uten at de fleste systemer faktisk trenger den ekstra marginen. Med mindre du har et dokumentert krav om 256-bits klassisk sikkerhet, dekker P-256 eller P-384 behovet for de aller fleste.
