NIST PQC-standarder förklarade: FIPS 203, 204 och 205 för företagsteam

Snabbt svar: NIST slutförde tre postkvantkryptografistandarder den 13 augusti 2024: FIPS 203 (ML-KEM) för nyckeletablering, FIPS 204 (ML-DSA) för allmänna digitala signaturer och FIPS 205 (SLH-DSA) som en konservativ, hashbaserad signaturreserv. De flesta företagsdistributioner använder som standard ML-KEM-768 och ML-DSA-65 för civilt bruk, eller ML-KEM-1024 och ML-DSA-87 för CNSA 2.0-miljöer, och reserverar SLH-DSA för snäva fall där algoritmdiversitet är viktigare än prestanda.

Tre standarder som publiceras samma dag är inte detsamma som tre standarder som löser samma problem. Företagsteam frågar sig hela tiden vilket FIPS-dokument som faktiskt gäller för deras TLS-stack, deras kodsigneringspipeline eller deras certifikatutfärdare, och det ärliga svaret är att FIPS 203, 204 och 205 aldrig var avsedda att konkurrera med varandra. De täcker olika uppgifter, har olika prestandaprofiler och befinner sig vid olika punkter av implementeringsmognad mellan bibliotek, HSM:er och plattformar år 2026.

Den här guiden bryter ner vad varje standard faktiskt specificerar, jämför ML-KEM, ML-DSA och SLH-DSA direkt, och mappar var och en till användningsfallet, prestandaprofilen och migreringsberoendet som bör styra beslutet. För en snabbare, beslutsfokuserad version av denna jämförelse och de vanligaste urvalsmisstagen, se vår beslutsguide för ML-KEM vs ML-DSA vs SLH-DSA.

Key Takeaways

• FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) slutfördes av NIST den 13 augusti 2024, vilket avslutade en åttaårig offentlig utvärderingsprocess.
• ML-KEM löser nyckeletablering; ML-DSA och SLH-DSA löser digitala signaturer. De är inte utbytbara, och de flesta system behöver både en KEM och en signaturalgoritm.
• ML-DSA är standardvärdet för generella signaturer; SLH-DSA byter prestanda och storlek mot ett konservativt, hashbaserat säkerhetsantagande oberoende av gittermatematik.
• Valet av parameteruppsättning beror på distributionsmålet: ML-KEM-768 och ML-DSA-65 för civila system, ML-KEM-1024 och ML-DSA-87 där CNSA 2.0 gäller.
• Implementeringsmognad varierar kraftigt beroende på algoritm och plattform år 2026, och det är just den mognadsskillnaden, inte algoritmpreferensen, som bör driva sekvenseringen.

Vad FIPS 203, 204 och 205 faktiskt standardiserar

NISTs postkvantkryptografiprojekt började 2016 med en öppen inbjudan att lämna in algoritmförslag och genomgick flera omgångar av offentlig kryptanalys innan NIST valde ut finalister 2022. Handelsministern godkände de resulterande standarderna den 13 augusti 2024, med verkan från och med följande dag.

Standard	Algoritm	Baserat på	Funktion	Ersätter
FIPS 203	ML-KEM (modulgitterbaserad nyckelinkapslingsmekanism)	KRISTALLER-Kyber	Nyckeletablering	RSA och Diffie-Hellman nyckelutbyte, ECDH
FIPS 204	ML-DSA (modulgitterbaserad digital signaturalgoritm)	KRISTALLER-Dilitium	Digitala signaturer	RSA- och ECDSA-signaturer
FIPS 205	SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)	SPHINCS+	Digitala signaturer	RSA- och ECDSA-signaturer, som en konservativ reserv

ML-KEM är en nyckelinkapslingsmekanism, den postkvantmässiga motsvarigheten till att etablera en delad hemlighet över en osäker kanal, det jobb som den klassiska Diffie-Hellman och ECDH utför idag. ML-DSA och SLH-DSA är båda digitala signaturalgoritmer som bevisar att ett meddelande, certifikat eller programvaruartefakt kom från en specifik privat nyckel och inte ändrades, det jobb som RSA och ECDSA utför idag. En fjärde standard, FN-DSA (FALCON), förblev ett utkast som FIPS 206 fram till mitten av 2026, och NIST valde också HQC år 2025 som en strukturellt oberoende backup-KEM till ML-KEM.

