En vanlig ECDSA-signatur veier rundt 64 byte. Bytt til ML-DSA-44, den letteste post-kvante-varianten NIST godkjente i august 2024, og samme signatur vokser til 2 420 byte. Det er nesten 38 ganger større, og forskjellen er ikke kosmetisk. Den avgjør hvor mange sertifikater som får plass i et TLS-håndtrykk, hvor mye en IoT-enhet må lagre, og hvor fort en nasjonal sikkerhetsmyndighet kan kreve at du bytter algoritme helt. NIST, NSA og NSM i Norge har alle satt tidsfrister for når ECDSA skal fases ut. Denne sammenligningen går gjennom tallene, benchmarkene og migreringsveien for norske og nordiske team som må ta stilling til ML-DSA vs ECDSA i praksis.

Hva er ECDSA og ML-DSA?

ECDSA (Elliptic Curve Digital Signature Algorithm) har vært arbeidshesten i moderne kryptografi siden tidlig 2000-tall. Algoritmen bygger på det diskrete logaritme-problemet over elliptiske kurver, typisk kurven P-256 eller P-384, og er standardisert i NIST FIPS 186-5. Styrken kommer fra at det tar uoverkommelig lang tid å regne ut en privat nøkkel fra en offentlig nøkkel på en klassisk datamaskin. Det er derfor ECDSA i dag sikrer alt fra TLS-sertifikater på norske banknettsteder til signaturer i Bitcoin- og Ethereum-lommebøker.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) er derimot bygget for en verden der kvantedatamaskiner finnes. Algoritmen, tidligere kjent som CRYSTALS-Dilithium, ble endelig standardisert av NIST i FIPS 204 i august 2024. Sikkerheten hviler på gitterproblemer i høydimensjonale rom, en matematisk oppgave som ikke har noen kjent kvante-snarvei slik Shors algoritme gir for elliptiske kurver. Til gjengjeld betaler du med langt større nøkler og signaturer. Sammenligningen med ECDSA vs Ed25519 handler om ytelse mellom to klassiske kurver, mens ML-DSA vs ECDSA handler om noe mer grunnleggende: om signaturen din i det hele tatt overlever kvantedatamaskiner.

Kvantetrusselen: hvorfor haster det plutselig?

Ingen vet nøyaktig når en kvantedatamaskin klarer å knekke ECDSA eller RSA, men estimatene har krympet raskt. Google anslo i 2019 at det ville kreve 20 millioner qubits å knekke RSA-2048. I mai 2025 reviderte Googles forskere tallet ned til under én million støyende qubits, ifølge en analyse fra The Quantum Insider. Det er en tjuegangers reduksjon på seks år. Googles interne sikkerhetsteam planlegger etter en migreringsfrist rundt 2029, ett år før NIST sin offisielle deprekeringsdato.

NIST har formalisert dette i dokumentet IR 8547: klassiske algoritmer på 112-bits sikkerhetsnivå, som RSA-2048 og ECDSA P-256, skal deprekeres for nye systemer etter 2030 og forbys helt etter 2035. Global Risk Institute sin kvantetrussel-rapport fra 2024 anslår 17 til 34 prosent sannsynlighet for at en kvantedatamaskin kan knekke RSA-2048 på 24 timer innen 2034, stigende til rundt 79 prosent innen 2044. Andre analyser, deriblant en IBM-tilknyttet vurdering, peker på at 1 399 logiske qubits kan holde til å knekke RSA-2048 på fem dager med nyere algoritmeforskning fra 2025, mens IBMs egen kjøreplan sikter mot 2 000 logiske qubits innen 2032. Spennet i estimatene er stort, fra midten av 2030-tallet til enkelte mer forsiktige analyser som ikke venter et gjennombrudd før 2055. Poenget er likevel det samme: data som krypteres eller signeres i dag, kan bli sårbar før den naturlige levetiden til sertifikatet eller dokumentet er over.

Dette henger sammen med det sikkerhetsmiljøet kaller “harvest now, decrypt later”: en motstander samler inn kryptert eller signert trafikk allerede i dag, og venter til en kvantedatamaskin faktisk finnes før dataene dekrypteres eller forfalskes i ettertid. For informasjon med kort levetid, som en enkelt påloggingsøkt, er dette lite relevant. For signaturer på firmware, langtidskontrakter eller myndighetsdokumenter som skal stå seg i tiår, er det derimot en reell grunn til å starte migreringen nå, selv om selve kvantedatamaskinen ennå ikke eksisterer.

Nøkkel- og signaturstørrelser: full oversikt

Den klareste forskjellen mellom algoritmene ligger i rene byte. Tabellen under samler tallene fra NIST FIPS 204 og Open Quantum Safe sitt referansebibliotek liboqs, sammen med typiske ECDSA-størrelser slik de rapporteres av Redsift og andre PKI-leverandører i 2026.

