ML-DSA vs SLH-DSA: 3500x Raskere Signering [2026]

NIST gjorde det offisielt 13. august 2024: ML-DSA (FIPS 204) og SLH-DSA (FIPS 205) er nå de to standardiserte signaturalgoritmene som skal erstatte RSA og ECDSA når kvantedatamaskiner en dag blir kraftige nok til å knekke dem. To år senere, sommeren 2026, er valget mellom dem ikke lenger teoretisk. Cloudflare signerer trafikk til opprinnelsesservere med ML-DSA, Windows Server kan bygge hele sertifikatkjeder på algoritmen, og både AWS og Google Cloud har lagt støtte inn i sine nøkkeltjenester. Spørsmålet team stiller nå er ikke om de skal migrere, men hvilken av de to algoritmene som passer til hvilken jobb.

Svaret er ikke entydig. ML-DSA signerer opp mot 3500 ganger raskere enn SLH-DSA i enkelte tester, men SLH-DSA hviler på en langt mer konservativ sikkerhetsantagelse. Denne artikkelen går gjennom nøyaktige tall fra NISTs egne spesifikasjoner, ytelsesbenchmarker fra tre uavhengige kilder, kostnaden ved å kjøre signering i skyen, og en praktisk migreringsguide for norske og nordiske team som allerede planlegger overgangen.

Trusselen bak hastverket kalles “harvest now, decrypt later”: angripere samler inn kryptert trafikk og signerte data i dag, i påvente av en kvantedatamaskin som kan bryte dem senere. For signaturer er ikke risikoen datatyveri, men forfalskning av fremtidige sertifikater, kodepakker og transaksjoner dersom en angriper klarer å rekonstruere en privat nøkkel fra offentlig informasjon. Amerikanske myndigheter har allerede satt en konkret frist i Executive Order 14144, som krever at føderale systemer går over til TLS 1.3 eller etterfølgeren innen 2. januar 2030. Ingen tilsvarende norsk eller nordisk frist er vedtatt ennå, men bank-, telekom- og offentlig sektor i Norden følger normalt de samme NIST- og IETF-standardene som resten av Europa.

Hva er ML-DSA og SLH-DSA?

ML-DSA og SLH-DSA er de to digitale signaturalgoritmene NIST godkjente som del av sin post-kvante-standardiseringsprosess. Begge løser samme problem, nemlig å bevise at en melding, et sertifikat eller en kodepakke faktisk kommer fra den som hevder å ha signert den, uten at en fremtidig kvantedatamaskin skal kunne forfalske signaturen. Der de skiller seg er i den matematiske grunnmuren.

ML-DSA (Module-Lattice-Based Digital Signature Standard) bygger på CRYSTALS-Dilithium og er gitterbasert. SLH-DSA (Stateless Hash-Based Digital Signature Standard) bygger på SPHINCS+ og er hash-basert. NIST har selv gjort rollefordelingen tydelig: ML-DSA er hovedvalget for de fleste, mens SLH-DSA er en bevisst konservativ reserveløsning i tilfelle svakheter i gitterbasert kryptografi skulle dukke opp senere. Et tredje alternativ, FALCON (fremtidig FIPS 206), er fortsatt under utvikling og ventes ferdigstilt en gang i 2026 eller 2027.

Til sammenligning: RSA-signaturer og elliptiske kurve-signaturer (ECDSA) er fortsatt trygge mot dagens datamaskiner, men vil begge kunne knekkes av en tilstrekkelig kraftig kvantedatamaskin ved bruk av Shors algoritme. Det er derfor NIST har brukt over åtte år på denne standardiseringsprosessen.

Navnebyttet forvirrer fortsatt mange. Dilithium-teamet, som opprinnelig utviklet algoritmen bak ML-DSA, og SPHINCS+-teamet bak SLH-DSA, deltok begge i NISTs åpne konkurranse som startet i 2016. Da NIST formaliserte vinnerne som offisielle standarder i 2024, fikk algoritmene nye, formelle navn som følger NISTs egen navnekonvensjon for module-lattice- og hash-baserte konstruksjoner. Det er ikke uvanlig å se de gamle prosjektnavnene Dilithium og SPHINCS+ fortsatt brukt om hverandre med ML-DSA og SLH-DSA i biblioteker, dokumentasjon og forskningsartikler, men det er de samme algoritmene under panseret.

Bakgrunnen: NISTs post-kvante-standardisering

NIST publiserte FIPS 204 og FIPS 205 samtidig 13. august 2024, sammen med FIPS 203 (ML-KEM, algoritmen for nøkkelutveksling). Siden da har standardene fått samme formelle status som eldre kjente standarder som AES (FIPS 197) og SHA-2 (FIPS 180-4). I mai 2025 kom NIST-rapporten IR 8610, som bekreftet at flere ekstra signaturkandidater fortsatt evalueres i en egen runde, men at ML-DSA og SLH-DSA forblir kjernen i den ferdige baseline-standarden.