ML-KEM vs. ML-DSA vs. SLH-DSA i korthet

De tre algoritmerna skiljer sig åt i mer än bara funktion. Nyckel- och signaturstorlekar, säkerhetsantagandet som var och en vilar på och beräkningskostnaden avgör var och en passar in i en verklig implementering.

Fast egendom	ML-KEM (FIPS 203)	ML-DSA (FIPS 204)	SLH-DSA (FIPS 205)
Säkerhetsgrund	Modulinlärning med fel (gitter)	Modulinlärning med fel och modullösning med korta heltal (gitter)	Endast hashfunktionssäkerhet, inget gitterantagande
Parameteruppsättningar	ML-KEM-512, 768, 1024	ML-DSA-44, 65, 87	Flera, t.ex. SLH-DSA-128s/f, 192s/f, 256s/f
Civilt försummelse	ML-KEM-768 (publik nyckel ~1 568 byte, chiffertext ~1 568 byte)	ML-DSA-65 (publik nyckel ~2 592 byte, signatur ~4 627 byte)	Inte en standard; används selektivt
CNSA 2.0-parameter	ML-KEM-1024 (publik nyckel ~1 568 byte, chiffertext ~1 568 byte)	ML-DSA-87 (publik nyckel ~2 592 byte, signatur ~4 627 byte)	Ingår inte i CNSA 2.0-sviten
Signatur-/chiffertextstorlek kontra klassisk	Ungefär 15 till 25 gånger större än ECDH	Ungefär 15 till 50 gånger större än ECDSA	Ungefär 100 till 700 gånger större än ECDSA (7 856 till 49 856 byte)
Relativ hastighet	Snabb; jämförbar med eller snabbare än klassiska KEM:er på modern hårdvara	Snabb; lämplig för signering av stora volymer	Långsam; signering kan ta hundratals millisekunder per operation
Bästa passform	TLS, VPN och valfri nyckelutbyte	Allmän signering: kod, dokument, certifikat, protokoll	Långlivad signering med låg volym där algoritmdiversitet är viktigast

Storleksskillnaden spelar roll operativt, inte bara akademiskt. En kedja med fyra certifikat byggd på ML-DSA-87 bär ungefär 15 till 20 gånger mer signaturdata än samma kedja på ECDSA P-384, vilket visar sig som större TLS-handskakningar, fler OCSP-svarsbyte och högre HSM-signeringsdataflödeskrav. SLH-DSAs signaturer är ytterligare en till två storleksordningar större, vilket är den direkta avvägningen för ett säkerhetsantagande som inte är beroende av att gitterhårdheten håller.

Att välja rätt standard per användningsfall

De flesta system behöver en KEM och en signaturalgoritm som arbetar tillsammans, inte ett enda val mellan de tre.

• TLS- och VPN-nyckelutbyte: ML-KEM passar perfekt. Hybridkonstruktioner som X25519MLKEM768 kombinerar den med ett klassiskt nyckelutbyte under övergångsfönstret.
• Kodsignering och firmwaresignering: ML-DSA är den praktiska standarden. Signerade artefakter behöver ofta förbli verifierbara i flera år, och ML-DSAs prestandaprofil stöder den signeringsvolym som de flesta byggpipelines kräver.
• Certifikatutfärdarens hierarkier: ML-DSA är det primära valet för utfärdande och rot-CA:er, och följer samma parameterlogik som kodsignering.
• Signaturer med hög säkerhet, låg volym och lång livslängd: SLH-DSA passar där en organisation vill ha ett andra, strukturellt oberoende signaturschema som försäkring mot en framtida svaghet i gitterkryptografi, och accepterar kostnaden för storlek och hastighet i utbyte.
• Nationella säkerhetssystem och den försvarsindustriella basen: ML-KEM-1024 och ML-DSA-87 är de obligatoriska parameteruppsättningarna enligt CNSA 2.0; SLH-DSA ingår inte i den sviten.

Implementeringsmognad år 2026

Standardstatus och driftsättningsberedskap är inte samma sak. Alla tre FIPS-standarder är slutgiltiga, men biblioteks-, HSM- och plattformsstöd för var och en har mognat i olika takt.

