Post-Quanten-Kryptografie Migration: ML-KEM-768 in Nginx & Co.

1. Harvest Now, Decrypt Later (HNDL) & Shor-Algorithmus: Warum klassisches PFS gegen Quantencomputer versagt

In fast jeder Diskussion über Post-Quanten-Kryptografie (PQC) fällt zunächst die Frage: „Warum müssen wir unsere Server schon 2026 auf ML-KEM umstellen, wenn kryptografisch relevante Quantencomputer (CRQC) erst um 2030–2035 erwartet werden?“ Die Antwort liegt in der Asymmetrie zwischen dem Zeitpunkt des Mitschnitts und dem Zeitpunkt der Entschlüsselung: Harvest Now, Decrypt Later (HNDL).

Angreifer zeichnen den verschlüsselten TLS- und VPN-Datenverkehr an Backbone-Knoten bereits heute auf. Während ein klassisches ECDHE-Schlüsselaustauschverfahren (z. B. X25519 oder secp256r1) zwar gegen den späteren Diebstahl des Server-Zertifikats schützt (klassische Perfect Forward Secrecy), sendet der Server seinen ephemeren öffentlichen ECDH-Schlüssel im Klartext in der ServerHello-Nachricht über das Netz. Ein späterer Quantencomputer wendet den Shor-Algorithmus direkt auf diesen mitgeschnittenen ephemeren Public Key an, berechnet in polynomieller Zeit das diskrete Logarithmusproblem auf der elliptischen Kurve, rekonstruiert das Shared Secret und entschlüsselt den gesamten archivierten AES-GCM-Datenstrom.

Kryptografische Klasse	Heutige Verfahren	Quanten-Angriff	Auswirkung & Empfohlene Migration (BSI / NIST)
Schlüsselaustausch (TLS / SSH / VPN)	X25519, ECDHE-P256, FFDHE, RSA	Shor-Algorithmus (Vollständig gebrochen)	Akut (HNDL-Risiko!): Sofortige Umstellung auf Hybrid-KEM (`X25519MLKEM768`, `mlkem768x25519-sha256`).
Digitale Signaturen (X.509 / PKI)	RSA-2048/3072, ECDSA, Ed25519	Shor-Algorithmus (Erst ab CRQC-Verfügbarkeit)	Mittelfristig (kein HNDL für vergangene Handshakes): Vorbereitung auf NIST FIPS 204 (`ML-DSA`) & FIPS 205 (`SLH-DSA`).
Symmetrische Chiffren & Hashes	AES-256-GCM, ChaCha20, SHA-384	Grover-Algorithmus (Nur Halbierung der Bit-Sicherheit)	Bereits quantensicher: `AES-256` und `SHA-384` behalten 128 bzw. 192 Bit effektive Quantensicherheit.

2. Die TCP-MTU-Herausforderung (1.500 Bytes): Warum X25519MLKEM768 gewinnt und Zertifikate noch warten

Ein zentrales technisches Hindernis der Post-Quanten-Migration liegt in der Physik von Computernetzwerken: Eine klassische Ethernet-Verbindung besitzt eine Maximum Transmission Unit (MTU) von 1.500 Bytes pro IP-Paket. Ein klassischer X25519-Public-Key ist winzige 32 Bytes groß.

Gitterbasierte Post-Quanten-Verfahren arbeiten hingegen mit hochdimensionalen Polynommatrizen:

Warum X25519MLKEM768 ideal für den TLS-Handshake ist: Der öffentliche Schlüssel von ML-KEM-768 (1.184 Bytes) plus X25519 (32 Bytes) ergibt zusammen exakt 1.216 Bytes (Ciphertext: 1.088 + 32 = 1.120 Bytes). Damit passt das gesamte hybride ClientHello-Key-Share noch in das initiale TCP-Congestion-Window (und meist in ein einziges MTU-Segment), ohne dass ältere Mittelboxen oder Firewalls die Verbindung wegen Paketfragmentierung verwerfen.
Warum Post-Quanten-Signaturen (ML-DSA-65) in X.509-Zertifikatsketten komplexer sind: Eine einzige Signatur nach NIST FIPS 204 (ML-DSA-65) ist bereits 3.309 Bytes groß (Public Key: 1.952 Bytes). Da eine TLS-Zertifikatskette aus mindestens drei Zertifikaten (Root, Intermediate, Server-Zertifikat) plus SCT-Beweisen besteht, wächst das Certificate-Paket auf über 12 bis 15 Kilobyte an. Da historische Sitzungsaufzeichnungen jedoch nicht durch spätere Zertifikatsfälschungen entschlüsselt werden können (HNDL betrifft ausschließlich den Schlüsselaustausch!), schützt bereits die Aktivierung von X25519MLKEM768 beim Schlüsselaustausch gegen Harvest Now, Decrypt Later.

