Post-Quantum-Kryptografie für sichere Tunnels: Kampf gegen “Harvest Now, Decrypt Later”

Die Daten, die Sie heute verschlüsseln, werden für die zukünftige Entschlüsselung aufgezeichnet

Willkommen im Jahr 2026. Wenn Sie noch immer ausschließlich auf RSA-2048 oder Standard-Elliptic-Curve-Kryptografie (ECC) für Ihre Produktionstunnel setzen, sind Sie nicht nur im Rückstand—Sie hinterlassen effektiv eine Zeitkapsel Ihrer Unternehmensgeheimnisse für zukünftige Gegner.

Der “Quantum Y2K” (oder Q-Day) ist kein ferner akademischer Begriff mehr. Mit NISTs Veröffentlichung der ersten drei Post-Quantum-Kryptografie-Standards im August 2024 hat die Branche einen kritischen Wendepunkt erreicht. Die Bedrohung ist nicht mehr nur eine “Zukunftsattacke”—es geht um die Harvest Now, Decrypt Later (HNDL)-Kampagne, die derzeit von gut finanzierten staatlichen Akteuren ausgeführt wird.

Die HNDL-Krise: Warum “später” eigentlich “jetzt” ist

Die Strategie Harvest Now, Decrypt Later basiert darauf, verschlüsselte Daten heute zu sammeln und zu speichern, in der Hoffnung, dass Durchbrüche in der Quantencomputing-Technologie sie in Zukunft lesbar machen. Gegner intercepten und speichern heute große Mengen an verschlüsseltem Traffic. Sie können es noch nicht lesen, aber das ist nicht notwendig. Sie wetten darauf, dass bis Anfang der 2030er Jahre ein Cryptographically Relevant Quantum Computer (CRQC) mit Shors Algorithmus in der Lage sein wird, aktuelle Verschlüsselungen in Minuten zu knacken.

NIST hat erklärt, dass verschlüsselte Daten weiterhin gefährdet sind, weil Gegner sie jetzt sammeln, um sie später zu entschlüsseln, sobald die Quanten-Technologie ausgereift ist. Da sensible Daten oft über viele Jahre ihren Wert behalten, ist der Beginn der Umstellung auf Post-Quantum-Kryptografie jetzt entscheidend, um zukünftige Sicherheitsverletzungen zu verhindern.

Wenn Ihr Traffic von 2026 mit veralteten Protokollen gesichert ist, läuft seine “Haltbarkeitsdauer” ab, sobald der Quantencomputer eingeschaltet wird. Für geistiges Eigentum, medizinische Aufzeichnungen oder Regierungsgeheimnisse ist ein Schutzfenster von vier Jahren eine katastrophale Schwachstelle.

Wer ist gefährdet?

Organisationen, die langlebige sensible Daten speichern, sind Hauptziele: Regierungsbehörden, Verteidigungsauftragnehmer, Finanzinstitute, Gesundheitsdienstleister und Betreiber kritischer Infrastruktur. Auch zunehmend private Unternehmen mit wertvollem geistigem Eigentum oder Kundendaten sind attraktiv.

Betreiber kritischer Infrastruktur verwalten architektonische Diagramme, Konfigurationen der Betriebstechnologie und Kommunikationssysteme, die bei späterer Entschlüsselung Sabotage oder Störungen ermöglichen könnten.

Die Vulnerabilitätstabelle: Legacy vs. Quanten

Algorithmus	Typ	Klassische Sicherheit	Quanten-Sicherheit	Status im Jahr 2026
RSA-3072	Faktorisierung	Stark	Gebrochen (Shor)	Legacy / Riskant
ECDHE (P-256)	Diskreter Logarithmus	Stark	Gebrochen (Shor)	Legacy / Riskant
ML-KEM (Kyber)	Gitterbasiert	Stark	Stark	NIST-Standard
ML-DSA (Dilithium)	Gitterbasiert	Stark	Stark	NIST-Standard

