Erläuterung der NIST PQC-Standards: FIPS 203, 204 und 205 für Enterprise-Teams

Kurz gesagt: Das NIST hat am 13. August 2024 drei Post-Quanten-Kryptographiestandards finalisiert: FIPS 203 (ML-KEM) für die Schlüsselerzeugung, FIPS 204 (ML-DSA) für allgemeine digitale Signaturen und FIPS 205 (SLH-DSA) als konservative, hashbasierte Signatur-Fallback-Lösung. Die meisten Unternehmensimplementierungen verwenden standardmäßig ML-KEM-768 und ML-DSA-65 für zivile Anwendungen oder ML-KEM-1024 und ML-DSA-87 für CNSA-2.0-Umgebungen und reservieren SLH-DSA für spezielle Anwendungsfälle, in denen die Vielfalt der Algorithmen wichtiger ist als die Leistung.

Drei am selben Tag veröffentlichte Standards bedeuten nicht, dass sie dasselbe Problem lösen. Unternehmen fragen sich immer wieder, welches FIPS-Dokument tatsächlich für ihren TLS-Stack, ihre Codesignatur-Pipeline oder ihre Zertifizierungsstelle relevant ist. Die ehrliche Antwort lautet: FIPS 203, 204 und 205 waren nie als Konkurrenz zueinander gedacht. Sie decken unterschiedliche Aufgaben ab, weisen unterschiedliche Leistungsprofile auf und befinden sich 2026 in unterschiedlichen Implementierungsstadien – sowohl in Bibliotheken als auch in HSMs und auf verschiedenen Plattformen.

Dieser Leitfaden erläutert die Spezifikationen der einzelnen Standards, vergleicht ML-KEM, ML-DSA und SLH-DSA direkt miteinander und ordnet jeden Standard dem Anwendungsfall, dem Leistungsprofil und den Migrationsabhängigkeiten zu, die für die Entscheidung ausschlaggebend sein sollten. Eine schnellere, entscheidungsorientierte Version dieses Vergleichs sowie Informationen zu den häufigsten Fehlern bei der Auswahl finden Sie in unserem Entscheidungsleitfaden „ML-KEM vs. ML-DSA vs. SLH-DSA“.

Wichtige Erkenntnisse

• Die Standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) wurden am 13. August 2024 vom NIST finalisiert und schlossen damit einen achtjährigen öffentlichen Evaluierungsprozess ab.
• ML-KEM dient der Schlüsselerzeugung; ML-DSA und SLH-DSA der Erstellung digitaler Signaturen. Sie sind nicht austauschbar, und die meisten Systeme benötigen sowohl einen KEM-Algorithmus als auch einen Signaturalgorithmus.
• ML-DSA ist der Standard für allgemeine Signaturen; SLH-DSA tauscht Leistung und Größe gegen eine konservative, hashbasierte Sicherheitsannahme, die unabhängig von Gittermathematik ist.
• Die Wahl des Parametersatzes hängt vom Einsatzziel ab: ML-KEM-768 und ML-DSA-65 für zivile Systeme, ML-KEM-1024 und ML-DSA-87, wo CNSA 2.0 Anwendung findet.
• Der Reifegrad der Implementierung variiert im Jahr 2026 je nach Algorithmus und Plattform stark, und diese Reifegradlücke, nicht die Präferenz für einen Algorithmus, sollte die Reihenfolge bestimmen.

Was FIPS 203, 204 und 205 tatsächlich standardisieren

Das Post-Quanten-Kryptographieprojekt des NIST begann 2016 mit einem offenen Aufruf zur Einreichung von Algorithmen und durchlief mehrere Runden öffentlicher Kryptoanalyse, bevor das NIST 2022 die Finalisten auswählte. Der Handelsminister genehmigte die daraus resultierenden Standards am 13. August 2024; sie traten am folgenden Tag in Kraft.