Verktøykjeden fulgte raskt etter. OpenSSL 3.5.0 (april 2025) la til innebygd støtte for ML-KEM, ML-DSA og SLH-DSA, uten behov for eksterne plugin-er som oqs-provider fra Open Quantum Safe-prosjektet. Debian Trixie, som kom i august 2025, fikk denne støtten rett inn i standard kryptografi-stacken. I desember 2025 ble en egen IANA-kodepunkt for ML-DSA registrert for TLS, og de første CMVP-sertifiseringene av en ML-DSA-modul kom i mars 2026. IETF-utkastet draft-ietf-tls-mldsa-02, sist oppdatert 22. mars 2026, spesifiserer nå hvordan ML-DSA skal brukes i TLS 1.3-håndtrykk og sertifikatkjeder, og forbyr eksplisitt bruk i TLS 1.2 og eldre.

Denne tidslinjen betyr at verken ML-DSA eller SLH-DSA lenger er eksperimentelle. De kjører i produksjonskritisk infrastruktur hos flere av verdens største teknologiselskaper, noe vi ser nærmere på lenger ned i artikkelen.

Verdt å presisere: ML-DSA og SLH-DSA er ikke de eneste post-kvante-algoritmene NIST arbeider med. Prosessen har egne spor for nøkkelutveksling (ML-KEM, allerede standardisert som FIPS 203) og for et fjerde signatur-spor med ekstra kandidater utover ML-DSA, SLH-DSA og FALCON, dokumentert i statusrapporten for standardiseringsprosessens fjerde runde. Disse ekstra kandidatene er ment som en ytterligere sikkerhetsmargin på lang sikt, ikke som en erstatning for de allerede ferdigstilte standardene, og har ingen produksjonsklar status i 2026.

Slik fungerer ML-DSA

ML-DSA tilhører familien gitterbaserte algoritmer og er direkte avledet fra CRYSTALS-Dilithium, en av finalistene i NISTs opprinnelige konkurranse. Sikkerheten hviler på at det er beregningsmessig vanskelig å løse bestemte problemer i høydimensjonale gitter, kjent som module-LWE og module-SIS. Disse problemene har ingen kjent effektiv løsning verken på klassiske eller kvantedatamaskiner, men de er nyere og matematisk mer komplekse enn hash-baserte antagelser.

Standarden definerer tre parametersett: ML-DSA-44, ML-DSA-65 og ML-DSA-87, tilsvarende NIST sikkerhetskategori 2, 3 og 5. Jo høyere tall, desto større nøkler og signaturer, men også høyere sikkerhetsmarginal. I praksis bruker de fleste TLS- og PKI-implementasjoner ML-DSA-44 eller ML-DSA-65 som standardvalg, mens ML-DSA-87 reserveres for spesielt sensitive systemer.

Et viktig poeng: signering med ML-DSA bruker en teknikk som kalles rejection sampling, der algoritmen noen ganger må forkaste og prøve på nytt internt før en gyldig signatur produseres. Det er derfor signeringstiden varierer mer enn verifiseringstiden i benchmarkene lenger ned i artikkelen. En NIST-presentasjon om batch-signering (“Batch me if you PQ-sign”) viser at gruppevis signering med ML-DSA kan gi 1,5 til 4,6 ganger høyere gjennomstrømning enn å signere én og én, uten at forsinkelsen per signatur øker med mer enn 25 prosent eller 0,5 millisekund. Det gjør algoritmen enda mer aktuell for tjenester som utsteder store mengder sertifikater eller tokens samtidig, som CA-er eller autentiseringstjenester.

Slik fungerer SLH-DSA

SLH-DSA er avledet fra SPHINCS+ og tilhører en helt annen familie: hash-baserte signaturer. I stedet for å stole på gitterproblemer, bygger SLH-DSA hele sikkerheten på egenskapene til en kryptografisk hashfunksjon, typisk SHA-256 eller SHAKE-256. Så lenge hashfunksjonen forblir kollisjonsresistent, forblir signaturen sikker. Dette gjør SLH-DSA til det mest konservative valget NIST har standardisert, fordi hash-funksjoners sikkerhet er langt bedre forstått og testet gjennom flere tiår enn gitterbasert kryptografi.

SLH-DSA leveres i seks hovedvarianter fordelt på tre sikkerhetsnivåer (128, 192 og 256 bit) og to profiler: “s” for small (minimerer signaturstørrelse, men signerer tregt) og “f” for fast (raskere signering, men større signatur). Hver variant finnes også i en SHA2- og en SHAKE-utgave, avhengig av hvilken hashfunksjon som brukes internt. NIST publiserte i tillegg et utkast til SP 800-230 i april 2026, som legger til ekstra, størrelsesoptimaliserte parametersett begrenset til maksimalt 2^24 signaturer per nøkkel, myntet på nisjebruk der antall signaturer er forutsigbart lavt.

Prisen for denne konservative tilnærmingen er ytelse. SLH-DSA bygger signaturen ved å vandre gjennom et stort tre av hash-verdier, en prosess som er beregningstung å signere med, men relativt rask å verifisere. Det gjenspeiles tydelig i tallene under.

Forskningsmiljøet jobber aktivt med å lukke ytelsesgapet. Et optimaliseringsprosjekt kalt SLotH, presentert på NISTs femte PQC-standardiseringskonferanse, viser at SHAKE-varianter av SLH-DSA kan gjøres opptil 300 ganger raskere med riktig implementasjon: signering med 128f-parametersettet kom ned i 4 903 978 klokkesykluser, mens verifisering med 128s-settet ble målt til bare 179 603 sykluser. Det er fortsatt langt fra ML-DSAs råhastighet, men det viser at dagens trege referanseimplementasjoner ikke nødvendigvis representerer et hardt tak for hva SLH-DSA kan levere i praksis.