EgenskapECDSA P-256ECDSA P-384ML-DSA-44ML-DSA-65ML-DSA-87
Offentlig nøkkel65 byte97 byte1 312 byte1 952 byte2 592 byte
Privat nøkkel~32 byte~48 byte2 560 byte4 032 byte4 896 byte
Signaturstørrelse64–72 byte96–104 byte2 420 byte3 309 byte4 627 byte
NIST sikkerhetsnivå––Nivå 2Nivå 3Nivå 5
Tilsvarende styrke128-bit192-bit~AES-128~AES-192~AES-256
Matematisk grunnlagElliptisk kurve, diskret logaritmeSammeModul-gitter (lattice)SammeSamme
StandardFIPS 186-5 (2023)SammeFIPS 204 (aug. 2024)SammeSamme
KvanteresistentNeiNeiJaJaJa
Signeringstid (IACR-referanse)0,031 ms–0,050 ms (Dilithium2)––
Verifiseringstid (IACR-referanse)0,096 ms–0,036 ms––
CNSA 2.0-statusUtfasesUtfases–Anbefalt standardnivåPåkrevd nivå for NSS

Regnestykket blir tydelig når man setter tallene opp mot hverandre direkte. Med en ECDSA P-256-signatur på 72 byte som referanse, er ML-DSA-44 rundt 34 ganger større og ML-DSA-87 rundt 64 ganger større, ifølge tall gjengitt av Evertrust og Open Quantum Safe. Ser man på det minste ECDSA-tallet, 64 byte, blir forskjellen enda brattere: opptil 38 og 72 ganger. Offentlige nøkler vokser enda mer relativt sett, med rundt 97 prosent økning mellom ML-DSA-44 og ML-DSA-87 alene.

Private nøkler følger samme mønster. En ECDSA P-256-privatnøkkel er typisk rundt 32 byte, mens ML-DSA-44 krever 2 560 byte og ML-DSA-87 hele 4 896 byte for det samme formålet, ifølge NIST FIPS 204 og Open Quantum Safe sin oversikt. For et system som lagrer tusenvis av private nøkler, for eksempel en sertifikatmyndighet eller en IoT-flåte med individuelle enhetsnøkler, betyr det en tilsvarende økning i lagringsbehov i selve nøkkellageret, uavhengig av hvor mange signaturer som faktisk produseres.

Sikkerhetsnivåer og hvorfor matematikken er ulik

ECDSA og ML-DSA løser samme oppgave, å bevise at en melding kommer fra en bestemt privat nøkkel, men de hviler på helt ulike matematiske antakelser. ECDSA er trygg fordi ingen klassisk datamaskin klarer å løse det diskrete logaritme-problemet over en elliptisk kurve innen rimelig tid. Problemet er at Shors algoritme, kjørt på en tilstrekkelig stor kvantedatamaskin, løser akkurat dette problemet effektivt. Det er selve grunnen til at ECDSA står på NIST sin utfasingsliste.

ML-DSA bygger i stedet på module-lattice-problemer, konkret varianter av Module-LWE og Module-SIS. Ingen kjent kvantealgoritme løser disse problemene raskere enn klassiske datamaskiner klarer, noe som er grunnen til at NIST valgte gitterbaserte konstruksjoner som hovedspor for post-kvante-signaturer. De tre parametersettene ML-DSA-44, ML-DSA-65 og ML-DSA-87 tilsvarer grovt sett sikkerhetsnivå 2, 3 og 5 i NIST sin skala, omtrent på linje med AES-128, AES-192 og AES-256. ML-DSA-65 regnes som standardvalget for de fleste applikasjoner, mens ML-DSA-87 er valget for CNSA 2.0 og nasjonale sikkerhetssystemer. Den som ønsker et dypere sammenligningsgrunnlag mellom to post-kvante-signaturfamilier, kan lese vår gjennomgang av ML-DSA vs SLH-DSA, der begge er kvanteresistente, men bygget på ulike matematiske familier.

Grunnen til at NSM i Norge nevner nettopp SLH-DSA som et alternativ til ML-DSA, er at de to post-kvante-algoritmene hviler på helt ulike matematiske familier. Skulle det en dag dukke opp en uventet svakhet i gitterbaserte konstruksjoner, står SLH-DSA igjen som en hasjbasert reserveløsning uten samme antakelse. Det er samme tankegang som ligger bak å kombinere ECDSA og ML-DSA i en hybrid: ingen enkelt matematisk antakelse bør bære hele sikkerheten alene i en overgangsperiode.

Ytelse i praksis: signering og verifisering

Størrelsestallene er entydige, men ytelsen er mer nyansert, og her spriker resultatene mellom kilder avhengig av maskinvare og implementasjon. Tre uavhengige målinger gir et representativt bilde.

Den første er IACR-studien “Benchmarking Post-Quantum Cryptography in TLS” fra 2019, som fortsatt siteres i 2025- og 2026-analyser fordi tallene holder seg stabile. Der målte forskerne ECDSA P-256 til 0,031 millisekund for signering og 0,096 millisekund for verifisering, mot 0,050 og 0,036 millisekund for Dilithium2, forløperen til ML-DSA-44. Konklusjonen er konsistent: ECDSA signerer raskere, men ML-DSA verifiserer raskere, med nesten tre ganger kortere verifiseringstid.