Der neue Goldstandard: NISTs Post-Quantum-Standards

Im August 2024 veröffentlichte NIST seine wichtigsten PQC-Standards als Federal Information Processing Standards (FIPS), die Schlüsselaustausch- und digitale Signaturverfahren spezifizieren. Diese umfassen:

1. ML-KEM (ehemals CRYSTALS-Kyber) - FIPS 203

ML-KEM ist ein Key Encapsulation Mechanism (Schlüsselaustauschverfahren), das verwendet wird, um einen gemeinsamen geheimen Schlüssel zwischen zwei Parteien über einen öffentlichen Kanal zu etablieren, wobei die Sicherheit auf der Schwierigkeit des Module Learning with Errors (MLWE)-Problems beruht.

Die Mathematik: Es basiert auf dem “Module Learning with Errors” (MLWE)-Problem, einem Teilgebiet der Gitterkryptografie. Im Gegensatz zu RSA, das eine eindimensionale Faktorisierungsaufgabe ist, beinhalten Gitterprobleme die Suche nach dem kürzesten Vektor in einem mehrdimensionalen Gitter—eine Aufgabe, die auch für Quantencomputer “schwierig” bleibt.

FIPS 203 spezifiziert drei Parameter-Sätze für ML-KEM: ML-KEM-512, ML-KEM-768 und ML-KEM-1024, in aufsteigender Sicherheitsstärke und abnehmender Performance.

Anwendungsfall 2026: Wird im TLS 1.3 Handshake verwendet, um ECDHE zu ersetzen oder zu ergänzen.

2. ML-DSA (ehemals CRYSTALS-Dilithium) - FIPS 204

FIPS 204 spezifiziert den Module-Gitter-basierten Digital Signature Standard, der verwendet wird, um unautorisierte Änderungen an Daten zu erkennen und die Identität des Signierenden zu authentifizieren.

Die Mathematik: Ebenfalls gitterbasiert, speziell mit dem Module-Lattice-basierten Digital Signature Algorithm.

Anwendungsfall 2026: Wird bei Identitätsanbietern und Zertifizierungsstellen (CAs) eingesetzt, um die Zertifikate zu signieren, die Ihre Tunnel-Endpunkte authentifizieren.

3. SLH-DSA (ehemals SPHINCS+) - FIPS 205

Der stateless hash-basierte Digital Signature Standard bietet eine alternative digitale Signaturmethode, die eine andere mathematische Grundlage als Backup zu ML-DSA darstellt.

4. Weitere Algorithmen in Entwicklung

Am 11. März 2025 veröffentlichte NIST Hamming Quasi-Cyclic (HQC) als fünften Algorithmus für post-quanten asymmetrische Verschlüsselung, der als Backup für ML-KEM dient und eine andere Mathematik nutzt, um mögliche Schwächen in Gitteransätzen zu mildern.

NIST plant, den FALCON-Standard als FIPS 206 zu veröffentlichen (benannt als FN-DSA), eine alternative gitterbasierte Signatur, die noch kleinere Signaturgrößen bietet.

Der Hybrid-Ansatz: Die “Sicherheitsumhüllung”

Eine der häufigsten Fragen im Jahr 2026 lautet: “Wenn PQC so gut ist, warum verwenden wir dann noch ECC?”

Die Antwort ist Crypto-Agilität. Während gitterbasierte Mathematik theoretisch gegen Quantenangriffe robust ist, ist sie in der Praxis noch relativ neu und wurde weniger “battle-tested” als RSA oder ECC. Es besteht immer eine geringe Chance, dass ein findiger klassischer Mathematiker einen Fehler entdeckt.

Um dies zu mildern, hat die Branche hybride Kryptografie als Brücke eingeführt, die klassische und post-quantum Algorithmen kombiniert, um Risiken zu minimieren und Interoperabilität zu bewahren.