Standard	Algorithmus	Basierend auf	Funktion	Ersetzt
FIPS203	ML-KEM (Modulgitterbasierter Schlüsselkapselungsmechanismus)	KRISTALLE-Kyber	Schlüsseleinrichtung	RSA- und Diffie-Hellman-Schlüsselaustausch, ECDH
FIPS204	ML-DSA (Modul-Lattice-basierter digitaler Signaturalgorithmus)	KRISTALLE-Dilithium	digitale Signaturen	RSA- und ECDSA-Signaturen
FIPS205	SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)	SPHINCS +	digitale Signaturen	RSA- und ECDSA-Signaturen als konservative Ausweichlösung

ML-KEM ist ein Schlüsselkapselungsmechanismus, das postquantenmechanische Äquivalent zur Etablierung eines gemeinsamen Geheimnisses über einen unsicheren Kanal – die Aufgabe, die die klassischen Verfahren Diffie-Hellman und ECDH heute erfüllen. ML-DSA und SLH-DSA sind digitale Signaturalgorithmen, die beweisen, dass eine Nachricht, ein Zertifikat oder ein Softwareartefakt von einem bestimmten privaten Schlüssel stammt und nicht verändert wurde – die Aufgabe, die RSA und ECDSA heute erfüllen. Ein vierter Standard, FN-DSA (FALCON), blieb bis Mitte 2026 als FIPS 206-Entwurf im Stadium des Entwurfs, und das NIST wählte 2025 HQC als strukturell unabhängigen Backup-KEM für ML-KEM aus.

ML-KEM vs. ML-DSA vs. SLH-DSA auf einen Blick

Die drei Algorithmen unterscheiden sich nicht nur in ihrer Funktion. Schlüssel- und Signaturgrößen, die zugrunde liegenden Sicherheitsannahmen und der Rechenaufwand bestimmen, wo jeder Algorithmus in einer realen Implementierung eingesetzt werden kann.

Eigenschaft	ML-KEM (FIPS 203)	ML-DSA (FIPS 204)	SLH-DSA (FIPS 205)
Sicherheitsgrundlage	Modul Lernen mit Fehlern (Gitter)	Modul Lernen mit Fehlern und Modul Kurze Ganzzahllösung (Gitter)	Sicherheit nur durch Hashfunktionen, keine Gitterannahme
Parametersätze	ML-KEM-512, 768, 1024	ML-DSA-44, 65, 87	Mehrere, z. B. SLH-DSA-128s/f, 192s/f, 256s/f
Standardeinstellung für Zivilisten	ML-KEM-768 (öffentlicher Schlüssel ~1,184 Bytes, Chiffretext ~1,088 Bytes)	ML-DSA-65 (öffentlicher Schlüssel ~1,952 Bytes, Signatur ~3,309 Bytes)	Keine Standardeinstellung; wird selektiv verwendet
CNSA 2.0-Parameter	ML-KEM-1024 (öffentlicher Schlüssel ~1,568 Bytes, Chiffretext ~1,568 Bytes)	ML-DSA-87 (öffentlicher Schlüssel ~2,592 Bytes, Signatur ~4,627 Bytes)	Nicht in der CNSA 2.0-Suite enthalten
Signatur-/Chiffretextgröße vs. klassische	Etwa 15 bis 25 Mal größer als ECDH	Etwa 15 bis 50 Mal größer als ECDSA	Etwa 100 bis 700 Mal größer als ECDSA (7,856 bis 49,856 Bytes)
Relativgeschwindigkeit	Schnell; vergleichbar mit oder schneller als klassische KEMs auf moderner Hardware	Schnell; geeignet für hohes Signieraufkommen	Langsam; das Signieren kann pro Vorgang Hunderte von Millisekunden dauern.
Optimale Bildschirmwahl	TLS, VPN und jeglicher Schlüsselaustausch	Allgemeine Signatur: Code, Dokumente, Zertifikate, Protokolle	Langlebige, kleinvolumige Signaturverfahren, bei denen die Vielfalt der Algorithmen am wichtigsten ist

Der Größenunterschied ist nicht nur akademisch, sondern auch operativ relevant. Eine auf ML-DSA-87 basierende Zertifikatskette mit vier Zertifikaten enthält etwa 15- bis 20-mal mehr Signaturdaten als dieselbe Kette auf ECDSA P-384. Dies äußert sich in größeren TLS-Handshakes, mehr OCSP-Antwortbytes und höheren Anforderungen an den HSM-Signaturdurchsatz. Die Signaturen von SLH-DSA sind sogar noch um ein bis zwei Größenordnungen größer, was den direkten Preis für eine Sicherheitsannahme darstellt, die nicht von der Gitterhärte abhängt.