Den andre kilden er et Go-benchmark fra 2025 som bruker Cloudflares eget kryptobibliotek CIRCL. Der brukte ECDSA-P256 rundt 18 700 nanosekunder på å signere og 20 900 nanosekunder på nøkkelgenerering, mens ML-DSA-44 brukte rundt 108 600 nanosekunder bare på nøkkelgenerering, over fem ganger lengre tid. Forfatteren bak benchmarken noterer likevel at ML-DSA-87 kan verifisere raskere enn ECDSA P-521 på samme maskin, noe som viser at forspranget snur ved høyere sikkerhetsnivåer.

Den tredje kilden er en ARM Cortex-M0-benchmark publisert i 2026, som tester begge algoritmene på svak, batteridrevet maskinvare typisk for IoT. Der brukte ECDSA P-256 92,6 klokkesykluser i gjennomsnitt på signering, mens ML-DSA-44 brukte 158,9. Forskjellen er mindre dramatisk enn på server-maskinvare, men fortsatt tydelig til ECDSA sin fordel på ressursbegrensede enheter. Et fjerde datapunkt fra en 2025-oversikt over PQ-signaturer viser at ML-DSA ved sikkerhetsnivå 5 verifiserer på 0,14 millisekund på en ARM-basert bærbar maskin, mot 0,88 millisekund for ECDSA på samme utstyr, altså over seks ganger raskere verifisering når sikkerhetsnivåene sammenlignes direkte.

Cloudflare har selv publisert en referansetabell der ML-DSA-44 brukes som CPU-basislinje (verdien 1,0) for både signering og verifisering, og beskriver algoritmen som “lett for CPU-en” sammenlignet med andre post-kvante-kandidater som ble vurdert i standardiseringsprosessen. Det stemmer godt med feltdataene: ML-DSA er ikke den raskeste signaturalgoritmen som finnes, men den er langt fra den tregeste blant de kvanteresistente alternativene.

For et system som håndterer TLS betyr dette to ting samtidig. På serversiden, der samme sertifikat brukes til å signere tusenvis eller millioner av håndtrykk, er den noe tregere signeringstiden i praksis uviktig fordi signaturen som regel beregnes én gang og gjenbrukes. På klientsiden, der hver enkelt tilkobling må verifisere signaturen på nytt, er ML-DSA sin raskere verifisering faktisk en fordel, ikke en ulempe. Flaskehalsen ligger dermed sjelden i selve CPU-tiden, men i båndbredden signaturene legger beslag på, som er tema for neste avsnitt.

Det er verdt å nevne at ML-DSA ikke er det eneste post-kvante-signaturvalget NIST standardiserte. FN-DSA (tidligere Falcon) og SLH-DSA (tidligere SPHINCS+) ble godkjent samtidig, og en 2025-studie som sammenligner flere PQC-signaturfamilier mot ECDSA, deriblant ML-DSA, Falcon, Mayo og SPHINCS+, konkluderer med at de kvanteresistente algoritmene samlet sett introduserer “kun mindre ytelsesoverhead” sammenlignet med klassisk ECDSA i praktiske bruksområder som blokkjedesystemer. ML-DSA har likevel blitt standardvalget for de fleste generelle bruksområder fordi den kombinerer moderat signaturstørrelse med enklere implementasjon enn Falcon, som krever flyttallsberegninger som er vanskeligere å sikre mot sidekanalangrep.

Hva større signaturer koster i TLS-håndtrykket

Byte-forskjellen fra spesifikasjonstabellen får reelle konsekvenser når den multipliseres opp gjennom en hel sertifikatkjede. Cloudflare skrev i sin 2025-rapport om post-kvante-internett at et rent bytte til ML-DSA-44 for alle signaturer legger til rundt 15 kilobyte data som må overføres fra server til klient under TLS-håndtrykket. En tidligere versjon av samme analyse fra 2024 anslo 17 kilobyte, og et senere Cloudflare-innlegg om “Sizing Up Post-Quantum Signatures” bekrefter samme størrelsesorden. Årsaken er at en typisk WebPKI-kjede med sertifikatgjennomsiktighet (Certificate Transparency) kan kreve opptil fem signaturer og to offentlige nøkler i ett og samme håndtrykk.

Andre målinger bekrefter bildet. En analyse fra lesitedefrancois.be viser at en tresertifikat-kjede signert med ML-DSA-65 legger til rundt 10 kilobyte signaturdata i TLS-meldingen Certificate, mot rundt 200 byte for en tilsvarende ECDSA-kjede. PQProbe har målt at et enkelt ML-DSA-65-kjeddledd veier 5 261 byte, mot 550 byte for RSA-2048 og bare 163 byte for ECDSA-P256. Legger man sammen to signaturer i en kjede, krysser man ifølge samme analyse ti kilobyte autentiseringsdata, der klassisk kryptografi holder seg på noen hundre byte. Evertrust har i tillegg regnet ut konkrete sertifikatstørrelser: et ML-DSA-87-sertifikat med to SAN-oppføringer og standard metadata lander på rundt 5,5 kilobyte, mens et hybridsertifikat med ML-DSA-65 kombinert med ECDSA P-256 lander på rundt 4,2 kilobyte.

