Post-Quanten-Kryptografie: Was Entwickler jetzt tun müssen

Quantencomputer bedrohen Ihre Verschlüsselung noch nicht. Ein Quantencomputer, der in der Lage wäre, RSA-2048 zu brechen, würde Millionen fehlerkorrigierter logischer Qubits benötigen — wir haben Hunderte verrauschter physikalischer. Doch hier liegt das Problem: Angreifer sammeln möglicherweise genau jetzt verschlüsselte Daten mit der Absicht, sie später zu entschlüsseln, sobald Quantenhardware ausgereift ist. Und die Migration kryptografischer Infrastruktur dauert Jahre.

Deshalb sind die NIST-Standards für Post-Quanten-Kryptografie aus dem Jahr 2024 für Entwickler heute relevant, nicht erst 2035.

Die eigentliche Bedrohung: Shors Algorithmus

1994 bewies Peter Shor, dass ein Quantencomputer große ganze Zahlen in polynomieller Zeit O((log N)³) faktorisieren kann. Das bricht RSA, dessen Sicherheit darauf beruht, dass Faktorisierung schwierig ist. Derselbe Algorithmus — mit geringfügigen Änderungen — bricht die Elliptische-Kurven-Kryptografie (ECC), die ECDSA und ECDH zugrunde liegt.

Was gebrochen wird:

• RSA (Verschlüsselung, Signaturen)
• ECDSA (Signieren — verwendet in TLS, SSH, Code-Signing, Bitcoin)
• ECDH (Schlüsselaustausch — verwendet in TLS, Signal, WhatsApp, iMessage)
• Diffie-Hellman (Schlüsselaustausch)

Was nicht gebrochen wird:

• AES-256 (symmetrische Verschlüsselung) — Grovers Algorithmus bietet nur eine quadratische Beschleunigung und reduziert die effektive Schlüsselstärke von 256 auf 128 Bit. Das ist beherrschbar.
• SHA-256, SHA-3 (Hash-Funktionen) — dasselbe: Grover bietet eine geringfügige Beschleunigung, die Sicherheit halbiert sich, ist mit den aktuellen Schlüsselgrößen aber noch stark genug
• HMAC — sicher
• Argon2, bcrypt (Passwort-Hashing) — sicher

Das Fazit: Asymmetrische Kryptografie muss ersetzt werden; symmetrische Kryptografie benötigt eine Erhöhung der Schlüsselgröße (AES-128 → AES-256).

Harvest Now, Decrypt Later

Die Bedrohung lautet nicht „Quantencomputer werden nächstes Jahr die Verschlüsselung brechen". Die Bedrohung ist:

1. Ein Angreifer erfasst und speichert heute Ihren verschlüsselten TLS-Datenverkehr
2. In den Jahren 2032–2040 wendet er Shors Algorithmus darauf an
3. Er entschlüsselt alles rückwirkend

Dieser Angriff — genannt „harvest now, decrypt later" oder HNDL — findet bereits statt. Die NSA und andere Nachrichtendienste speichern mit ziemlicher Sicherheit große Mengen verschlüsselten Datenverkehrs. Der NSA-Hinweis von 2022 warnte ausdrücklich davor.

Daten, die heute vor HNDL geschützt werden müssen:

• Staatsgeheimnisse, klassifizierte Regierungsdaten
• Langlebige persönliche Daten (Krankenakten, Ausweisdokumente)
• Finanzdaten mit langen regulatorischen Aufbewahrungspflichten
• Geschäftsgeheimnisse und geistiges Eigentum
• Passwort-Datenbanken (obwohl bcrypt/Argon2 sicher sind)

Daten, um die man sich nicht sofort sorgen muss:

• Session-Tokens (kurzlebig, in 10 Jahren wertlos)
• Flüchtige Chat-Nachrichten (es sei denn, Sie sind ein hochwertiges Ziel)
• Öffentliche Informationen

Die Post-Quanten-Standards des NIST (2024)

Nach einem 8-jährigen Wettbewerb finalisierte das NIST im August 2024 drei Post-Quanten-Kryptografie-Algorithmen:

ML-KEM (CRYSTALS-Kyber) — Key Encapsulation

• Ersetzt: RSA-Schlüsselaustausch, ECDH
• Sicherheitsgrundlage: Module-Learning-With-Errors-Problem (MLWE) — gilt sowohl für klassische als auch für Quantencomputer als schwer
• Leistung: Schnell, kleine Schlüssel (~800 Bytes für KEM-768), schnelle Operationen
• Verwenden für: TLS-Schlüsselaustausch, verschlüsseltes Key-Wrapping, hybride Verschlüsselungsverfahren

# Python example using pqcrypto library
from pqcrypto.kem.kyber768 import generate_keypair, encapsulate, decapsulate

public_key, secret_key = generate_keypair()

# Sender encapsulates a shared secret
ciphertext, shared_secret_sender = encapsulate(public_key)

# Receiver decapsulates
shared_secret_receiver = decapsulate(secret_key, ciphertext)

assert shared_secret_sender == shared_secret_receiver
# Now use shared_secret as AES key

ML-DSA (CRYSTALS-Dilithium) — Digitale Signaturen

• Ersetzt: ECDSA, RSA-PSS zum Signieren
• Sicherheitsgrundlage: MLWE- + MSIS-Probleme
• Leistung: Moderate Schlüsselgrößen (~1.312 Bytes öffentlicher Schlüssel), schnelles Signieren
• Verwenden für: Code-Signing, TLS-Zertifikate, Dokumentensignierung, JWT-Signaturen