Nøkkel- og signaturstørrelser: full tabell

Tallene under er hentet direkte fra Tabell 2 i FIPS 204 og de tilsvarende strukturreglene i FIPS 205 (offentlig nøkkel er alltid 2n byte, privat nøkkel alltid 4n byte, der n er hash-lengden). RSA-2048 og en typisk ECDSA-kurve er tatt med som referanse.

Algoritme	Type	Offentlig nøkkel	Privat nøkkel	Signatur	NIST-kategori
RSA-2048 (referanse)	Klassisk	256 byte	256 byte	256 byte	Ikke kvantesikker
ECDSA P-256 (referanse)	Klassisk	64 byte	32 byte	64 byte	Ikke kvantesikker
ML-DSA-44	Gitterbasert	1 312 byte	2 560 byte	2 420 byte	Kategori 2
ML-DSA-65	Gitterbasert	1 952 byte	4 032 byte	3 309 byte	Kategori 3
ML-DSA-87	Gitterbasert	2 592 byte	4 896 byte	4 627 byte	Kategori 5
SLH-DSA-128s	Hash-basert	32 byte	64 byte	7 856 byte	Kategori 1
SLH-DSA-128f	Hash-basert	32 byte	64 byte	17 088 byte	Kategori 1
SLH-DSA-192s	Hash-basert	48 byte	96 byte	16 224 byte	Kategori 3
SLH-DSA-192f	Hash-basert	48 byte	96 byte	35 664 byte	Kategori 3
SLH-DSA-256s	Hash-basert	64 byte	128 byte	29 792 byte	Kategori 5
SLH-DSA-256f	Hash-basert	64 byte	128 byte	49 856 byte	Kategori 5

Mønsteret er slående. SLH-DSA snur hele forholdet på hodet sammenlignet med ML-DSA og de klassiske algoritmene: nøklene er nesten latterlig små (32 til 128 byte), mens signaturen er enorm (opptil 49 856 byte, over 200 ganger større enn en RSA-2048-signatur). ML-DSA holder seg til et mer balansert forhold, med signaturer på 2,4 til 4,6 kilobyte, altså 3 til 20 ganger mindre enn SLH-DSA på tilsvarende sikkerhetsnivå.

Ytelse: signering og verifisering i praksis

Tre uavhengige benchmarker fra 2026 viser samme grunnleggende mønster, selv om maskinvaren varierer: ML-DSA signerer dramatisk raskere enn SLH-DSA, mens forskjellen i verifiseringstid er langt mindre.

Kilde og maskinvare	Algoritme	Nøkkelgenerering	Signering	Verifisering
ITB-studien (ARM-basert firmware)	ML-DSA-44	0,299 ms	0,734 ms	0,166 ms
ITB-studien (ARM-basert firmware)	SLH-DSA-SHA2-128s	206,066 ms	1 430,190 ms	1,159 ms
Ciphermind-benchmark	ML-DSA-44	0,042 ms	0,165 ms	0,040 ms
Ciphermind-benchmark	SLH-DSA-SHA2-128s	32,756 ms	246,849 ms	0,254 ms
Ciphermind-benchmark	SLH-DSA-SHA2-128f	0,506 ms	11,588 ms	0,703 ms
Passkeybridge (AWS Graviton4)	ML-DSA-87	–	0,62 ms	0,71 ms
Passkeybridge (AWS Graviton4)	SLH-DSA-SHAKE-256s	–	2 210 ms	3,4 ms

Tallene fra Passkeybridges Graviton4-tester er de mest slående: SLH-DSA-256s bruker rundt 3500 ganger lengre tid på å signere enn ML-DSA-87 på identisk maskinvare, mens verifiseringen bare er omtrent 5 ganger tregere. Det gjentar seg i de to andre kildene. Selv den raskeste SLH-DSA-varianten, 128f, er fortsatt 15 til 70 ganger tregere å signere med enn ML-DSA-44, avhengig av implementasjon og maskinvare.

Konsekvensen er praktisk: for systemer som signerer ofte, altså TLS-håndtrykk, API-kall eller sanntidstransaksjoner, er SLH-DSA rett og slett for tregt. For systemer som signerer sjelden men verifiserer ofte, som fastvareoppdateringer eller sertifikatutstedelse med lang levetid, er SLH-DSAs treghet på signeringssiden mindre relevant.

Verdt å merke seg: tallene over varierer mer enn de fleste andre benchmarker i kryptografi, nettopp på grunn av rejection sampling i ML-DSA. En egen studie publisert i mars 2026 målte ML-DSA-44-signering til et gjennomsnitt på 158,9 millisekunder, men med et spenn fra 70,1 til hele 541,7 millisekunder i verste tilfelle, en variasjonskoeffisient på 67,5 prosent og en 99. persentil på 489,9 millisekunder. Forskjellen mellom denne studien og de sub-millisekund-tallene i tabellen over illustrerer hvor mye implementasjon, maskinvare og om rejection-sampling-forsøk telles med, påvirker resultatet. Konklusjonen om at ML-DSA er dramatisk raskere enn SLH-DSA står likevel fast på tvers av alle kildene.