Konsekvensen er praktisk, ikke bare teoretisk. Et TLS 1.3 ClientHello med hybrid nøkkelutveksling som X25519MLKEM768 veier allerede over to kilobyte og kan sprenge standard TCP-pakkestørrelse, noe som tvinger fram fragmentering. Legg ML-DSA-signaturer oppå det, og enkelte nettverk med dårlig håndtering av fragmenterte TLS-pakker kan begynne å feile håndtrykk helt. Det er hovedgrunnen til at Cloudflare og andre store CDN-er fortsatt bruker ECDSA for selve signaturene, mens de kjører ML-KEM for nøkkelutveksling. Den samme logikken diskuteres i vår sammenligning av ML-KEM vs HQC, som ser på nøkkelutvekslingssiden av det samme post-kvante-skiftet.

Hybridsignaturer: broen mellom to verdener

De fleste sikkerhetsmiljøer anbefaler ikke et rent bytte fra ECDSA til ML-DSA over natten. I stedet kombineres begge algoritmene i det som kalles en hybridsignatur: meldingen signeres med både ECDSA og ML-DSA, og mottakeren må verifisere begge signaturene for at meldingen skal godkjennes. Poenget er å unngå et enkelt feilpunkt. Hvis det senere skulle vise seg å finnes en svakhet i ML-DSA, en ung standard med begrenset feltdata, faller systemet tilbake på den velprøvde sikkerheten til ECDSA. Motsatt beskytter ML-DSA-delen mot et fremtidig kvantebrudd på ECDSA.

En rapport fra MIT sitt 6.5610-kurs i anvendt kryptografi, publisert i 2026, har målt kostnaden ved en slik hybrid direkte. En kombinert ECDSA P-256 og Dilithium2-signatur brukte i gjennomsnitt 54,4 mikrosekund på nøkkelgenerering, 131,1 mikrosekund på signering og 113,7 mikrosekund på verifisering, med en gjennomsnittlig signaturstørrelse på 2 484 byte. Byttes Dilithium2 ut med det sterkere Dilithium3, stiger tallene til 109,1 mikrosekund for nøkkelgenerering, 232,7 mikrosekund for signering og 180,8 mikrosekund for verifisering, med signaturstørrelse på 4 659 byte. Det er en håndterbar kostnad for de fleste servere, men den er langt fra gratis på enheter med begrenset CPU eller strømbudsjett.

NSM begrunner selv hybridvalget med at tilliten til de nye gitterbaserte algoritmene ennå ikke har rukket å bygge seg opp på samme måte som tilliten til ECDSA har gjort over to tiår med produksjonsbruk. Så lenge begge signaturene må verifiseres for at meldingen skal godkjennes, kan et angrep bare lykkes dersom begge de underliggende matematiske problemene løses samtidig, noe som i praksis er en langt høyere terskel enn å knekke én enkelt algoritme. Kostnaden er at systemet arver ulempene fra begge sider: signaturstørrelsen fra ML-DSA og forvaltningsarbeidet med to separate nøkkelsett i stedet for ett.

Hvem har allerede tatt i bruk ML-DSA?

ML-DSA er ikke lenger bare teori i et NIST-dokument. Flere store aktører har rullet ut støtte i løpet av 2025 og 2026.

  • AWS KMS la til støtte for ML-DSA 13. juni 2025, med nøkkelspesifikasjonene ML_DSA_44, ML_DSA_65 og ML_DSA_87, samt en ny signeringsalgoritme kalt ML_DSA_SHAKE_256.
  • AWS Private CA fulgte opp 17. november 2025 med støtte for å utstede ML-DSA-sertifikater og utføre post-kvante kodesignering sammen med AWS KMS.
  • Cloudflare støtter siden midten av 2026 ML-DSA-sertifikater for Authenticated Origin Pulls og Custom Origin Trust Store, altså mellom Cloudflares kant og opprinnelsesserveren, forutsatt OpenSSL 3.5.0 eller nyere.
  • BoringSSL, Googles TLS-bibliotek som brukes i Chrome, implementerte ML-DSA (Dilithium) for signaturer allerede tidlig i 2025, ifølge en 2026-oversikt over post-kvante-støtte i kryptografibiblioteker.
  • NSM (Nasjonal sikkerhetsmyndighet) anbefaler i sine kryptografiske anbefalinger fra mars 2025 eksplisitt en hybridløsning: ECDH kombinert med ML-KEM for nøkkelutveksling, og ECDSA kombinert med ML-DSA for signaturer, som “et første steg mot full kvantesikkerhet”.
  • Open Quantum Safe-prosjektet ga ut liboqs versjon 0.14.0 i august 2025, den siste utgaven som støtter både den opprinnelige Dilithium-varianten fra NIST-runde 3 og den ferdigstandardiserte ML-DSA, før fremtidige versjoner kutter den gamle varianten helt.