Die Wahl des richtigen Standards je nach Anwendungsfall

Die meisten Systeme benötigen einen KEM und einen Signaturalgorithmus, die zusammenarbeiten, nicht nur eine einzige Auswahl zwischen den dreien.

• TLS- und VPN-Schlüsselaustausch: ML-KEM passt direkt. Hybridkonstruktionen wie X25519MLKEM768 kombinieren es mit einem klassischen Schlüsselaustausch während des Übergangsfensters.
• Codesignierung und Firmware-Signierung: ML-DSA ist der praktische Standard. Signierte Artefakte müssen oft über Jahre hinweg verifizierbar bleiben, und das Leistungsprofil von ML-DSA unterstützt das Signiervolumen, das die meisten Build-Pipelines benötigen.
• Hierarchien von Zertifizierungsstellen: ML-DSA ist die erste Wahl für ausstellende und Stammzertifizierungsstellen und folgt der gleichen Parameterlogik wie die Codesignierung.
• Hochsichere, seltene und langlebige Signaturen: SLH-DSA eignet sich für Organisationen, die ein zweites, strukturell unabhängiges Signaturverfahren als Absicherung gegen zukünftige Schwächen in der Gitterkryptographie wünschen und dafür die damit verbundenen Einbußen bei Größe und Geschwindigkeit in Kauf nehmen.
• Nationale Sicherheitssysteme und die verteidigungsindustrielle Basis: ML-KEM-1024 und ML-DSA-87 sind die erforderlichen Parametersätze gemäß CNSA 2.0; SLH-DSA ist nicht Teil dieser Suite.

Implementierungsreife im Jahr 2026

Standardstatus und Einsatzbereitschaft sind nicht dasselbe. Alle drei FIPS-Standards sind final, aber die Unterstützung für Bibliotheken, HSMs und Plattformen hat sich jeweils unterschiedlich schnell entwickelt.

ML-KEM bietet von den drei Protokollen die breiteste Browser- und TLS-Bibliotheksunterstützung. Der hybride Schlüsselaustausch ist in aktuellen Versionen gängiger Browser und TLS-Stacks bereits möglich. ML-DSA wird von etablierten PKI-Plattformen für Unternehmen unterstützt und ist seit dem Update vom Mai 2026 allgemein in den Microsoft Active Directory-Zertifikatdiensten von Windows Server 2025 verfügbar. Die Abdeckung variiert jedoch je nach Anwendungsfall: Codesignierung ist der zuverlässigste Weg, während umfassendere TLS-, VPN- und Remote-Desktop-Szenarien eine Validierung für jede einzelne Anwendung erfordern. SLH-DSA wird von wichtigen Kryptografiebibliotheken unterstützt, findet aber aufgrund seiner engeren, spezialisierteren Rolle deutlich weniger Anwendung in der Produktion. HSM-Firmware-Unterstützung für ML-KEM und ML-DSA ist auf aktueller Hardware führender Hersteller verfügbar. Ältere HSM-Module benötigen in der Regel ein Firmware-Update oder eine Hardware-Aktualisierung, bevor sie PQC-Operationen durchführen können.

Migrationsabhängigkeit und Sequenzierung

Keiner dieser Algorithmen kann isoliert eingesetzt werden, und die Reihenfolge ist wichtiger als die Wahl des Algorithmus.