Maskinvareakselerasjon og optimalisering

Begge algoritmene er fortsatt unge nok til at det finnes betydelig uutnyttet ytelse i implementasjonene. For ML-DSA handler mye av arbeidet om å redusere variasjonen som kommer fra rejection sampling, blant annet gjennom bedre polynomaritmetikk og vektoriserte instruksjoner på moderne prosessorer som AWS Graviton4. For SLH-DSA er hovedinnsatsen rettet mot å gjøre selve hash-tre-vandringen raskere, som SLotH-prosjektets 300 ganger raskere SHAKE-implementasjon viser.

Chipprodusenter har også begynt å bevege seg. ARMs PSA Crypto API-spesifikasjon fikk i 2025 et eget forslag for å definere et standardgrensesnitt mot SLH-DSA (SPHINCS+), med støtte for alle tre sikkerhetsnivåene 128, 192 og 256 bit. Målet er at fremtidige mikrokontrollere og HSM-er kan tilby innebygd akselerasjon for begge algoritmene på samme måte som AES-NI i dag akselererer symmetrisk kryptering i CPU-er. Frem til den maskinvaren blir standard, er det programvareoptimalisering som avgjør om SLH-DSA i det hele tatt er praktisk brukbart utover nisjetilfeller med lavt signeringsvolum.

Sikkerhetsmodell: gitterproblemer mot hashfunksjoner

Den viktigste ikke-tekniske forskjellen mellom ML-DSA og SLH-DSA handler ikke om hastighet, men om hvor mye tillit du legger i den underliggende matematikken. ML-DSAs sikkerhet hviler på at module-LWE- og module-SIS-problemer forblir vanskelige å løse. Ingen praktisk angrepsvei er kjent i dag, men gitterbasert kryptografi er en relativt ung gren av faget sammenlignet med hashfunksjoner, og forskningsmiljøet fortsetter å teste antagelsene.

NIST har vært tydelig på at nylige kryptanalytiske funn mot andre gitterbaserte forslag ikke påvirker ML-DSA eller ML-KEM, og at begge “er klare for implementering nå”, ifølge NISTs egne oppdateringer. Likevel er nettopp denne typen usikkerhet grunnen til at SLH-DSA finnes som standard i utgangspunktet.

SLH-DSAs sikkerhet reduseres til langt enklere og bedre utforskede egenskaper: kollisjons- og preimage-resistens i en hashfunksjon som SHA-256 eller SHAKE-256. Dette er antagelser kryptografer har testet og angrepet i flere tiår, og de er strukturelt enklere enn algebraiske gitterproblemer. Det er nettopp derfor Cloudflare i sin egen tekniske gjennomgang beskriver SLH-DSA som et bevisst “big-signature, conservative, backup”-valg, altså en forsikring i tilfelle lattice-baserte antagelser en dag skulle vise seg svakere enn antatt.

For team som ikke ønsker å velge mellom de to sikkerhetsmodellene i det hele tatt, peker flere IETF-utkast mot komposittsertifikater, der en enkelt sertifikatkjede bærer både en klassisk (RSA eller ECDSA), en gitterbasert (ML-DSA) og eventuelt en hash-basert (SLH-DSA) signatur samtidig. Fordelen er at et system forblir gyldig selv om én av signaturmodellene skulle falle, ulempen er at sertifikatstørrelsen øker ytterligere oppå den allerede større ML-DSA- eller SLH-DSA-signaturen. Denne tilnærmingen er fortsatt under standardisering og ikke i utbredt produksjonsbruk per august 2026, men den er verdt å følge med på for organisasjoner med spesielt høye krav til kontinuitet.

Prising: hva koster signering i skyen

Ingen av skyleverandørene har egen prislinje for “post-kvante signering” ennå. I stedet faller ML-DSA- og SLH-DSA-nøkler inn under de eksisterende prisklassene for asymmetriske operasjoner, som i praksis blir dyrere enn symmetrisk kryptering eller RSA-2048 fordi de klassifiseres som “avanserte” nøkkeltyper. Det er verdt å presisere at prisene i tabellen under gjelder selve signeringsoperasjonen, ikke lagring eller overføring av selve signaturen. En SLH-DSA-signatur på 49 856 byte koster ikke mer å produsere i kroner og øre enn en ML-DSA-signatur på 4 627 byte hos noen av de tre store, men den koster vesentlig mer i båndbredde, lagringsplass i sertifikatlogger og CPU-tid brukt på selve signeringen, som tabellen med ytelsestall lenger opp illustrerer.