Mønsteret er tydelig: infrastrukturleverandører beveger seg først, og de starter med kontrollerte miljøer som interne sertifikatkjeder og signering, ikke med å bytte ut ECDSA i offentlige nettsteder. Felles for AWS, Cloudflare og BoringSSL er også at de tilbyr ML-DSA som et tillegg ved siden av ECDSA, ikke som en erstatning. Ingen av de store leverandørene har så langt fjernet ECDSA-støtte, noe som understreker at bransjen selv regner overgangsperioden i år, ikke måneder.

Kostnadsbildet: hva koster overgangen i praksis?

ML-DSA og ECDSA er ikke produkter med separate prislapper, men overgangen har konkrete kostnadskonsekvenser som lar seg tallfeste. AWS KMS er et godt eksempel: ifølge AWS sin offentlige prisside koster hver nøkkel 1 dollar per måned, uavhengig av om det er en symmetrisk, asymmetrisk, ECDSA- eller ML-DSA-nøkkel. Selve lagringskostnaden endrer seg altså ikke. Det som endrer seg, er databelastningen rundt hver signatur, og dermed de indirekte kostnadene knyttet til båndbredde, lagring og prosessering.

KostnadskomponentECDSAML-DSAKilde
AWS KMS nøkkellagring1 USD/mnd1 USD/mnd (samme sats)AWS KMS-prisside
Signaturdata i full sertifikatkjede~200 byte~10–17 kBCloudflare / PQProbe
Enkelt sertifikat med metadataUnder 1 kB2,5–5,5 kBCloudflare / Evertrust
Hybrid ECDSA + ML-DSA-sertifikat–~4,2 kBEvertrust
Nøkkelgenereringstid (Go/CIRCL)~20,9 µs~108,6 µsMoeghifar-benchmark 2025
Sertifikatutstedelse (AWS Private CA)Standard prismodellSamme modell, nå med ML-DSA-støtteAWS Private CA

Den reelle kostnaden ved ML-DSA ligger altså ikke i selve nøkkeladministrasjonen, men i alt som følger av å flytte flere kilobyte gjennom nettverket og lagre større sertifikater i hver eneste TLS-tilkobling. For en tjeneste med millioner av daglige håndtrykk kan 15 kilobyte ekstra per tilkobling bety en merkbar økning i utgående trafikk, selv om ingen av kildene i denne artikkelen oppgir et konkret kronebeløp for akkurat det.

Den mest realistiske kostnadsvurderingen for de fleste norske virksomheter handler derfor mindre om regningen fra skyleverandøren og mer om timene som går med til testing, sertifikatkjede-redesign og HSM-oppgraderinger. Ingen av kildene i denne artikkelen antyder at ML-DSA i seg selv koster mer å drifte enn ECDSA gjør, men migreringsprosjektet rundt det gjør det, akkurat slik enhver algoritmeutskifting i produksjon historisk sett har krevd tid fra sikkerhetsteamet.

Slik migrerer du: steg for steg

En migrering fra ren ECDSA til ML-DSA, eller til en hybridmodell, bør følge en strukturert plan i stedet for et brått bytte.

  1. Kartlegg det kryptografiske inventaret. Finn hver plass ECDSA, RSA eller andre klassiske algoritmer brukes, fra TLS-sertifikater til kodesignering og interne API-er.
  2. Oppdater biblioteker til versjoner med ML-DSA-støtte, som OpenSSL 3.5.0 eller nyere, liboqs 0.14.0 eller nyere, og BoringSSL fra tidlig 2025.
  3. Test hybridmodus først. Følg NSM sin anbefaling om å kombinere ECDSA og ML-DSA, ikke erstatte ECDSA direkte, i alle systemer som håndterer sensitiv eller langsiktig informasjon.
  4. Mål ytelses- og båndbreddepåvirkningen i eget miljø før produksjonssetting. Bruk realistiske tall for handshake-størrelse og sammenlign med egen nettverkskapasitet.
  5. Rull ut til ikke-kritiske systemer først, og overvåk feilrater i TLS-håndtrykk knyttet til pakkefragmentering og MTU-begrensninger.
  6. Design sertifikatkjeder på nytt for å minimere antall signaturer. Kortere kjeder demper mye av størrelsesproblemet.
  7. Sett interne frister i tråd med CNSA 2.0 (2030 for programvaresignering, 2033 for full utfasing) eller egen risikovurdering hvis virksomheten ikke er direkte underlagt amerikanske krav.
  8. Dokumenter kryptografisk inventar løpende og følg oppdaterte anbefalinger fra NSM og NIST minst årlig.

Vanlige feil ved migrering til ML-DSA

Flere team som har testet ML-DSA i egne miljøer, går i de samme fellene. Den første er å velge ML-DSA-87 som standard “for sikkerhets skyld” uten å faktisk trenge sikkerhetsnivå 5. Det gir unødvendig store signaturer og nøkler for systemer som ville klart seg fint med ML-DSA-44 eller ML-DSA-65, og forsterker båndbredde- og lagringskostnaden uten en tilsvarende sikkerhetsgevinst i praksis.