Wie funktioniert ein hybrider PQC-Tunnel

Anstatt X25519 (ECC) durch Kyber-768 (PQC) zu ersetzen, verwenden wir beide:

Duale Schlüsselaustausch: Der Tunnelinitiator sendet zwei öffentliche Schlüssel: einen klassischen (X25519) und einen post-quantum (ML-KEM-768).
Gemeinsame Schlüsselerzeugung: Der Empfänger antwortet mit zwei “Chiffretexten”. Beide Parteien verwenden dann eine Key Derivation Function (KDF), um den klassischen gemeinsamen Schlüssel und den PQC-Schlüssel zu “mischen” und einen einzigen Master-Key zu erstellen.
Das Ergebnis: Um den Tunnel zu knacken, muss ein Angreifer sowohl die klassische Mathematik als auch die quantenresistente Mathematik brechen. Das stellt sicher, dass der Traffic von 2026 vor heutigen Hackern und zukünftigen Quantencomputern geschützt ist.

Praxisbeispiele: Branchenführer

Cloudflare’s Einsatz

Cloudflare implementierte 2022 eine Vorabversion des ML-KEM-Schlüsselaustausch-Algorithmus. Bis Mitte August 2024 sind bereits über 16 % der menschlich generierten Anfragen an Cloudflares Server mit post-quantum Schlüsselvereinbarungen im Hybridansatz mit X25519 geschützt.

IBM’s Beitrag

Zwei von IBM entwickelte Algorithmen, ML-KEM (ursprünglich CRYSTALS-Kyber) und ML-DSA (ursprünglich CRYSTALS-Dilithium), wurden von IBM-Forschern in Zusammenarbeit mit Industrie- und Akademiepartnern entwickelt und gehören zu den ersten drei veröffentlichten Post-Quantum-Kryptografie-Standards.

Microsoft’s Integration

Microsoft kündigte an, dass mit den NIST-Standards die PQC-Algorithmen in Windows- und Azure-Kryptobibliotheken integriert werden, wobei die Kern-API (SymCrypt) Kyber (ML-KEM), Dilithium (ML-DSA) und Sphincs+ (SLH-DSA) unterstützt.

PQC in OpenSSH: Vorreiterrolle

OpenSSH ist Vorreiter bei der Post-Quantum-Implementierung:

Seit Version 9.0 im April 2022 bietet OpenSSH standardmäßig eine post-quantum Schlüsselaustauschmethode an, initial via dem Algorithmus sntrup761x25519-sha512.

In OpenSSH 9.9 wurde eine zweite post-quantum Schlüsselaustauschmethode mlkem768x25519-sha256 hinzugefügt, die in OpenSSH 10.0 im April 2025 zum Standard wurde.

OpenSSH 10.1 warnt Nutzer, wenn eine nicht-post-quantum Schemen gewählt wird, diese Warnung kann jedoch via WarnWeakCrypto-Option deaktiviert werden.

Aktuelle Verbreitungsstatistiken

Zwischen Oktober 2024 und März 2025 stieg die Nutzung von ML-KEM für SSH-Schlüsselaustausch um 554 %, während die Nutzung von SNTRUP um 21 % zunahm.

Dennoch laufen noch drei Viertel der OpenSSH-Versionen im Internet, die zwischen 2015 und 2022 veröffentlicht wurden und keine quantensichere Verschlüsselung unterstützen. Weniger als 20 % der TLS-Server verwenden TLSv1.3, die einzige Version, die PQC unterstützt.

PQC vs. TLS 1.3 Tunnels: Der Deep-Dive

Der Übergang zu PQC bei Tunneln erfolgt hauptsächlich auf der TLS 1.3 Ebene. Standard-Tunneling-Agenten (wie jene für localhost-Exposition oder Site-to-Site-VPNs) tauschen ihre Transport-Sicherheit aus.

Wesentliche Unterschiede bei PQC-Tunneln