Leverandør	Nøkkellagring per måned	Pris per 10 000 signeringsoperasjoner	PQC-støtte i dag
AWS KMS	1 USD per nøkkel	0,03 USD (RSA-2048/symmetrisk) / 0,15 USD (annen asymmetrisk)	Støtter ML-DSA-nøkler og signering (ikke via CloudHSM)
Azure Key Vault (standard)	Ingen grunnavgift	0,03 USD flat sats	Ingen offisiell ML-DSA/SLH-DSA-støtte i standard Key Vault ennå
Azure Key Vault (HSM-beskyttet)	1–5 USD per nøkkel, avhengig av type	0,03–0,15 USD, avhengig av nøkkeltype	Ingen offisiell ML-DSA/SLH-DSA-støtte ennå
Google Cloud KMS (programvare)	Ca. 0,06 USD per nøkkelversjon	0,03 USD flat sats	Støtter ML-DSA-65 og SLH-DSA-SHA2-128s
Google Cloud KMS (HSM)	Ca. 2,50 USD per nøkkel	0,03 USD flat sats	Samme PQC-støtte som programvarenivå

Det praktiske bildet i august 2026: Google Cloud KMS er den eneste av de tre store som eksplisitt lister støtte for begge algoritmene, med ML-DSA-65 og SLH-DSA-SHA2-128s tilgjengelig direkte i tjenesten. AWS KMS støtter ML-DSA-nøkler og signering, men foreløpig ikke via CloudHSM. Selve kronebeløpet per operasjon er identisk med det du allerede betaler for ECDSA eller RSA i “avansert”-kategorien, så kostnadsøkningen ved å bytte til ML-DSA handler mindre om pris per signatur og mer om båndbreddekostnaden signaturene skaper i nettverket, som vi ser på under.

Dedikert HSM-maskinvare gir et annet kostnadsbilde. En sammenligning fra QCecuring, satt opp med et scenario på 10 HSM-beskyttede asymmetriske nøkler og 50 000 signeringsoperasjoner i måneden, viser at AWS CloudHSM lander på rundt 1 168 USD i måneden (per HSM-instans, operasjoner inkludert), Azure Managed HSM på rundt 3 287 USD i måneden (per HSM-pool), mens Google Cloud HSM kommer ut vesentlig billigere på rundt 60 USD i måneden i grunnkostnad pluss omtrent 1,50 USD for selve operasjonene. For team som allerede har dedikert HSM-infrastruktur til RSA eller ECDSA, vil overgangen til ML-DSA eller SLH-DSA i de fleste tilfeller skje innenfor samme kostnadsramme, siden det er nøkkeltype og volum, ikke algoritmefamilie, som styrer prisen hos de tre store.

Båndbredde- og infrastrukturkostnad ved store signaturer

Her blir forskjellen mellom de to algoritmene brått mye mer konkret. Cloudflare publiserte 28. oktober 2025 en detaljert analyse av hva det koster å bytte hele TLS-trafikken til ML-DSA. Selskapet håndterer rundt 18 millioner TLS-tilkoblinger i sekundet. Å bytte alle signaturer til ML-DSA-44 legger til rundt 15 kilobyte data per håndtrykk, noe som til sammen krever 2,1 terabit i sekundet med ekstra kapasitet, tilsvarende omtrent 0,5 prosent av Cloudflares totale nettverkskapasitet.

Et typisk TLS-håndtrykk i dag sender rundt 1 248 byte autentiseringsdata (fem signaturer og to offentlige nøkler i en full sertifikatkjede). Bytt disse til ML-DSA-ekvivalenter, og tallet hopper til over 14 700 byte, godt forbi TCPs innledende overbelastningsvindu. Cloudflares egne tester fra 2024 viser at når nyttelasten krysser 10 kilobyte, utløses ofte en ekstra rundtur (RTT), noe som i noen tilfeller kan gi over 60 prosent tregere håndtrykk. Ved rundt 40 kilobyte inntreffer et nytt hopp fordi hele det innledende overbelastningsvinduet fylles opp.

SLH-DSA gjør problemet enda tydeligere. IETFs utkast om post-kvante DNSSEC, datert 16. oktober 2025, peker på at SLH-DSA-signaturer (7 856 til 49 856 byte) overskrider DNS sin UDP-grense på 1 232 byte med god margin, noe som tvinger frem TCP-fallback og øker forsinkelse og belastning på DNS-resolvere. Det er nettopp derfor Let’s Encrypt 3. juni 2026 annonserte en satsing på Merkle Tree Certificates (MTC), et format som komprimerer beviset for at et sertifikat er gyldig ned til rundt 736 byte for batcher på 4,4 millioner sertifikater. Målet er en staging-versjon sent i 2026 og produksjonsklar drift i 2027.

Virkelige eksempler: hvem bruker ML-DSA og SLH-DSA i dag

Post-kvante-signaturer er ikke lenger noe som bare finnes i forskningspapirer. Her er sju konkrete eksempler på reell bruk gjennom 2025 og 2026.