from pqcrypto.sign.dilithium3 import generate_keypair, sign, verify

public_key, secret_key = generate_keypair()

message = b"Deploy to production"
signature = sign(message, secret_key)

# Verify
assert verify(message, signature, public_key)

SLH-DSA (SPHINCS+) — Hash-basierte Signaturen

• Ersetzt: ECDSA als konservatives Backup
• Sicherheitsgrundlage: Ausschließlich Hash-Funktionen — die konservativste Wahl
• Leistung: Größere Signaturen (~8–50 KB), langsameres Signieren
• Verwenden für: Hochsicheres Signieren, bei dem Schlüsselwiederverwendung ein Problem darstellt, langfristige Dokumentensignierung

Das NIST standardisierte außerdem FALCON (FN-DSA) — ein Gitter-Signaturverfahren mit kompakten Signaturen, geeignet für ressourcenbeschränkte Umgebungen wie IoT.

Was jetzt zu tun ist: Ein gestufter Aktionsplan

Stufe 1 — Heute erledigen (Geringer Aufwand, hohe Wirkung)

Erstellen Sie eine Bestandsaufnahme Ihrer Kryptografie. Sie können nicht migrieren, was Sie nicht katalogisiert haben. Dokumentieren Sie:

• Wo verwendet Ihre Anwendung TLS? (Die meisten Frameworks erledigen das)
• Wo erzeugen oder prüfen Sie Signaturen? (JWTs, Code-Signing, PDF-Signierung)
• Wo verwenden Sie asymmetrischen Schlüsselaustausch? (RSA-umschlossene AES-Schlüssel, SSH)
• Welche Bibliotheken verwenden Sie? (OpenSSL, BouncyCastle, AWS KMS usw.)

Rüsten Sie AES-128 auf AES-256 auf. Dies ist risikoarm und sofort umsetzbar. AES-256 halbiert sich gegenüber Grover auf 128-Bit-Sicherheit — immer noch reichlich sicher.

Aktivieren Sie TLS 1.3 überall. TLS 1.3 verwendet standardmäßig Forward Secrecy (ECDHE), das heißt, vergangene Sitzungen können selbst dann nicht entschlüsselt werden, wenn der langfristige Schlüssel kompromittiert wird. Dies mildert HNDL für TLS-Datenverkehr teilweise ab.

Stufe 2 — Planung für die nächsten 6–18 Monate

Führen Sie hybriden Schlüsselaustausch in TLS ein. Die TLS-Arbeitsgruppe hat X25519Kyber768 standardisiert — ein Hybridverfahren, das sowohl klassisches ECDH als auch ML-KEM verwendet. Google Chrome, Cloudflare und AWS unterstützen es bereits. Es schützt vor HNDL und erhält gleichzeitig die klassische Sicherheit:

# Nginx with OpenSSL 3.x + oqs-provider (Open Quantum Safe)
ssl_ecdh_curve X25519Kyber768;  # hybrid classical + PQC

Ersetzen Sie RSA/ECDSA in neuen Systemen durch ML-DSA. Für alles auf der grünen Wiese — neue Microservices, neue JWT-Implementierungen, neue SSH-Bereitstellungen — verwenden Sie ML-DSA (Dilithium3 oder Dilithium5) statt ECDSA-256.

Aktualisieren Sie Ihre TLS-Zertifikats-Pipeline. Die meisten öffentlichen CAs stellen noch keine PQC-Zertifikate aus, aber Sie können ML-DSA heute schon für intern signierte Zertifikate und Service-Mesh-Zertifikate verwenden.

Stufe 3 — Langfristige Migration (1–5 Jahre)

Vollständige PKI-Migration. Ersetzen Sie Ihre RSA/ECC-Zertifikatshierarchie durch eine PQC-basierte CA-Infrastruktur. Dies ist der schwierigste Teil — Hardware-Sicherheitsmodule (HSMs), automatisierte Zertifikatsrotation und Zertifikatsketten müssen alle aktualisiert werden.

Hardware und eingebettete Geräte. IoT- und eingebettete Geräte können oft nicht aus der Ferne gepatcht werden und haben Lebensdauern von über 10 Jahren. Überprüfen Sie alle derartigen Geräte, die zur Authentifizierung auf RSA oder ECDSA angewiesen sind.

Schlüsselverwaltungssysteme. AWS KMS, Azure Key Vault, HashiCorp Vault — prüfen Sie deren PQC-Roadmaps und Migrationszeitpläne.

Bibliotheks- und Framework-Unterstützung

Zusammenfassung auf einer Seite

What breaks:    RSA, ECDSA, ECDH, classical DH
What's safe:    AES-256, SHA-256, SHA-3, bcrypt, Argon2
New standards:  ML-KEM (Kyber) for key exchange
                ML-DSA (Dilithium) for signatures
                SLH-DSA (SPHINCS+) for conservative signing

Do today:       Upgrade AES-128 → AES-256
                Enable TLS 1.3 (forward secrecy)
                Audit crypto inventory

Do soon:        Hybrid TLS key exchange (X25519Kyber768)
                ML-DSA for new signature systems

Do in 1-5 yrs:  Full PKI migration to PQC
                Firmware updates for IoT devices

Die Quantenbedrohung für die Kryptografie ist real und der Zeitrahmen ungewiss — genau deshalb ist es die richtige Entscheidung, jetzt zu handeln, bevor Quantencomputer dazu in der Lage sind.

Weiterführende Lektüre: Glossar zum Quantencomputing — Shors Algorithmus · Was Quantencomputer heute können