Quantenkryptografie: Was Entwickler wirklich wissen müssen

Charles Bennett und Gilles Brassard erhielten den Turing Award für ihre grundlegende Arbeit zur Quanteninformationswissenschaft, konkret für das BB84-Protokoll zur Quantenschlüsselverteilung, das sie 1984 veröffentlichten. Von der Veröffentlichung bis zum Turing Award vergingen 40 Jahre. Das zeigt ganz gut, wie lange theoretische Arbeit im Quantencomputing braucht, bis sie für die breitere Informatik-Community relevant genug ist, um anerkannt zu werden.

Die Auszeichnung kommt zu einem interessanten Zeitpunkt. Quantencomputer, die RSA-Verschlüsselung knacken können, gibt es noch nicht, und vielleicht dauert es noch ein Jahrzehnt. Trotzdem ist die Kryptografie-Community bereits mitten in der Migration. Das NIST hat seine ersten Post-Quanten-Kryptografie-Standards finalisiert, große Browser testen Post-Quanten-Schlüsselaustausch, und Signal setzt ihn bereits produktiv ein. Die Lücke zwischen „Quantencomputer werden Verschlüsselung irgendwann brechen“ und „wir müssen unsere Systeme jetzt umstellen“ hat sich geschlossen.

Was Quantencomputer tatsächlich bedrohen

Die populäre Berichterstattung über Quantencomputing und Kryptografie ist meist entweder alarmistisch („Jede Verschlüsselung ist gebrochen!“) oder abwertend skeptisch („Das wird nie funktionieren“). Die Realität ist konkreter und interessanter.

Quantencomputer bedrohen asymmetrische Kryptografie, also Verfahren, die auf der mathematischen Schwierigkeit beruhen, große Zahlen zu faktorisieren (RSA), oder diskrete Logarithmen zu berechnen (Diffie-Hellman, ECC). Shors Algorithmus kann diese Probleme auf einem ausreichend großen Quantencomputer in polynomieller Zeit lösen. Das heißt: RSA-2048, dessen Knacken klassische Computer Milliarden Jahre kosten würde, könnte ein Quantencomputer theoretisch in wenigen Stunden brechen.

Für symmetrische Kryptografie sind Quantencomputer deutlich weniger bedrohlich. Grovers Algorithmus bringt bei der Brute-Force-Suche einen quadratischen Geschwindigkeitsvorteil, der die effektive Schlüssellänge praktisch halbiert. AES-256 entspricht damit gegenüber einem Quanten-Angreifer AES-128, was für Brute-Force immer noch unpraktisch ist. AES-128 sinkt auf die Sicherheit von 64 Bit. Das ist besorgniserregend, aber nicht katastrophal.