1. Payload-Größe: PQC-Schlüssel sind deutlich größer als ECC-Schlüssel. Ein X25519-öffentlicher Schlüssel ist 32 Bytes; ein Kyber-768-öffentlicher Schlüssel ist 1.184 Bytes. Dieses “Bloating” kann IP-Fragmentierung verursachen, wenn es nicht vom Tunneling-Agent richtig gehandhabt wird.

2. Verarbeitungsaufwand: Obwohl PQC im Allgemeinen schnell ist, erfordert der initiale Handshake mehr CPU-Zyklen. Für hochfrequente “kurzlebige” Tunnel kann dies eine leichte Latenz hinzufügen.

3. Localhost-Tunnels: Entwickler, die Tunnels nutzen, um localhost (z.B. via Cloudflare Tunnel oder Tailscale) freizugeben, sehen jetzt “PQC-Enabled”-Flags in ihrer CLI. Das stellt sicher, dass auch der “temporäre” Entwicklungstraffic—der oft sensible API-Schlüssel oder .env-Daten enthält—vor Auslesen geschützt ist.

Leistungsvergleich: PQC vs. Legacy (2026 Benchmarks)

Protokoll-Metrik	ECC (X25519)	Hybrid (X25519 + Kyber768)	PQC Only (Kyber768)
Handshake-Latenz	~0.5ms	~0.8ms	~0.6ms
Öffentlicher Schlüssel	32 B	~1.2 KB	1.18 KB
Quantenresistenz	Nein	Ja	Ja
Klassisches Vertrauen	100 %	100 %	95 % (neuer)

Hinweis: Die Performance-Einbuße bei hybriden Tunneln ist für die meisten Anwendungen vernachlässigbar. Im Jahr 2026 überwiegt das Risiko, PQC nicht zu verwenden, die Latency-Mehrkosten von 0,3 ms.

Umsetzung von PQC-Tunneln: Eine Checkliste für 2026

Wenn Sie Infrastruktur verwalten, sollte Ihre “Quantum Readiness”-Roadmap die Tunneling-Agents priorisieren. Diese sind die “Rohre”, durch die Ihre sensibelsten Daten fließen.

1. Überprüfen Sie Ihre Tunneling-Agents

Prüfen Sie, ob Ihre Anbieter (Zscaler, Cloudflare, Twingate oder OpenSSH) hybride PQC-Schlüsselaustausch unterstützen. Stand 2026 sind die branchenüblichen hybriden Gruppen:

Für OpenSSH: - mlkem768x25519-sha256 (ML-KEM-768 + X25519) - Standard in OpenSSH 10.0+ - sntrup761x25519-sha512 (NTRU Prime + X25519) - Verfügbar seit OpenSSH 9.0

Um Ihre OpenSSH-Konfiguration zu prüfen:

ssh -Q kex

Um den PQC-Schlüsselaustausch zu erzwingen:

ssh -o KexAlgorithms=mlkem768x25519-sha256 user@host

Für TLS 1.3: Stellen Sie sicher, dass Ihre serverseitige Bibliothek (OpenSSL 3.5+, BoringSSL) die PQC-Gruppen in der Präferenzliste aktiviert hat. OpenSSL 3.5, veröffentlicht im April 2025, unterstützt die drei NIST-Standards ML-KEM, ML-DSA und SLH-DSA vollständig.

2. Aktualisieren Sie Ihre “Localhost”-Workflows

Lassen Sie Ihre Entwicklungsumgebung nicht die Schwachstelle sein. Beim Einsatz eines Tunneling-Agents für lokale Entwicklung:

Nutzen Sie Agents, die Post-Quantum Key Exchange (PQ-KEX) unterstützen
Überprüfen Sie den Handshake im Sicherheits-Tab Ihres Browsers (nach “X25519 + Kyber768” suchen)
Aktivieren Sie PQC-Flags in Ihren Entwicklungs-Tunnel-CLI-Tools