ML-KEM har det bredaste stödet för webbläsare och TLS-bibliotek av de tre, med hybridnyckelutbyte som redan är förhandlingsbart i nuvarande versioner av större webbläsare och TLS-stackar. ML-DSA-stöd har nått vanliga företags-PKI-plattformar, inklusive allmän tillgänglighet i Microsoft Active Directory Certificate Services på Windows Server 2025 från och med maj 2026-uppdateringen, även om täckningen varierar beroende på scenario: kodsignering är den mest tillförlitliga vägen, medan bredare TLS-, VPN- och fjärrskrivbordsscenarier kräver validering arbetsbelastning för arbetsbelastning. SLH-DSA-stöd finns i större kryptografiska bibliotek men ser betydligt mindre produktionsdistribution, vilket återspeglar dess smalare, mer specialiserade roll. HSM-firmware-stöd för ML-KEM och ML-DSA är tillgängligt på nuvarande generationens hårdvara från större leverantörer, medan äldre HSM-moduler vanligtvis kräver en firmwareuppdatering eller hårdvaruuppdatering innan de kan utföra PQC-operationer.

Migrationsberoende och sekvensering

Ingen av dessa algoritmer används isolerat, och sekvenseringen är viktigare än algoritmvalet.

1. Certifikatutfärdarens hierarkier måste migrera roten först. Att utfärda ett lövcertifikat på ML-DSA innan den utfärdande certifikatutfärdaren och offline-roten har migrerats bryter den förtroendekedja som migreringen var avsedd att upprätta.
2. HSM-beredskapsgrindar signeringsdataflöde. ML-DSA och SLH-DSA ökar båda beräknings- och lagringsbelastningen per signeringsoperation, och äldre HSM-partitioner behöver validering av firmware innan de kan litas på att hålla jämna steg i produktionen.
3. Hybridkonstruktioner köper tid men lägger till en andra migrering senare. Sammansatta eller dubbelstackdesigner som parar ihop en klassisk algoritm med ML-KEM eller ML-DSA skyddar mot omogna PQC-implementeringar idag, men de måste fortfarande göra sig av med den klassiska komponenten före NIST:s föreslagna förbudsdatum 2035 för kvantsårbara algoritmer med offentlig nyckel.
4. Upptäckten måste komma först. En noggrann inventering av var RSA, ECDSA och ECDH faktiskt används idag, mappad till ägare och kritiska punkter, är den indata som varje sekvenseringsbeslut är beroende av.

Vad vi egentligen skulle rekommendera

För de flesta företagsteam utanför National Security Systems är ML-KEM-768 för nyckelutbyte och ML-DSA-65 för signering rätt standardvärde: båda ligger på NIST:s säkerhetsnivå kategori 3, båda har stabilt biblioteks- och plattformsstöd år 2026, och båda håller certifikat- och handskakningsstorlekar närmare hanterbara än de högsta parameteruppsättningarna. Team som förväntar sig att sälja till NSS eller den försvarsindustriella basen bör designa för ML-KEM-1024 och ML-DSA-87 från början snarare än att eftermontera senare, eftersom CNSA 2.0 inte accepterar de civila standardvärdena. Reservera SLH-DSA för en smal uppsättning signeringsanvändningsfall med hög säkerhet där ett andra, oberoende säkerhetsantagande motiverar storleken och prestandakostnaden, inte som en generell standard. Oavsett vilken kombination ett team landar på är det svårare problemet sällan algoritmval. Det handlar om att veta var klassiska algoritmer faktiskt körs idag, vilket är anledningen till att kryptografisk upptäckt, inte standardval, vanligtvis är den första riktiga blockeraren som teamen stöter på.

Hur krypteringskonsulting kan hjälpa

Att välja rätt kombination av ML-KEM, ML-DSA och SLH-DSA är ett beslut som beror på en organisations specifika system, myndighetsskyldigheter och nuvarande kryptografiska fotavtryck, inte en universallösning. Våra PQC-rådgivningstjänster arbetar igenom just det beslutet tillsammans med dig: vi bedömer vilka parameteruppsättningar som passar varje systemkategori, sekvenserar den root-first CA-migreringsväg som beskrivs ovan och bygger en fasad färdplan som är anpassad till FIPS 203, 204 och 205 och, där så är tillämpligt, CNSA 2.0-kraven.