Cloudflare har, ifølge selskapets egen dokumentasjon oppdatert 3. juli 2026, tatt i bruk ML-DSA for autentisering på forbindelsen mellom Cloudflare og opprinnelsesserveren din (“PQC to your origin”). Støtte for besøkende-til-kant og interne forbindelser er under utvikling.
OpenSSL og Debian fikk innebygd ML-DSA- og SLH-DSA-støtte med OpenSSL 3.5.0 i april 2025, og denne versjonen fulgte med i Debian Trixie fra august 2025, noe som gjør algoritmene tilgjengelig i standard Linux-verktøykjeder uten ekstra plugin-er.
Windows Server / Active Directory Certificate Services kan siden maidoppdateringen i 2026 bygge hele ML-DSA-sertifikatkjeder, ifølge dokumentasjon fra både S5 Technology (17. juni 2026) og Encryption Consulting (28. juni 2026). Det inkluderer rot-, underordnede-, enterprise- og frittstående CA-er, samt utstedelse av ML-DSA-sertifikater for kodesignering, TLS, bruker- og maskinautentisering og signering av OCSP-svar.
AWS KMS og Google Cloud KMS støtter begge ML-DSA i produksjon, ifølge Wiz’ gjennomgang publisert 28. mai 2026. Google går lenger og tilbyr også SLH-DSA-SHA2-128s direkte i tjenesten.
Let’s Encrypt annonserte 3. juni 2026 en veikart mot post-kvante WebPKI basert på Merkle Tree Certificates, med mål om en staging-testperiode sent i 2026 og produksjonsdrift i 2027.
IETF oppdaterte 22. mars 2026 utkastet draft-ietf-tls-mldsa-02, som formelt spesifiserer bruken av ML-DSA i TLS 1.3-håndtrykk og sertifikatkjeder, samtidig som det utelukker støtte i eldre TLS-versjoner.
Thales har publisert en egen ML-DSA-programmeringsguide for sin Luna HSM-serie, som reproduserer de offisielle FIPS 204-nøkkelstørrelsene og viser hvordan ML-DSA-signering integreres i maskinvaresikrede nøkkelmoduler for banker og annen kritisk infrastruktur.

Et fellestrekk er tydelig: nesten all produksjonsbruk så langt handler om ML-DSA. SLH-DSA finnes i verktøykjedene og i enkelte skytjenester, men brukes foreløpig mest som en bevisst reserve, ikke som hovedvalg for høyvolum-trafikk. Mønsteret gjentar seg på tvers av alle sju eksemplene over: uansett om det er Cloudflares nettverk, Microsofts sertifikattjenester eller skyleverandørenes nøkkelhåndtering, er ML-DSA det som faktisk bærer produksjonstrafikk i dag, mens SLH-DSA i hovedsak venter i kulissene til et konkret behov for den ekstra konservatismen dukker opp.

Bruksområder: når bør du velge hvilken

Valget mellom ML-DSA og SLH-DSA avhenger nesten alltid av hvor ofte du signerer versus hvor ofte du verifiserer, og hvor lenge signaturen må forbli gyldig. En enkel tommelfingerregel: jo høyere signeringsfrekvens, desto sterkere argument for ML-DSA, og jo lengre levetid signaturen trenger å ha tillit over, desto sterkere argument for å i det minste vurdere SLH-DSA som et sekundært lag.

TLS-sertifikater og WebPKI: ML-DSA-44 eller ML-DSA-65. Høyt volum og lav toleranse for forsinkelse gjør SLH-DSA upraktisk her, spesielt gitt Cloudflares tall om håndtrykk-oppblåsing.
Kodesignering og fastvareoppdateringer: Begge kan fungere, men SLH-DSA passer spesielt godt fordi signering skjer sjelden (én gang per utgivelse), mens verifisering skjer mange ganger på enheter i felt, noe SLH-DSAs “rask verifisering, treg signering”-profil er skreddersydd for.
Bedrifts-PKI og intern CA-hierarki: ML-DSA via for eksempel AD CS, siden det gir lavest driftskompleksitet og er det Microsoft, Cloudflare og skyleverandørene faktisk har bygget verktøy rundt.
Blokkjede- og validatornoder: ML-DSA, av rene ytelsesgrunner. Bransjeanalyser peker på at ML-DSA-44 signerer 4 til 5 ganger raskere enn ECDSA og bare rundt 2 ganger tregere å verifisere, mens SLH-DSAs treghet ville skapt flaskehalser i høyfrekvent blokkproduksjon.
Langtidsarkivering og statlig eID med krav om tiår-lang tillit: SLH-DSA som konservativt alternativ eller sekundærsignatur, nettopp fordi den hash-baserte sikkerhetsmodellen er bedre testet over tid enn gitterbasert kryptografi.
DNSSEC: Verken ML-DSA eller SLH-DSA er problemfrie på grunn av UDP-grensen på 1 232 byte, men ML-DSA er det mer realistiske alternativet av de to siden SLH-DSA-signaturer er flere ganger større.

Migreringsguide: fra RSA og ECDSA til post-kvante-signaturer

Norske og nordiske virksomheter som allerede planlegger overgangen, følger i stor grad samme rekkefølge som Cloudflare, Microsoft og de store skyleverandørene har testet ut gjennom 2025 og 2026.