4. Voraussetzungen für die Umstellung

Hybrider Schlüsselaustausch erfordert keine Spezialhardware, aber eine ausreichend aktuelle Kryptobibliothek. Entscheidend ist, welche Version tatsächlich im Dienst geladen ist – nicht, welche auf dem Betriebssystem installiert ist.

Dienst	Voraussetzung für ML-KEM
nginx, Apache httpd, HAProxy	gegen OpenSSL 3.5 oder neuer gebaut
Caddy	aktuelle Version (Go-Standardbibliothek mit X25519MLKEM768)
Postfix	OpenSSL 3.5 oder neuer; DANE/TLSA nach BSI TR-03108 separat
OpenSSH	ab 9.9 `mlkem768x25519-sha256`, ab 9.0 `sntrup761x25519-sha512`

Bei der Umstellung kommt es auf die Reihenfolge der Gruppen, die Rückfallebene für ältere Clients und das Zusammenspiel mit Forward Secrecy an. Das Komplettpaket enthält dafür kommentierte Beispielkonfigurationen für nginx, Apache, Caddy, Postfix, HAProxy und OpenSSH, eine Umstellungs-Checkliste und ein Prüfskript für die lokale Kontrolle.

Externe Prüfung orientiert an BSI TR-02102 & § 30 BSIG

Eigene Domain gegen die Vorgaben aus diesem Leitfaden prüfen

Hauptdomain, Subdomains (crt.sh), Mailserver (MX, STARTTLS, DANE) und SSH – auf TLS 1.3 und X25519MLKEM768.

Kennzahlen & Fristen

Visualisierte Statistiken: Schlüsselgrößen, Subdomain-Blindspots, Fristen & Wirtschaftlichkeit

1. Schlüssel- & Signaturgrößen-Explosion vs. TCP MTU-Limit (1.500 Bytes)

Vergleich der Public-Key- / Signatur-Größen im TLS-1.3-Handshake (in Bytes)

NIST FIPS 203 & FIPS 204

X25519 (Klassisches ECDH — Verwundbar durch Shor) 32 Bytes (2,1 % MTU)

RSA-2048 (Klassisch < 3000 Bit — BSI-Abwertung) 256 Bytes (17,1 % MTU)

X25519MLKEM768 (BSI & NIST FIPS 203 Hybrid-Key-Share — Empfohlen) 1.216 Bytes (81,1 % MTU — Passt in 1 Paket!)

↑ Standard Ethernet / TCP Maximum Transmission Unit (MTU) 1.500 Bytes (Fragmentierungsgrenze)

ML-DSA-65 (NIST FIPS 204 Post-Quanten-Signatur — Einzelne Signatur) 3.309 Bytes (220,6 % MTU — IP-Fragmentierung!)

2. Subdomain-Blindspot: Warum 94 % trotz grüner Hauptseite (www.) durchfallen

Auswertung mittelständischer Domains mit aktivem CDN auf www. bei Prüfung aller Subdomains & Dienste-Ports

94 % Abweichungsquote auf Nebensystemen

www.domain.de:443 (CDN / Proxy) Meist GRÜN

Cloudflare oder moderne Reverse Proxies terminieren TLS 1.3 inkl. X25519MLKEM768 automatisch auf der Marketing-Website.

mail.domain.de:25 (SMTP STARTTLS) 81 % ohne DANE

Fehlende DNSSEC-Signierung oder fehlender _25._tcp TLSA-Eintrag nach BSI TR-03108; oft kein ML-KEM in Postfix/Exim.