Den andre fellen er å teste kun i laboratoriemiljø med lav breddegrad-latens og god nettverkskvalitet, og aldri på mobilnett eller nettverk med høyt pakketap. Fordi ML-DSA-signaturer øker sjansen for fragmenterte TLS-pakker, dukker feilene ofte først opp i produksjon, på nettverk utviklerteamet aldri testet mot. Den tredje fellen er å glemme maskinvaresikkerhetsmoduler (HSM-er). Ikke alle eldre HSM-er støtter ML-DSA ennå, og et bytte av signaturalgoritme uten å verifisere HSM-kompatibilitet på forhånd kan stoppe hele utrullingen midtveis. Den fjerde og siste fellen er å undervurdere at hybridsignaturer i praksis dobler arbeidsmengden ved nøkkelrotasjon, siden både ECDSA- og ML-DSA-nøkler må roteres, overvåkes og revideres parallelt så lenge hybridperioden varer.

En femte, mindre åpenbar felle er å behandle migreringen som et rent teknisk prosjekt uten å informere driftspersonell om de nye feilmønstrene. Et TLS-håndtrykk som feiler på grunn av en for stor sertifikatkjede, ser ofte ut som et generelt nettverksproblem i overvåkingsverktøy, ikke som en kryptografisk størrelsesbegrensning. Team som ikke er forberedt på dette, kan bruke unødvendig lang tid på feilsøking som burde tatt minutter.

Bruksområder: når bør du velge hva?

Valget mellom ECDSA, ML-DSA og en hybridløsning avhenger sterkt av hva systemet skal beskytte og hvor lenge dataene må forbli sikre. Et nyttig tankeeksperiment er å spørre seg selv hvor lenge signaturen eller sertifikatet faktisk må stå seg. Et kortlevd TLS-sertifikat med 90 dagers gyldighet har god tid til å vente på et modnere økosystem, mens en signatur på et dokument som skal være juridisk gyldig i 20 år, allerede i dag risikerer å bli signert med en algoritme som er forbudt før dokumentet går ut på dato.

  • Offentlig sektor og nasjonal sikkerhet: Systemer underlagt CNSA 2.0 bør planlegge for ML-DSA-87 nå. NSA krever at nye anskaffelser til nasjonale sikkerhetssystemer støtter CNSA 2.0 fra januar 2027.
  • Vanlige nettsteder og TLS-servere: Vent på modne hybridsertifikater fra store CA-er før du bytter fullt ut. Håndtrykk-overheaden på 15–17 kilobyte er fortsatt en reell kostnad for høytrafikk-tjenester.
  • Kodesignering av programvare og fastvare: Her haster det mer. CNSA 2.0 krever at ny programvare og fastvare bruker CNSA 2.0-signeringsalgoritmer, og AWS Private CA med ML-DSA er allerede tilgjengelig for dette formålet. Fastvare som skal ligge urørt i produkter i mange år etter utsendelse, er nettopp den typen langlevd signatur der kvantetrusselen får tid til å bli reell før produktet fases ut.
  • IoT og innebygde enheter: Med begrenset RAM og strøm bør du vurdere om enheten i det hele tatt tåler nøkler på flere kilobyte. ARM Cortex-M0-benchmarken viser at ML-DSA fortsatt er tregere enn ECDSA på svak maskinvare, og for batteridrevne sensornettverk kan den ekstra CPU-tiden også bety kortere batterilevetid.
  • Blokkjede og kryptovaluta: Bitcoin og Ethereum bruker fortsatt ECDSA over kurven secp256k1. En full om-signering av eksisterende adresser er praktisk sett umulig i etterkant, noe som gjør planlegging nå kritisk. Se vår gjennomgang av Bitcoins kvantetrussel for hvordan dette spesifikt rammer eksisterende lommebøker.
  • Finansnæringen: Finans Norge har publisert et eget veikart for kvantesikker finansnæring, som bygger videre på NSM sine anbefalinger og peker mot samme tidslinje som CNSA 2.0.
  • Dokumentsignering og generell PKI: Start med hybrid ECDSA+ML-DSA nå, og gå over til ren ML-DSA når størrelsesbudsjettet i egne systemer tillater det.

Fordeler og ulemper

Satt opp mot hverandre punkt for punkt handler valget sjelden om hvilken algoritme som er “best” i abstrakt forstand, men om hvilke svakheter organisasjonen din tåler å leve med akkurat nå.

ECDSA

Fordelene med ECDSA er velkjente: signaturer på bare 64 til 72 byte, lavt CPU-forbruk ved signering, og over to tiår med utbredt, moden støtte i praktisk talt alle biblioteker, nettlesere og maskinvaremoduler. Nesten enhver HSM, smartkortbrikke og innebygd krypteringsmodul på markedet støtter ECDSA i dag, noe som gjør implementasjon både billig og lavrisiko. Ulempen er at hele sikkerhetsgrunnlaget faller sammen dersom en tilstrekkelig stor kvantedatamaskin bygges, noe NIST nå planlegger for som en reell mulighet innen 2030 til 2035.