Kartlegg all eksisterende bruk av RSA og ECDSA på tvers av TLS-sertifikater, kodesignering, SSH-nøkler og DNSSEC. Uten en fullstendig oversikt over hvor nøklene faktisk brukes, er det umulig å prioritere riktig rekkefølge på migreringen.
Oppgrader kryptografibiblioteker til versjoner med innebygd ML-DSA/SLH-DSA-støtte, som OpenSSL 3.5 eller nyere, fremfor å basere produksjon på eksperimentelle plugin-er som oqs-provider. Dette alene fjerner store deler av kompleksiteten, siden algoritmene da følger med standard sikkerhetsoppdateringer.
Bygg et parallelt ML-DSA CA-hierarki for intern PKI, gjerne med samme verktøy dere allerede har, som AD CS på Windows Server 2025. Kjør det parallelt med den eksisterende RSA/ECDSA-hierarkiet i en avgrenset periode før noe byttes ut helt.
Velg hybrid- eller ren PQ-tilnærming for TLS. IETF anbefaler i overgangsperioden hybride nøkkelutvekslinger (for eksempel X25519MLKEM768) kombinert med enten klassiske eller PQ-signaturer, avhengig av risikoprofil og hvor konservativ organisasjonen ønsker å være.
Test håndtrykk-størrelse og forsinkelse før produksjonssetting. Følg spesielt med på Cloudflares terskel på rundt 10 kilobyte, der en ekstra rundtur kan gi merkbart tregere tilkoblinger på ustabile nettverk, og mål effekten separat på mobilnett og faste linjer.
Rull ut ML-DSA-sertifikater for interne tjenester og kodesignering først, siden konsekvensen av feil er lavere enn i offentlig WebPKI. Bruk denne fasen til å bygge egen driftserfaring før dere rører publikumsvendte systemer.
Følg med på CA/Browser Forum sine kommende krav til offentlig tiltrodde ML-DSA-sertifikater, ventet sent i 2026 eller i 2027, før dere satser på PQC i publikumsvendte TLS-sertifikater. Sett en intern milepæl knyttet til dette, ikke bare til egen teknisk klarhet.
Vurder SLH-DSA spesifikt for langtidsarkivering, fastvaresignering eller andre tilfeller der konservativ sikkerhet veier tyngre enn ytelse, og dokumenter begrunnelsen slik at valget kan revurderes når FALCON (FIPS 206) etter hvert blir tilgjengelig som et tredje alternativ.

Fordeler og ulemper

ML-DSA, fordeler: Signaturer på 2,4 til 4,6 kilobyte, altså langt mindre enn SLH-DSA. Signering og verifisering skjer på under ett millisekund i de fleste benchmarker. Bredest verktøystøtte i dag, med OpenSSL 3.5, AWS KMS, Google Cloud KMS og Windows AD CS. NISTs eget hovedvalg for de fleste bruksområder.

ML-DSA, ulemper: Hviler på en yngre matematisk antagelse (module-lattice) enn hash-baserte alternativer. Signaturene er fortsatt 9 til 70 ganger større enn en klassisk ECDSA-signatur. Historikken med reelle angrep er kortere enn for hash-baserte metoder, noe som er selve grunnen til at NIST valgte å standardisere et helt annet matematisk fundament ved siden av, i stedet for å satse alt på gitterbasert kryptografi alene.

SLH-DSA, fordeler: Sikkerheten reduseres til velkjente hash-funksjonsegenskaper, den mest konservative antagelsen NIST har standardisert. Offentlige og private nøkler er ekstremt små (32 til 128 byte). Verifisering er rask og konkurransedyktig selv om signering ikke er det.

SLH-DSA, ulemper: Signering kan ta fra titalls millisekunder til over to sekunder avhengig av parametersett, opptil 3500 ganger tregere enn ML-DSA i noen tester. Signaturene er enorme, opptil 49 856 byte. Upraktisk for høyfrekvente, interaktive protokoller som TLS-håndtrykk i stor skala.

Norge og Norden: hvorfor overgangen haster nå

Ingen norsk eller nordisk myndighet har foreløpig satt en bindende frist for post-kvante-signaturer, i motsetning til USAs Executive Order 14144 med sin frist 2. januar 2030 for føderale systemer. I praksis følger norske banker, teleselskaper og offentlige etater likevel de samme NIST- og IETF-standardene som resten av Europa, ganske enkelt fordi det er disse standardene leverandørene av TLS-biblioteker, skytjenester og HSM-maskinvare bygger mot. Når OpenSSL, Windows Server, AWS og Google Cloud alle har lagt til ML-DSA-støtte gjennom 2025 og 2026, blir det i praksis også standarden nordiske virksomheter arver, uavhengig av nasjonal lovgivning.

Det som gjør signaturalgoritmer spesielt relevant for sektorer som bank og offentlig eID, er at forfalskede signaturer kan gi varig skade selv om selve kommunikasjonen aldri blir avlyttet. En angriper som klarer å forfalske et sertifikat eller en kodesignatur, kan late som en tiltrodd part i årevis fremover. Det er nettopp derfor NIST har standardisert to algoritmer med ulik matematisk grunnmur, ikke bare én, slik at kritisk infrastruktur ikke står og faller på om én enkelt antagelse holder.

Verdikt: hvilken bør du velge

Tallene peker i én klar retning for de fleste. Med signaturer 3 til 20 ganger mindre og signering opptil 3500 ganger raskere, er ML-DSA det praktiske standardvalget for TLS, bedrifts-PKI, blokkjeder og alt annet med jevnlig, høyfrekvent signering. Det er også algoritmen skyleverandørene og Microsoft har bygget mest verktøy rundt gjennom 2025 og 2026, og den Cloudflare selv omtaler som løsningen som “må duge” frem til noe bedre kommer, i påvente av FALCON (FIPS 206).