1. Zertifizierungsstellenhierarchien müssen zuerst die Stammzertifizierungsstelle migrieren. Die Ausstellung eines Endbenutzerzertifikats auf ML-DSA, bevor die ausstellende Zertifizierungsstelle und die Offline-Stammzertifizierungsstelle migriert wurden, unterbricht die Vertrauenskette, die durch die Migration hergestellt werden sollte.
2. Die HSM-Bereitschaft begrenzt den Durchsatz bei der Signaturverarbeitung. ML-DSA und SLH-DSA erhöhen beide den Rechen- und Speicheraufwand pro Signaturvorgang, und ältere HSM-Partitionen müssen per Firmware validiert werden, bevor man sich darauf verlassen kann, dass sie im Produktivbetrieb mithalten können.
3. Hybridkonstruktionen verschaffen zwar Zeit, erfordern aber später eine zweite Migration. Zusammengesetzte oder Dual-Stack-Designs, die einen klassischen Algorithmus mit ML-KEM oder ML-DSA kombinieren, schützen zwar heute vor unausgereiften PQC-Implementierungen, müssen aber die klassische Komponente noch vor dem von NIST vorgeschlagenen Datum 2035, an dem quantenanfällige Public-Key-Algorithmen nicht mehr zulässig sein sollen, abschaffen.
4. Die Entdeckung muss an erster Stelle stehen. Eine genaue Bestandsaufnahme der tatsächlichen Verwendung von RSA, ECDSA und ECDH, zugeordnet zu Eigentümer und Kritikalität, ist die Grundlage jeder Sequenzierungsentscheidung.

Was wir tatsächlich empfehlen würden

Für die meisten Unternehmensteams außerhalb der nationalen Sicherheitssysteme (NSS) sind ML-KEM-768 für den Schlüsselaustausch und ML-DSA-65 für die Signierung die richtige Ausgangsbasis: Beide entsprechen der Sicherheitskategorie 3 des NIST, bieten 2026 solide Bibliotheks- und Plattformunterstützung und halten die Zertifikats- und Handshake-Größen im Vergleich zu den höchsten Parametersätzen deutlich handhabbarer. Teams, die an NSS oder die Verteidigungsindustrie verkaufen möchten, sollten von Anfang an auf ML-KEM-1024 und ML-DSA-87 setzen, anstatt nachträglich nachzurüsten, da CNSA 2.0 die zivilen Standardeinstellungen nicht akzeptiert. SLH-DSA sollte für wenige, besonders sichere Signierungsanwendungen reserviert werden, bei denen eine zweite, unabhängige Sicherheitsannahme den Aufwand für Größe und Leistung rechtfertigt – nicht als allgemeiner Standard. Unabhängig von der gewählten Kombination liegt die größte Herausforderung selten in der Algorithmusauswahl. Vielmehr ist es zu wissen, wo klassische Algorithmen heute tatsächlich eingesetzt werden. Daher ist die kryptografische Ermittlung, nicht die Standardauswahl, meist die erste Hürde für Teams.

Wie Verschlüsselungsberatung helfen kann

Die Wahl der richtigen Kombination aus ML-KEM, ML-DSA und SLH-DSA hängt von den spezifischen Systemen, regulatorischen Verpflichtungen und der aktuellen kryptografischen Infrastruktur Ihres Unternehmens ab und ist keine Standardlösung. Unsere PQC-Beratungsleistungen unterstützen Sie genau bei dieser Entscheidung: Wir ermitteln, welche Parametersätze zu welcher Systemkategorie passen, legen die Reihenfolge des oben beschriebenen Migrationspfads für die Root-CA fest und erstellen einen gestaffelten Fahrplan, der den Anforderungen von FIPS 203, 204 und 205 sowie gegebenenfalls den CNSA 2.0-Anforderungen entspricht.

Diese Beratungsarbeit ist nur dann zielführend, wenn sie auf einem präzisen Bild davon basiert, wo klassische Algorithmen heute tatsächlich eingesetzt werden. CBOM Secure erstellt und pflegt dieses Inventar kontinuierlich und ordnet jede RSA-, ECDSA- und ECDH-Instanz sowie die zugehörigen Bibliotheken und HSM-Partitionen den Systemverantwortlichen zu, die die in diesem Leitfaden beschriebenen Standardauswahlentscheidungen treffen müssen. Diese Daten bilden die Grundlage für jede der oben genannten Entscheidungen zur Migrationsreihenfolge und sind der Grund, warum die Algorithmenauswahl ohne sie so oft ins Stocken gerät.