ML-DSA

ML-DSA sin store fordel er at den ikke har noen kjent kvantesvakhet, kombinert med relativt god CPU-ytelse sammenlignet med andre post-kvante-signaturkandidater som ble vurdert i NIST sin prosess. Verifiseringen kan i mange tilfeller være raskere enn ECDSA, og algoritmen er nå offisielt standardisert og støttet av flere store skyleverandører samtidig. Ulempene er signaturer og nøkler som er 34 til 72 ganger større, tregere nøkkelgenerering på flere plattformer, økt håndtrykk-overhead på 15 til 17 kilobyte, og status som en relativt ung standard med mindre feltdata enn ECDSA har opparbeidet seg over tyve år.

Hva sier NIST om overgangen?

NIST sin egen prosjektside for post-kvante-kryptografi er tydelig på at ventetiden er over. Etter at de tre første endelige PQC-standardene ble publisert, skriver NIST CSRC: “With the release of the first three final PQC standards, organizations should begin migrating their systems to quantum-resistant cryptography.” (NIST CSRC)

Samme kilde peker på at overgangen ikke bare handler om å bytte algoritme et sted i koden, men om et systematisk kartleggingsarbeid: “Cybersecurity products, services, and protocols will need updates, and organizations must identify where vulnerable algorithms are used and plan to replace or update them.” (NIST CSRC)

Da NIST offisielt kunngjorde godkjenningen av standarden, beskrev de opphavet til algoritmen slik: “FIPS 204 specifies the Module-Lattice-Based Digital Signature Standard, which is derived from CRYSTALS-Dilithium submission.” (NIST CSRC, kunngjøring 2024)

En NIST-presentasjon om FIPS 204 oppsummerer det samme poenget kort og presist: “FIPS 204 specifies ML-DSA Based on the Selected NIST PQC submission CRYSTALS-Dilithium” (NIST PQC-presentasjon, 2024). Budskapet fra standardiseringsmyndigheten er konsistent på tvers av alle disse kildene: ML-DSA er ferdig, godkjent, og klar til bruk, og organisasjoner bør ikke vente med å begynne planleggingen.

Norge og Norden: hvor står vi?

Nasjonal sikkerhetsmyndighet oppdaterte sine kryptografiske anbefalinger 24. mars 2025 med eksplisitt veiledning om post-kvante-algoritmer. Anbefalingen er en hybridløsning: ECDH kombinert med ML-KEM for nøkkelutveksling, og ECDSA kombinert med ML-DSA for signaturer, beskrevet som “et første steg mot full kvantesikkerhet” fram til tilliten til de nye algoritmene er godt nok etablert i felt. NSM anbefaler også at virksomheter fører et kryptografisk inventar og forbereder seg konkret på overgangen, i tråd med samme prinsipper som NIST fremmer internasjonalt.

Finans Norge har bygget videre på NSM sine anbefalinger med et eget veikart for en kvantesikker finansnæring, rettet mot banker og betalingsaktører som må planlegge overgangen på tvers av eldre systemer og nye standarder samtidig. Sverige har på sin side publisert nasjonale anbefalinger gjennom NCSC med en frist om full overgang senest innen 2035, og en strammere frist på 2030 for spesielt sensitiv informasjon, altså praktisk talt samme tidslinje som NIST og CNSA 2.0 opererer med. For norske og nordiske virksomheter betyr dette at det ikke lenger er et spørsmål om post-kvante-signaturer kommer, men når den enkelte virksomheten selv setter sin interne migreringsdato.

Det regulatoriske presset i Norge kommer heller ikke bare fra kryptografifaget isolert sett. Digitalsikkerhetsloven, som gjennomfører NIS2 i norsk rett, stiller allerede krav om risikostyring og hendelseshåndtering for et bredt utvalg virksomheter, og et kryptografisk inventar som uansett kreves for å planlegge en ML-DSA-migrering, er samtidig god dokumentasjon opp mot disse kravene. For selskaper som allerede jobber med etterlevelse av digitalsikkerhetsloven, gir det mening å legge post-kvante-planleggingen inn i det samme risikoarbeidet, framfor å behandle det som et separat kryptografiprosjekt.

Konklusjon: hvem vinner sammenligningen?

Det finnes ikke noe enkelt svar på ML-DSA vs ECDSA, fordi de to algoritmene løser ulike problemer på ulike tidshorisonter. Trenger du et system som er raskt, kompakt og fungerer overalt akkurat nå, vinner ECDSA fortsatt på nesten alle praktiske mål: signaturer 34 til 72 ganger mindre, lavere CPU-bruk ved signering, og to tiår med utprøvd drift. Trenger du derimot et system som fortsatt er trygt om ti eller femten år, har ECDSA alene ingen god vei framover, fordi NIST sin egen tidslinje setter 2035 som siste frist for bruk av 112-bits klassiske algoritmer.