Det rådgivningsarbetet håller bara om det utgår från en korrekt bild av var klassiska algoritmer faktiskt körs idag. CBOM Secure bygger och underhåller kontinuerligt det lagret, och mappar varje RSA-, ECDSA- och ECDH-instans, tillsammans med biblioteken och HSM-partitionerna bakom dem, till systemägarna som kommer att behöva agera utifrån standardvalsbesluten i den här guiden. Det är den indata som varje migreringssekvenseringsbeslut ovan är beroende av, och anledningen till att algoritmval så ofta stannar utan det.

Det lagret matar två olika exekveringsvägar, eftersom ML-KEM och ML-DSA/SLH-DSA hanteras via olika infrastrukturer. HSM-as-a-Service överför ML-KEM-nyckeletableringsbeslutet till produktion, FIPS-validerad nyckelhantering för TLS, VPN och alla nyckelutbytesarbetsbelastningar. CodeSign Secure gör detsamma för ML-DSA- och SLH-DSA-signeringsbeslutet, med HSM-baserad signering för kod, firmware och långlivade artefakter. Där signeringsbeslutet specifikt gäller certifikatutfärdande utfärdar och hanterar CertSecure Manager ML-DSA- och hybridcertifikat över Microsoft AD CS och andra CA-plattformar från ett enda policyplan.

Vad detta innebär för företagsteam

FIPS 203, 204 och 205 besvarar tre olika tekniska frågor, inte en enda. ML-KEM säkrar nyckelutbyte, ML-DSA bär den generella signeringsbördan, och SLH-DSA används i reserv för de snäva fall där ett andra, oberoende säkerhetsantagande är värt sin storlek och hastighetskostnad. Standarderna i sig är fastställda; det som fortfarande varierar mellan organisationer är parameterval, implementeringsmognad på de specifika plattformar som används och den sekvensering som krävs för att migrera en PKI-hierarki på ett säkert sätt. Team som behandlar standardval som den svåra delen upptäcker ofta att den verkliga begränsningen är att veta var deras klassiska kryptografi finns från första början.

Vanliga frågor om partihandel med mat och dryck

Är FIPS 203, 204 och 205 slutgiltiga standarder eller utkast?

Alla tre är slutgiltiga. NIST:s handelsminister godkände dem den 13 augusti 2024, med verkan från och med den 14 augusti 2024. De är produktionsberättigade standarder, inte utkast, till skillnad från NIST IR 8547 eller utkastet till FIPS 206 (FN-DSA), som förblev i utkaststatus fram till mitten av 2026.

Behöver jag alla tre standarderna, eller kan jag bara välja en?

Nästan alla system behöver minst en KEM och en signaturalgoritm, så ML-KEM plus antingen ML-DSA eller SLH-DSA är det realistiska minimumet. SLH-DSA är vanligtvis additiv snarare än en ersättning för ML-DSA, och används selektivt där dess oberoende säkerhetsantagande är värt prestandakostnaden.

Varför har NIST två signaturstandarder istället för en?

Algoritmdiversitet är en avsiktlig säkring. ML-DSA och SLH-DSA vilar på olika matematiska antaganden, gitterproblem kontra hashfunktionssäkerhet, så en framtida svaghet som upptäcks i gitterkryptografi skulle inte äventyra båda samtidigt. NIST upprätthåller SLH-DSA specifikt som den strukturellt oberoende reservlösningen.

Vilka parameteruppsättningar bör CNSA 2.0-reglerade organisationer använda?

ML-KEM-1024 för nyckeletablering och ML-DSA-87 för signaturer, båda i NIST kategori 5. CNSA 2.0 inkluderar inte SLH-DSA i sin algoritmsvit.

Betyder antagandet av dessa standarder att även AES måste förändras?

Nej. FIPS 203, 204 och 205 behandlar kryptografi med publik nyckel, där Shors algoritm ger en kvantdator en exponentiell fördel. AES-256 är en symmetrisk algoritm och anses redan vara kvantresistent vid den nyckelstorleken, med hänsyn till Grovers algoritm.