3. Wechseln Sie zu ML-DSA für internes PKI

Während öffentliche CAs noch im Übergang sind, sollte Ihr internes Root CA (für mTLS zwischen Diensten) beginnen, hybride Zertifikate mit ML-DSA auszustellen. Das verhindert, dass ein Angreifer eine Dienst innerhalb Ihres Netzwerks im Falle eines Quantencomputers imitiert.

4. Implementieren Sie Crypto-Agilität

Crypto-Agilität ist die Fähigkeit, kryptografische Algorithmen schnell auszutauschen, wenn Standards sich ändern. Das wird im Zeitalter der Quanten eine entscheidende Fähigkeit sein, da Organisationen, die Verschlüsselung tief in Legacy-Systeme eingebaut haben, Schwierigkeiten haben werden, sich anzupassen, wenn diese Algorithmen obsolet werden.

Regulatorischer und Compliance-Zeitplan

Laut NIST IR 8547 wird NIST bis 2035 veraltete, quantenanfällige Algorithmen aus seinen Standards entfernen, wobei Hochrisikosysteme viel früher migrieren sollen.

Angesichts der Herausforderung, auf Post-Quantum-Kryptografie umzustellen, haben Behörden weltweit mehrjährige Roadmaps veröffentlicht, die die Quantenbedrohung in den Vordergrund stellen und regulatorische Erwartungen an die Bereitschaft heute setzen. Es wird erwartet, dass Planung, Entdeckung und Inventarisierung innerhalb der nächsten zwei bis vier Jahre abgeschlossen sind.

Wichtige Fristen

2030: US-Bundesbehörden müssen auf PQC umstellen
2035: NIST stellt RSA, Diffie-Hellman und elliptische Kurven-Kryptografie (ECDH, ECDSA) gemäß CNSA 2.0 ein
2027: Erwartete Finalisierung des HQC-Standards als Backup für ML-KEM

Der Quantum-Zeitplan: Wann kommt Q-Day?

Laut dem Quantum Threat Timeline Report 2024 sind sich Experten einig, dass ein Quantencomputer in den nächsten 10 Jahren 100 logische Qubits erreichen könnte, und ein Drittel der Cybersicherheitsexperten prognostiziert, dass Q-Day vor 2032 eintreten wird.

Schätzungen, wann ein kryptografisch relevanter Quantencomputer kommt, reichen von 5 bis 20 Jahren, wobei viele Beobachter mit einem Eintreffen in der Mitte der 2030er rechnen.

Das alarmierendste an HNDL-Angriffen ist, dass sie ohne sichtbare Anzeichen eines Eindringens stattfinden können, da das Ziel des Angreifers darin besteht, Daten still und heimlich für zukünftige Entschlüsselung zu sammeln. Das bedeutet, dass Verstöße bereits passiert sein könnten, aber unentdeckt bleiben.

Maßnahmenplan: 90-Tage-Plan für Quantum Readiness

Führungskräfte können in den nächsten 90 Tagen konkrete Maßnahmen ergreifen:

Woche 1-2: Kartieren Sie Ihre wichtigsten Daten

Identifizieren Sie Daten, die langfristig vertraulich bleiben müssen, und verstehen Sie, wo sie gespeichert sind, wie darauf zugegriffen wird und wer Zugriff hat.

Woche 3-4: Überprüfen Sie Netzwerkkonfigurationen

Prüfen Sie Ihre Tunneling-Infrastruktur, VPN-Endpunkte und TLS-Konfigurationen. Identifizieren Sie alle Systeme, die nur mit veralteter Verschlüsselung arbeiten.

Woche 5-8: Kryptografisches Inventar

Führen Sie eine Bestandsaufnahme der Kryptografie durch und bewerten Sie Risiken datenbasiert. Das entspricht den Vorgaben des US Department of Homeland Security, das eine Inventarisierung der sensibelsten Daten und kryptografischen Systeme fordert.