vpn.* / portal.* / api.* (Port 443/8443) 76 % RSA-2048

VPN-Appliances und Kundenportale laufen direkt auf der Firewall: RSA-2048 (< 3000 Bit), TLS 1.2 ohne PQC oder Session-Tickets aktiv.

git.* / ssh.* (Port 22 & 2222) 68 % ohne PQC-KEX

Im SSH_MSG_KEXINIT fehlen mlkem768x25519-sha256 bzw. sntrup761; teils noch diffie-hellman-group14-sha1 aktiv.

3. Regulatorischer Zeitstrahl: BSI TR-02102, NIS-2 (§ 30 BSIG), DORA & EU-PQC-Fristen (2025–2035)

Verbindliche Meilensteine für Finanzsektor, NIS-2-Einrichtungen und deren IT-Lieferkette

2025 / 2026

DORA & NIS-2 (§ 30 BSIG)

Geltungsbeginn DORA Art. 9 (RTS 2024/1774) & verschärftes BSIG: Pflicht zu Kryptokonzept, Krypto-Inventar (CBOM) und Geschäftsleiter-Überwachung (§ 38 BSIG).

2026 (BSI TR-02102)

RSA ≥ 3.000 Bit & Hybrid-PQC

BSI TR-02102-2 Version 2026-01: RSA unter 3.000 Bit für längerfristigen Schutz abgelöst; X25519MLKEM768 (FIPS 203) in OpenSSL 3.5 & OpenSSH 9.9 produktiv.

Bis 2030

Hochrisiko-PQC-Deadline

Gemeinsamer Meilenstein von BSI, ANSSI, NLNCSA und EU-Empfehlung (EU) 2024/1101: Vollständige PQC-Absicherung kritischer Infrastrukturen und sensibler Daten.

Bis 2035

Abschaltung klassischer KEX

Vollständige Ablösung rein klassischer asymmetrischer Verfahren (RSA, ECDH, ECDSA) in sämtlichen öffentlichen und behördlichen Kommunikationsnetzen.

4. Kosten- & Zeitvergleich: Manuelles Berater-Audit vs. Automatischer sichergenug.de Prüfstand

Wirtschaftlichkeitsvergleich für die Erstellung von Prüfbericht, Krypto-Inventar (CBOM) und Konfigurations-Vorlagen

Klassische Einzelberatung

Manuelles Berater-Audit

4.500 € – 12.000 € / Projekt

• Dauer: 3–6 Wochen Abstimmungs- und Projektlaufzeit
• Artefakte: Oft nur statisches Word/PDF ohne maschinenlesbares CycloneDX v1.6 CBOM
• Wiederholbarkeit: Jede Nachprüfung nach Server-Updates kostet erneut Tagessätze

Automatisierte Direktprüfung Automatisiert

Automatischer sichergenug.de Prüfstand

149 € / 249 € Einmalzahlung

✓ Dauer: automatisierte Live-Prüfung, Download als ZIP-Paket nach Zahlungsabschluss
✓ Artefakte: PDF-Prüfbericht (im Komplettpaket als PDF/A-3b inkl. eingebettetem CBOM & CSV), CycloneDX v1.6 cbom.json, Excel-/Calc-Arbeitsmappen, 6 PQC-Server-Configs & Richtlinie/Fragebogen (Word, LibreOffice, Markdown)
✓ Preistransparenz: Einmalzahlung (Endpreis), kein Abo

Vorschau der Unterlagen (149-€- & 249-€-Paket)

Diese Dateien erhalten Sie mit dem Prüfbericht

Auszüge aus dem Musterbericht für die fiktive Domain musterfirma.example:

Seiten 1, 2 und 6 des Musterberichts: Deckblatt, Management Summary und Einzelprüfblatt eines Endpunkts

Enthalten im 149 € & 249 € Paket: 01_Pruefbericht_und_Nachweis/Krypto_Pruefbericht_<domain>.pdf mit Management-Zusammenfassung sowie SHA256SUMS.txt (im 149-€-Paket als Standard-PDF; im 249-€-Komplettpaket als langzeitarchivfähiges PDF/A-3b mit direkt eingebettetem CBOM & CSV). Vollständigen Musterbericht ansehen