What's threatened by quantum computers:
BROKEN (by Shor's algorithm):
├── RSA (all key sizes)
├── Diffie-Hellman key exchange
├── Elliptic Curve Cryptography (ECDSA, ECDH)
└── DSA
WEAKENED (by Grover's algorithm):
├── AES-128 → effectively 64-bit security (upgrade to AES-256)
├── AES-256 → effectively 128-bit security (still secure)
└── SHA-256 → effectively 128-bit preimage resistance (still secure)
NOT AFFECTED:
├── One-time pads
├── Hash-based signatures (SPHINCS+)
└── Symmetric encryption with sufficiently large keys

Praktisch heißt das: Alles, was Public-Key-Kryptografie nutzt, also TLS-Handshakes, SSH-Verbindungen, Code-Signierung, Kryptowährungen und digitale Signaturen, muss auf quantenresistente Algorithmen umgestellt werden. Symmetrische Verschlüsselung braucht hauptsächlich größere Schlüssel.

Das Problem „Harvest Now, Decrypt Later“

Genau deshalb ist die Migration dringend, obwohl Quantencomputer noch nichts brechen können. Angreifer, vor allem Staaten, zeichnen verschlüsselten Datenverkehr heute mit ziemlicher Sicherheit auf, um ihn zu entschlüsseln, sobald Quantencomputer verfügbar sind.

Man denke an Daten, die 20 Jahre oder länger vertraulich bleiben müssen: diplomatische Kommunikation, Geheimdienstberichte, Geschäftsgeheimnisse, Patientenakten. Wenn diese Daten heute mit RSA oder ECDH verschlüsselt werden und in 15 Jahren ein leistungsfähiger Quantencomputer existiert, versagt die Verschlüsselung rückwirkend. Die Daten waren immer verwundbar, man wusste es nur noch nicht.

Das ist keine spekulative Bedrohungsanalyse. Die NSA-Richtlinien empfehlen ausdrücklich, für Verschlusssachen auf quantenresistente Algorithmen umzusteigen. In der Geheimdienstwelt geht man davon aus, dass staatliche Akteure bereits verschlüsselten Datenverkehr horten. Wenn Ihre Daten ein langes Geheimhaltungsbedürfnis haben, war der Zeitpunkt zum Umstieg gestern.

Post-Quanten-Kryptografie: Was das NIST ausgewählt hat

Das NIST führte einen mehrjährigen Wettbewerb zur Standardisierung post-quantenkryptografischer Algorithmen durch, ähnlich wie seinerzeit die Auswahl von AES. Nach der Bewertung Dutzender Kandidaten legte es drei primäre Algorithmen als Standard fest:

• ML-KEM (Kyber) – Ein Key-Encapsulation-Mechanismus für den Schlüsselaustausch. Er basiert auf dem Module-Learning-With-Errors-Problem (MLWE) aus der Gitterkryptografie und ersetzt Diffie-Hellman und ECDH in TLS-Handshakes und ähnlichen Protokollen. Er ist schnell, erzeugt vergleichsweise kleine Schlüssel und ist die primäre Empfehlung für allgemeinen Schlüsselaustausch.
• ML-DSA (Dilithium) – Ein Signaturverfahren, ebenfalls auf Gitterkryptografie basierend. Es ersetzt RSA und ECDSA bei der Signierung. Signaturen sind größer als bei ECDSA (etwa 2,5 KB statt 64 Byte), was Auswirkungen auf Zertifikatsketten und Protokolle hat, die viele Signaturen übertragen.
• SLH-DSA (SPHINCS+) – Ein hashbasiertes Signaturschema. Seine Sicherheit beruht auf Hashfunktionen statt auf Gitterproblemen. Es ist langsamer und erzeugt größere Signaturen als ML-DSA, stützt sich aber auf gut verstandene Annahmen zu Hashfunktionen statt auf neuere Gitter-Annahmen. Es ist der konservative Rückfallpunkt.

Die gitterbasierten Algorithmen (ML-KEM, ML-DSA) werden aus Performancegründen bevorzugt, beruhen aber auf mathematischen Problemen, die im Vergleich zu den Jahrzehnten an Analysen hinter RSA und AES relativ neu sind. Es besteht eine kleine, aber nicht null liegende Chance, dass ein Durchbruch in der Gitter-Kryptoanalyse sie schwächen könnte. SPHINCS+ dient als Versicherung, denn seine Sicherheit beruht auf Hashfunktionen, die wir seit über 30 Jahren untersuchen.

Was bereits im Einsatz ist

Post-Quanten-Kryptografie ist nicht mehr theoretisch. Sie steckt bereits in Produktivsystemen, die Sie heute nutzen.

• Chrome und Firefox verwenden für TLS-Verbindungen einen hybriden Schlüsselaustausch (X25519 + ML-KEM-768). Das „hybrid“ bedeutet, dass ein klassischer mit einem post-quantenfesten Schlüsselaustausch kombiniert wird. Selbst wenn einer davon gebrochen wird, bleibt die Verbindung sicher. Das vergrößert den TLS-Handshake um etwa 1 KB.
• Signal hat PQXDH eingeführt, ein post-quantenfestes Protokoll für den initialen Schlüsselaustausch. Jede neue Signal-Unterhaltung bietet inzwischen Post-Quanten-Forward-Secrecy.
• Apple iMessage hat PQ3 eingeführt, das post-quantenfesten Schlüsselaustausch mit regelmäßiger Neuverschlüsselung nutzt. Apple behauptet, dies biete „Level 3“-Sicherheit, die höchste Stufe in ihrem Modell.
• Cloudflare unterstützt post-quantenfesten Schlüsselaustausch auf seinem CDN. Wenn Sie hinter Cloudflare sitzen, nutzen Ihre Verbindungen unter Umständen bereits ML-KEM, ohne dass Sie es wissen.
• AWS KMS unterstützt hybrides post-quantenfestes TLS für Schlüsselverwaltungsoperationen.

Die Migrationsherausforderung für Entwickler

Wenn Sie Software entwickeln, die Kryptografie verwendet (und das ist praktisch jede Software), sieht die Migration in der Praxis so aus.

TLS: Größtenteils erledigt für Sie

Wenn Ihre Anwendung TLS über eine Standardbibliothek nutzt (OpenSSL, BoringSSL, das crypto/tls-Paket von Go), wird die Post-Quanten-Unterstützung auf Bibliotheksebene ergänzt. Sie erhalten sie über Dependency-Updates. Ihre wichtigste Aufgabe ist sicherzustellen, dass Sie nicht auf alte TLS-Bibliotheksversionen festgelegt sind und dass Ihre Systeme die etwas größeren Handshake-Größen verarbeiten können.

Die Größenzunahme ist wichtiger, als man denkt. ML-KEM-768 vergrößert die TLS-ClientHello-Nachricht um etwa 1.100 Byte. Manche Middleboxes, Firewalls und schlecht implementierte TLS-Stacks verarbeiten ClientHello-Nachrichten, die größer als ~512 Byte sind, nicht. Googles Erfahrung beim Ausrollen von post-quantenfestem Schlüsselaustausch zeigte, dass etwa 0,5 % der Verbindungen wegen Middlebox-Inkompatibilität fehlschlugen. Wenn Ihre Nutzer hinter Unternehmensfirewalls sitzen, sollten Sie das testen.

Digitale Signaturen: Disruptiver

Post-Quanten-Signaturen sind deutlich größer als klassische. Eine ECDSA-Signatur hat 64 Byte. Eine ML-DSA-65-Signatur hat etwa 3.300 Byte. Eine SLH-DSA-Signatur kann über 17.000 Byte groß sein. Das hat weitreichende Folgen:

• X.509-Zertifikatsketten werden deutlich größer. Eine typische Kette aus drei Zertifikaten mit ML-DSA-Signaturen ist grob 10 KB größer als mit ECDSA. Bei bandbreitenbeschränkten Verbindungen fällt das ins Gewicht.
• Blockchain- und Kryptowährungssysteme, die auf kompakte Signaturen setzen, stehen vor Skalierungsproblemen. Jede Transaktion mit einer Post-Quanten-Signatur benötigt 50-mal mehr Speicherplatz.
• Code-Signierung, Paket-Signierung und Verifikation von Software-Updates müssen größere Signaturen verarbeiten, ohne die Größenannahmen bestehender Tools zu brechen.
• Certificate-Transparency-Logs, OCSP-Antworten und CRL-Verteilung wachsen alle in der Größe.

Kryptografie auf Anwendungsebene: Ihr Problem

Wenn Ihre Anwendung eigene kryptografische Protokolle implementiert (Ende-zu-Ende-Verschlüsselung, eigener Schlüsselaustausch, signierte Tokens, verschlüsselter Speicher), müssen Sie die Migration aktiv planen. Die allgemeine Strategie:

1. Inventarisieren Sie Ihre kryptografischen Abhängigkeiten. Finden Sie jede Stelle, an der Ihr Code RSA, ECDSA, ECDH oder Diffie-Hellman verwendet. Dazu gehören Bibliotheken, Schlüsselverwaltungssysteme, Zertifizierungsstellen und Hardware-Security-Module.
2. Setzen Sie zuerst auf hybride Verfahren. Kombinieren Sie klassische und post-quantenfeste Algorithmen. Stellt sich heraus, dass der Post-Quanten-Algorithmus eine Schwachstelle hat, fallen Sie auf klassische Sicherheit zurück. Kommen Quantencomputer, haben Sie Post-Quanten-Schutz.
3. Verwenden Sie etablierte Bibliotheken. Implementieren Sie Post-Quanten-Algorithmen nicht selbst. Nutzen Sie liboqs (Open Quantum Safe), das sich in OpenSSL integriert und getestete Implementierungen von ML-KEM, ML-DSA und SPHINCS+ bereitstellt.
4. Testen Sie die Performance-Auswirkungen. Post-Quanten-Operationen sind im Allgemeinen schnell (die Schlüsselerzeugung bei ML-KEM ist mit ECDH vergleichbar), aber die Signaturprüfung ist langsamer, und Schlüssel- und Signaturgrößen wirken sich auf Bandbreite und Speicher aus.
5. Planen Sie Krypto-Agilität ein. Entwerfen Sie Protokolle so, dass sich die kryptografischen Algorithmen austauschen lassen, ohne das Protokoll zu brechen. Das lässt sich nur schwer nachrüsten. Deutlich einfacher ist es, dies von Anfang an einzubauen.

Und was ist mit Quantenschlüsselverteilung?

Bennett und Brassards BB84, die Arbeit, für die sie den Turing Award erhielten, ist Quantenschlüsselverteilung (QKD), ein grundlegend anderer Ansatz. Statt mathematische Probleme zu nutzen, die Quantencomputer nicht lösen können, nutzt QKD die physikalischen Eigenschaften der Quantenmechanik, um Verschlüsselungsschlüssel zu verteilen. Jeder Abhörversuch stört die Quantenzustände und wird dadurch erkennbar.

QKD ist theoretisch elegant und beruht auf physikalischen statt rechnerischen Annahmen, weshalb sich ihre Sicherheit beweisen lässt. In der Praxis hat sie aber ernsthafte Grenzen: Sie benötigt dedizierte Glasfaserverbindungen (sie läuft nicht über das Internet), die maximale Distanz liegt ohne Quantenrepeater, die es noch nicht in großem Maßstab gibt, bei wenigen hundert Kilometern, und sie ist enorm teuer. China hat ein QKD-Netz zwischen Peking und Shanghai aufgebaut, das allerdings auf vertrauenswürdige Relaisknoten setzt, was den Zweck etwas untergräbt.

Auf absehbare Zeit ist Post-Quanten-Kryptografie (mathematische Algorithmen auf klassischen Computern) der praktische Weg. QKD ist für hochsichere Regierungs- und Militärverbindungen relevant, wird aber TLS für Ihre Webanwendung nicht ersetzen.

Zeitplan: Wann wird das wirklich relevant?

Niemand weiß, wann ein kryptografisch relevanter Quantencomputer (CRQC) existieren wird, also einer, der groß genug ist, um RSA-2048 zu brechen. Die Schätzungen reichen von 2030 bis „nie“, wobei sich die meisten Experten um 2035 bis 2040 gruppieren. Die derzeit größten Quantencomputer haben etwa 1.000 physische Qubits. Für das Brechen von RSA-2048 werden Millionen fehlerkorrigierter logischer Qubits benötigt.

Aber hier ist der Punkt: Der genaue Zeitpunkt spielt keine Rolle. Die Migration selbst dauert Jahre. Große Organisationen müssen ihre kryptografische Nutzung inventarisieren, Bibliotheken aktualisieren, Kompatibilität testen, Schlüssel und Zertifikate rotieren und Protokolle anpassen. Das NIST empfiehlt, die Umstellung bis 2035 abzuschließen. Da Migrationen in Unternehmenssoftware routinemäßig 5 bis 10 Jahre dauern, ist der Start jetzt wohl schon spät.

Der praktische Rat ist langweilig, aber richtig: Aktualisieren Sie Ihre TLS-Bibliotheken, planen Sie die Signatur-Migration, setzen Sie wo möglich auf hybride Verfahren und bauen Sie Krypto-Agilität in neue Systeme ein. Sie müssen nicht in Panik geraten, aber Sie sollten anfangen. Am härtesten trifft es die Organisationen, die die Post-Quanten-Migration als Zukunftsproblem behandeln, bis daraus ein Notfall wird.