Die zentrale Frage: Welche Daten könnten bei Entschlüsselung in 10 Jahren erheblichen Schaden anrichten?

Woche 9-12: Beginnen Sie mit hybrider Migration

Implementieren Sie hybride PQC für Ihre sensibelsten Tunnel
Aktualisieren Sie OpenSSH auf Version 10.0 oder höher
Aktivieren Sie ML-KEM in TLS 1.3-Endpunkten
Testen Sie hybride Konfigurationen in Staging-Umgebungen
Dokumentieren Sie Ihren PQC-Migrationsfahrplan

Die Linux-Enterprise-Perspektive

Red Hat Enterprise Linux 10.0 unterstützt ML-KEM für den Schutz von TLS-Verbindungen, die mit OpenSSL, GnuTLS und NSS sowie SSH-Verbindungen mit OpenSSH hergestellt werden, gegen Harvest Now, Decrypt Later-Angriffe.

Um PQC systemweit auf RHEL 10.0 zu aktivieren:

# Installieren Sie erforderliche Pakete
dnf install crypto-policies-pq-preview crypto-policies-scripts

# Wechseln Sie zu TEST-PQ-Policy
update-crypto-policies --set DEFAULT:TEST-PQ

Das Urteil: Warten Sie nicht auf den “Quantum Y2K”

Der “Quantum Y2K” ist kein einzelnes Datum im Kalender; es ist ein schiebendes Fenster. Jeder Tag, an dem Sie noch immer veraltete Tunnel verwenden, ist ein weiterer Tag, an dem Daten in den “Harvest”-Archiven globaler Gegner landen.

Studien zeigen, dass Hoch-Retentionssektoren wie Satelliten- und Gesundheitsnetzwerke Expositionsfenster von Jahrzehnten haben, wenn PQC verzögert wird. Hybride und forward-secure Ansätze verkürzen dieses Risiko um mehr als zwei Drittel.

Durch die Integration von ML-KEM und ML-DSA via Hybrid-Ansatz folgen Sie nicht nur einer NIST-Vorgabe—Sie stellen sicher, dass Ihr geistiges Eigentum auch in den 2030er Jahren und darüber hinaus privat bleibt.

Zusammenfassung der Maßnahmen

Alle Legacy RSA/ECC-Tunnel identifizieren
Hybrid PQC (ML-KEM) in Ihre TLS 1.3-Stacks aktivieren
OpenSSH auf Version 10.0 oder höher aktualisieren
Vergewissern Sie sich, dass localhost-Tunneling-Agents NIST-anerkannte Algorithmen verwenden
Führen Sie eine kryptografische Inventarisierung aller sensiblen Daten und Systeme durch
Implementieren Sie Crypto-Agilität
Erstellen Sie einen PQC-Migrationsfahrplan, der den regulatorischen Anforderungen entspricht
Überwachen Sie die Fortschritte bei der Adoption und passen Sie bei Bedarf an

Weitere Ressourcen

NIST PQC Standards: https://csrc.nist.gov/projects/post-quantum-cryptography
NIST IR 8547: Übergang zu Post-Quantum-Kryptografie-Standards
OpenSSH PQC Guide: https://www.openssh.org/pq.html
Cloudflare PQC Blog: Branchenbeispiele und Leistungsdaten
IETF RFC 9794: Standards für hybriden Schlüsselaustausch in TLS

Die Quantenbedrohung ist kein Problem von morgen—sie ist eine strategische Notwendigkeit von heute. Organisationen, die jetzt handeln, schützen ihre Daten für Jahrzehnte. Wer zögert, riskiert, seine Geheimnisse zu verlieren, sobald Quantencomputing Realität wird.

Beginnen Sie noch heute mit Ihrer PQC-Umstellung. Ihr zukünftiges Ich wird es Ihnen danken.