Filippo Valsorda hat letzte Woche dargelegt, dass AES-128 gegen Quantencomputer standhält. Derselbe Punkt war eine Fußnote in unserem Beitrag Die Spaltung bei Hybrid-Signaturen: Die Quantenbedrohung liegt auf Signaturen und Schlüsselaustausch, nicht auf der Blockchiffre.
Unsere Scandaten fügen eine Überraschung hinzu. Die Betreiber, die ihren AES-Schlüssel verdoppelt haben, sind nicht dieselben, die den Teil geändert haben, den Shor tatsächlich bricht. In einem rollierenden 30-Tage-Fenster von [PQ]probe-TLS-Scans:
| AES-Profil | Anteil der Hosts | PQC-Schlüsselaustausch | A-Note-Quote |
|---|---|---|---|
| Nur AES-128 | 44 % | 48 % | 43 % |
| Nur AES-256 | 32 % | 6 % | 6 % |
| Beide | 13 % | 0 % | 0 % |
| Keines (nur ChaCha20) | 12 % | 1 % | 1 % |
Nur-AES-128-Hosts handeln hybriden PQC-Schlüsselaustausch 8-mal so häufig aus wie Nur-AES-256-Hosts (48 % gegen 6 %). Hosts, die beide Chiffren akzeptieren, fallen auf 0 %. Die ChaCha20-Zeile liegt bei 1 %, nahe an Nur-AES-256. Die Methodik steht am Ende dieses Beitrags.
Der Grund liegt in der Konfiguration, nicht in der Kryptografie. OpenSSL und rustls beginnen ihre TLS-1.3-Standard-Suite-Liste mit TLS_AES_256_GCM_SHA384, also handelt ein Host, der die Voreinstellungen übernimmt, AES-256-GCM aus. Die Hosts, die AES-128-GCM aushandeln, sind meist diejenigen, die diese Vorgabe überschreiben. Cloudflare und die anderen großen Edge-Flotten sind die offensichtlichen Beispiele, und genau auf diesen Flotten wird X25519MLKEM768 seit 2024 ausgerollt. AES-128 in einem TLS-1.3-Handshake ist das Zeichen einer Edge-Konfiguration, die jemand pflegt.
TLS-1.2-Hosts kommen aus der anderen Richtung zu AES-256. In TLS 1.2 wählt der Server die Chiffre, und diese Hosts sind meist auf eine ECDHE-AES256-GCM-Suite festgelegt, durch eine Präferenzliste, die aus einem Härtungsleitfaden von vor der Quantendebatte stammt. Dieselbe Liste hat X25519, P-256 oder RSA als Schlüsselaustausch festgelegt. Die Chiffre wurde aktualisiert. Der Schlüsselaustausch nicht.
Standardisierungsgremien sind sich einig, dass AES-128 keine weitere Änderung braucht. BSI TR-02102-1 empfiehlt AES-128, AES-192 und AES-256 gleichberechtigt für neue Systeme, wie im BSI-Verfallsdatum-Beitrag behandelt. NIST IR 8547 ordnet jede NIST-zugelassene symmetrische Primitive mit mindestens 128 Bit klassischer Sicherheit der PQC-Kategorie 1 zu, und die NIST-PQC-FAQ ist deutlicher: Anwendungen können weiterhin AES-128, AES-192 oder AES-256 verwenden.
CNSA 2.0 verlangt zwar AES-256, aber zur einheitlichen Absicherung von National Security Systems auf Top-Secret-Stufe, nicht aus Gründen der Grover-Resistenz. Aus demselben Grund verlangt CNSA 2.0 ML-KEM-1024 und ML-DSA-87 statt der häufigeren ML-KEM-768 und ML-DSA-65. Außerhalb der NSS-Arbeit verlangt kein Compliance-Regime eine Abkehr von AES-128.
Was das für Audits und Beschaffung bedeutet
[PQ]probe bewertet den Schlüsselaustausch, nicht die Chiffre. Ein Host, der hybriden PQC-Schlüsselaustausch aushandelt, ist quantensicher, ob seine Chiffre AES-128-GCM oder AES-256-GCM ist. Ein Host auf einem klassischen Schlüsselaustausch ist es nicht, gleichgültig welche Chiffre er wählt.
Audit-Werkzeuge, die AES-128 wegen Quantenresistenz herabstufen, prüfen die Chiffre, obwohl die Quantenbedrohung auf dem Schlüsselaustausch liegt. Beschaffungsanforderungen, die AES-256 verlangen, drängen Betreiber genau in die Konfigurationen, die in den Daten oben festsitzen, in die Spalte, in der die PQC-Adoption bei 6 % statt 48 % liegt.
Die Post-Quanten-Migration dauert Jahre, und die Arbeit liegt in Legacy-Systemen und Hersteller-Abhängigkeiten. Betreiber, die AES-128 gewählt haben, sind größtenteils bereits auf hybriden Schlüsselaustausch umgestiegen. Betreiber auf Nur-AES-256 nicht. Investieren Sie die nächsten zwei Jahre in den Schlüsselaustausch, nicht in die Verdoppelung des symmetrischen Schlüssels. Der Handshake-Größenrechner schätzt, was das asymmetrische Upgrade für einen gegebenen Algorithmus-Mix kostet.
Methodik
Jeder Host trägt seinen jüngsten erfolgreichen TLS-Scan der letzten 30 Tage bei. Die Spalte „AES-Profil“ spiegelt wider, welche AES-Schlüsselgrößen in den ausgehandelten Cipher-Suites des Hosts auftauchen; Hosts, die ausschließlich ChaCha20 aushandeln, stehen in der Zeile „Keines“. Die PQC-Schlüsselaustausch-Adoption zählt Hosts, die eine ML-KEM-Gruppe bewerben oder aushandeln, in der Praxis X25519MLKEM768 oder SecP256r1MLKEM768. Prozentwerte sind auf ganze Zahlen gerundet.