SLH-DSA er ikke et alternativ til ML-DSA i de fleste sammenhenger, det er en forsikring. Bruk den der signering skjer sjelden og konsekvensen av en fremtidig svakhet i gitterbasert kryptografi er uakseptabel, som fastvaresignering, rot-CA-lag eller arkivering med krav om tillit i flere tiår. For alt annet: velg ML-DSA, test håndtrykk-størrelsen mot Cloudflares 10-kilobyte-terskel, og hold SLH-DSA klar som reserve.

Ofte stilte spørsmål

Hva er forskjellen mellom ML-DSA og SLH-DSA?

ML-DSA (FIPS 204) er gitterbasert og avledet fra CRYSTALS-Dilithium, med små, raske signaturer på 2,4 til 4,6 kilobyte. SLH-DSA (FIPS 205) er hash-basert og avledet fra SPHINCS+, med svært små nøkler men store signaturer på 7,8 til 49,8 kilobyte og mye tregere signering.

Er ML-DSA og SLH-DSA det samme som Kyber og Dilithium?

Nei, men de henger sammen. Dilithium ble standardisert som ML-DSA, mens Kyber ble standardisert som ML-KEM (FIPS 203), algoritmen for nøkkelutveksling, ikke signering. SLH-DSA kommer fra et helt annet forslag, SPHINCS+, og har ingen direkte forgjenger med et eget kortnavn.

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

SLH-DSA bygger signaturen ved å bevise gyldighet gjennom et stort hash-tre, noe som krever mange hash-verdier i selve signaturen. ML-DSA bruker i stedet en mer kompakt algebraisk struktur basert på gitterproblemer, som gir vesentlig mindre signaturer for samme sikkerhetsnivå.

Kan jeg bruke ML-DSA og SLH-DSA sammen med RSA i en overgangsperiode?

Ja. IETF anbefaler hybride løsninger i overgangsfasen, der klassiske og post-kvante-algoritmer brukes samtidig, slik at systemet forblir sikkert selv om én av de to skulle vise seg sårbar. Dette gjelder først og fremst nøkkelutveksling (ML-KEM kombinert med ECDHE), men tilsvarende komposittmodeller for signaturer er under utvikling.

Støtter nettleserne ML-DSA-sertifikater i dag?

Ikke fullt ut. Cloudflare bruker foreløpig ML-DSA mellom seg selv og opprinnelsesservere, ikke mot sluttbrukerens nettleser. Bredt tiltrodd offentlig støtte i WebPKI venter på oppdaterte krav fra CA/Browser Forum, som ikke ventes før sent i 2026 eller i løpet av 2027.

Hvilken algoritme bør jeg velge for kodesignering?

Begge er teknisk sett egnet siden kodesignering skjer sjelden. ML-DSA er enklest å komme i gang med gitt dagens verktøystøtte i Windows AD CS og OpenSSL. SLH-DSA er verdt å vurdere for fastvare med svært lang levetid i felt, der konservativ sikkerhet er viktigere enn signeringstid.

Påvirker post-kvante-signaturer båndbreddekostnadene mine?

Ja, målbart. Cloudflare beregner at en full overgang til ML-DSA-44 krever 2,1 terabit i sekundet ekstra kapasitet på tvers av selskapets nettverk, omtrent 0,5 prosent av total kapasitet. For mindre virksomheter er den relative økningen i håndtrykk-størrelse den samme, selv om det absolutte tallet blir mindre synlig.

Når blir FALCON (FIPS 206) tilgjengelig som tredje alternativ?

FALCON er valgt av NIST som et fremtidig, kompakt gitterbasert signaturalternativ, men er fortsatt under utvikling som utkast til FIPS 206. Ferdigstillelse ventes en gang i 2026 eller 2027, ifølge NISTs egne statusoppdateringer.

Finnes det maskinvare som akselererer ML-DSA og SLH-DSA?

Ikke som standard ennå. ARM har publisert et forslag til et eget PSA Crypto API-grensesnitt for SLH-DSA, og forskningsprosjekter som SLotH har vist opptil 300 ganger raskere SHAKE-implementasjoner gjennom programvareoptimalisering. Fullverdig maskinvareakselerasjon på linje med AES-NI for symmetrisk kryptering finnes foreløpig ikke i utbredt bruk for noen av de to algoritmene.

Hvor lang tid tar en migrering til ML-DSA eller SLH-DSA?

Det avhenger av hvor mange systemer som bruker RSA eller ECDSA i dag, men mønsteret hos Cloudflare, Microsoft og de store skyleverandørene har vært en trinnvis prosess over 12 til 24 måneder: først biblioteksoppgradering, deretter interne piloter, så gradvis utrulling til produksjon internt, og til slutt offentlig WebPKI-støtte når CA/Browser Forum har oppdatert kravene sine. De fleste organisasjoner bør regne minst ett år fra kartlegging til full intern produksjonsdrift av ML-DSA, gitt at kryptografibibliotekene allerede støtter algoritmen.

Se også flere artikler i kategorien Kryptografi.

Kilder: NIST FIPS 204, NIST FIPS 205, NIST Post-Quantum Cryptography Project, Cloudflare-bloggen, Open Quantum Safe (ML-DSA), Open Quantum Safe (SLH-DSA) og IETF-utkastet for ML-KEM i TLS 1.3.