Dieses Inventar speist zwei unterschiedliche Ausführungspfade, da ML-KEM und ML-DSA/SLH-DSA über verschiedene Infrastrukturen verwaltet werden. HSM-as-a-Service überträgt die Entscheidung zur ML-KEM-Schlüsselerzeugung in die Produktion und bietet FIPS-validiertes Schlüsselmanagement für TLS, VPN und jegliche Schlüsselaustausch-Workloads. CodeSign Secure leistet dasselbe für die ML-DSA- und SLH-DSA-Signaturentscheidung mit HSM-gestützter Signierung von Code, Firmware und langlebigen Artefakten. Wenn die Signaturentscheidung speziell für die Zertifikatsausstellung relevant ist, stellt CertSecure Manager ML-DSA- und Hybridzertifikate über Microsoft AD CS und andere CA-Plattformen hinweg mit einer einzigen Richtlinienebene aus und verwaltet diese.

Wohin führt dies für Unternehmensteams?

FIPS 203, 204 und 205 beantworten drei unterschiedliche technische Fragestellungen, nicht nur eine. ML-KEM sichert den Schlüsselaustausch, ML-DSA übernimmt die allgemeine Signaturlast, und SLH-DSA dient als Reserve für die wenigen Fälle, in denen eine zweite, unabhängige Sicherheitsannahme den damit verbundenen Aufwand an Größe und Geschwindigkeit rechtfertigt. Die Standards selbst sind festgelegt; was sich jedoch je nach Organisation noch unterscheidet, ist die Parameterauswahl, der Implementierungsgrad auf den jeweiligen Plattformen und die erforderliche Reihenfolge für die sichere Migration einer PKI-Hierarchie. Teams, die die Standardauswahl als schwierigsten Teil betrachten, stellen oft fest, dass die eigentliche Herausforderung darin besteht, überhaupt zu wissen, wo ihre klassische Kryptografie implementiert ist.

Häufig gestellte Fragen

Handelt es sich bei FIPS 203, 204 und 205 um endgültige Standards oder um Entwürfe?

Alle drei sind endgültig. Der Handelsminister hat sie am 13. August 2024 vom NIST genehmigt; sie traten am 14. August 2024 in Kraft. Im Gegensatz zu NIST IR 8547 oder dem Entwurf FIPS 206 (FN-DSA), der bis Mitte 2026 im Entwurfsstatus blieb, handelt es sich um produktionsreife Standards und nicht um Entwürfe.

Benötige ich alle drei Standards oder kann ich nur einen auswählen?

Nahezu jedes System benötigt mindestens einen KEM-Algorithmus und einen Signaturalgorithmus. Daher ist ML-KEM plus entweder ML-DSA oder SLH-DSA das realistische Minimum. SLH-DSA wird typischerweise zusätzlich zu ML-DSA eingesetzt und ersetzt dieses nicht. Es kommt nur dann zum Einsatz, wenn die unabhängige Sicherheitsannahme den Leistungsverlust rechtfertigt.

Warum hat das NIST zwei Signaturstandards anstatt nur einem?

Die Vielfalt der Algorithmen ist eine bewusste Absicherung. ML-DSA und SLH-DSA basieren auf unterschiedlichen mathematischen Annahmen – Gitterproblemen versus Hash-Funktionssicherheit –, sodass eine zukünftig entdeckte Schwachstelle in der Gitterkryptographie nicht beide gleichzeitig gefährden würde. Das NIST verwendet SLH-DSA ausdrücklich als strukturell unabhängige Alternative.

Welche Parametersätze sollten von den CNSA 2.0-regulierten Organisationen verwendet werden?

ML-KEM-1024 für die Schlüsselerzeugung und ML-DSA-87 für Signaturen, beide in der NIST-Kategorie 5. CNSA 2.0 enthält SLH-DSA nicht in seiner Algorithmensuite.

Bedeutet die Übernahme dieser Standards, dass sich auch AES ändern muss?

Die FIPS-Standards 203, 204 und 205 behandeln Public-Key-Kryptographie, wobei Shors Algorithmus einem Quantencomputer einen exponentiellen Vorteil verschafft. AES-256 ist ein symmetrischer Algorithmus und gilt bei dieser Schlüssellänge bereits als quantenresistent, was Grovers Algorithmus berücksichtigt.