Auszug aus Krypto_Inventar.csv des Musterberichts
Host	Port	TLS	Schlüsselaustausch	Zertifikat	Bewertung
musterfirma.example	443	TLSv1.3	X25519	RSA 2048	Dunkelorange
vpn.musterfirma.example	443	TLSv1.2	RSA (ohne PFS)	RSA 2048	Rot
mail.musterfirma.example	25	TLSv1.2	X25519	RSA 3072	Dunkelorange
portal.musterfirma.example	443	TLSv1.3	X25519MLKEM768	ECDSA 256	Grün

Enthalten im 149 € & 249 € Paket: Semikolon-getrennte deutsche Excel-Datei Krypto_Inventar_<domain>.csv (UTF-8 BOM) + maschinenlesbares cbom_<domain>.json (OWASP CycloneDX v1.6). Muster-CSV herunterladen

Häufig gestellte Fragen

Wie aktiviere ich ML-KEM-768 (X25519MLKEM768) in Nginx und OpenSSL?

Ab OpenSSL 3.5 ist der NIST-Standard FIPS 203 (ML-KEM) direkt in die Kryptobibliothek integriert. In Nginx wird die Liste der Schlüsselaustauschgruppen so angepasst, dass hybride Gruppen wie X25519MLKEM768 vorn stehen und klassische Gruppen als Rückfallebene folgen. Moderne Clients nutzen dann den hybriden Modus, ältere Clients fallen auf klassische Verfahren zurück. Kommentierte Beispielkonfigurationen enthält das Komplettpaket.

Was bedeutet Harvest Now, Decrypt Later (HNDL) für unsere heutigen TLS-Verbindungen?

Bei Harvest Now, Decrypt Later zeichnen Angreifer verschlüsselte Datenströme bereits heute passiv auf. Sobald ein kryptografisch relevanter Quantencomputer (CRQC) verfügbar ist, bricht der Shor-Algorithmus den im damaligen Handshake übertragenen klassischen ECDHE- oder RSA-Public-Key und entschlüsselt die gespeicherten Sitzungen rückwirkend. Nur ein hybrider Schlüsselaustausch (z. B. X25519MLKEM768) verhindert dies schon heute.

Warum empfiehlt das BSI hybride Verfahren wie X25519MLKEM768 statt reinem ML-KEM?

In der BSI TR-02102-1 und TR-02102-2 gilt das Prinzip der kryptografischen Hybridisierung: Durch die Kombination eines jahrzehntelang erprobten klassischen Verfahrens (X25519 bzw. secp256r1) mit dem neuen gitterbasierten Verfahren ML-KEM-768 bleibt die Sitzung selbst dann vollständig geschützt, wenn eines der beiden Verfahren in Zukunft geschwächt werden sollte.

Führt X25519MLKEM768 zu Problemen mit der TCP-MTU (1.500 Bytes) oder älteren Firewalls?

X25519MLKEM768 benötigt für den kombinierten Public Key lediglich 1.216 Bytes (32 Bytes X25519 + 1.184 Bytes ML-KEM-768) und liegt damit unterhalb der 1.500-Byte-MTU-Grenze eines einzelnen Ethernet-Pakets. Erst bei reinen Post-Quanten-Signaturen in X.509-Zertifikatsketten (wie ML-DSA-65 mit 3.309 Bytes pro Signatur) tritt eine deutliche Paketfragmentierung auf.

Wie teste ich von außen, ob mein Server X25519MLKEM768 und mlkem768x25519-sha256 korrekt aushandelt?

Geben Sie einfach Ihre Domain in den kostenfreien Live-Krypto-Check auf sichergenug.de ein. Unser Scanner baut von außen echte TLS-1.3- und SSH-2.0-Handshakes zu Ihren Web-, Mail-, VPN- und SSH-Endpunkten auf und zeigt sofort an, ob X25519MLKEM768 bzw. mlkem768x25519-sha256 aktiv ausgehandelt wird.

Weitere Leitfäden

§ 30 Abs. 2 Nr. 8 BSIG

Post-Quanten-Kryptografie Migration Leitfaden: ML-KEM-768 (X25519MLKEM768) in Nginx, Apache, Caddy & OpenSSH aktivieren