Den praktiske konklusjonen, støttet av både NSM, NIST og de store skyleverandørenes egne utrullinger, er hybrid nå og full overgang senere. Kombiner ECDSA og ML-DSA i systemer som håndterer sensitiv eller langsiktig informasjon, følg CNSA 2.0 sin tidslinje (2030 for signering av programvare, 2033 for full utfasing i amerikanske nasjonale sikkerhetssystemer) som en fornuftig referanseramme selv utenfor USA, og vent med å fjerne ECDSA helt til hybridsertifikater og biblioteker har modnet ytterligere. For norske virksomheter betyr det konkret: kartlegg det kryptografiske inventaret i år, test hybridmodus i 2026, og la selve fristen for full overgang følge egen risikoprofil framfor en vilkårlig dato.

Tallene i denne artikkelen peker mot en enkel tommelfingerregel. Jo lenger levetid signaturen eller sertifikatet har, desto sterkere grunn er det til å begynne migreringen nå, selv om selve kvantetrusselen fortsatt ligger et stykke fram i tid. Jo kortere levetid, desto tryggere er det å vente på at ML-DSA-økosystemet modnes videre og at håndtrykk-overheaden krymper etter hvert som sertifikatkjeder designes smartere. Begge tilnærminger er riktige, bare for ulike systemer.

Ofte stilte spørsmål

Er ML-DSA det samme som Dilithium?

Ja, i praksis. ML-DSA er den offisielle NIST-standardiserte versjonen av algoritmen som tidligere gikk under navnet CRYSTALS-Dilithium i standardiseringskonkurransen. FIPS 204 spesifiserer ML-DSA som direkte avledet fra Dilithium-innsendelsen, og de fleste bibliotek bruker nå ML-DSA-navnet etter at standarden ble endelig i august 2024.

Må jeg bytte ut ECDSA med en gang?

Nei, ikke umiddelbart for de fleste virksomheter. NIST sin tidslinje setter 2030 som deprekeringsår og 2035 som forbudsår for klassiske 112-bits algoritmer som ECDSA P-256. De fleste sikkerhetsmyndigheter, deriblant NSM i Norge, anbefaler å starte med hybridløsninger nå framfor å fjerne ECDSA helt.

Hvorfor er ML-DSA-signaturer så mye større enn ECDSA?

Forskjellen kommer av matematikken bak algoritmene. ECDSA baserer seg på kompakte punkter på en elliptisk kurve, mens ML-DSA baserer seg på gitterstrukturer som krever langt mer data for å representere sikkert. Det er en direkte konsekvens av å bytte til et matematisk problem uten kjent kvante-snarvei.

Hvilken ML-DSA-variant bør jeg velge?

ML-DSA-65 regnes som standardvalget for de fleste applikasjoner og gir sikkerhet omtrent på nivå med AES-192. ML-DSA-44 passer for lettere bruksområder der båndbredde og lagring er ekstra begrenset. ML-DSA-87 er valget for nasjonale sikkerhetssystemer under CNSA 2.0 og andre bruksområder med høyeste sikkerhetskrav.

Påvirker ML-DSA ytelsen til nettsteder merkbart?

Ja, i hvert fall på håndtrykk-nivå. Et fullt bytte til ML-DSA-44 for alle signaturer i en typisk sertifikatkjede legger til 15 til 17 kilobyte ekstra data per TLS-håndtrykk, ifølge Cloudflares egne målinger. For høytrafikk-tjenester kan det bety merkbart mer utgående båndbredde og økt risiko for pakkefragmentering, spesielt på mobilnett med høyere pakketap enn faste linjer.

Hva er CNSA 2.0, og gjelder det norske virksomheter?

CNSA 2.0 er NSA sin Commercial National Security Algorithm-pakke, som setter formelle frister for amerikanske nasjonale sikkerhetssystemer: ny programvare skal bruke CNSA 2.0-signeringsalgoritmer, og full utfasing av eldre algoritmer skal være fullført innen 2030 til 2033. Kravet gjelder ikke direkte norske virksomheter, men fungerer som en anerkjent internasjonal referanse som NSM sine egne anbefalinger langt på vei speiler.

Kan Bitcoin og Ethereum bytte til ML-DSA?

Teknisk sett kan nye adresser signeres med ML-DSA eller andre post-kvante-algoritmer, men eksisterende adresser bygget på ECDSA over secp256k1 kan ikke signeres om i etterkant uten at eierne selv flytter midlene. Det gjør overgangen langt mer komplisert enn i sentraliserte systemer som skyleverandører kontrollerer fullt ut.

Hvor finner jeg et ferdig bibliotek for å teste ML-DSA?

Open Quantum Safe sitt liboqs-bibliotek er den mest brukte referanseimplementasjonen og støtter ML-DSA-44, ML-DSA-65 og ML-DSA-87. OpenSSL 3.5.0 og nyere har innebygd støtte, og Cloudflares CIRCL-bibliotek i Go tilbyr et alternativ for team som allerede bruker Go i infrastrukturen sin. Alle tre er åpen kildekode og egner seg godt til å teste hybridoppsett før produksjonssetting.