Zusammenfassung

  • RFC 10024 definiert drei TLS-1.3-Gruppen, die ECDHE- und ML-KEM-Werte in festgelegter Reihenfolge prüfen, zusammenfügen und in den TLS-Schlüsselplan geben.
  • Die kryptografische Zielaussage „mindestens eine Komponente bleibt sicher“ ist keine Aussage über unabhängige RNG-, Prozess-, Bibliotheks- oder Betreibergrenzen.
  • Die FIPS-Folge der Komponenten, der tatsächlich gewählte ServerHello-Wert, die Zertifikatssignatur und die reale TLS-Terminierung müssen getrennt belegt werden.

Der Prüfbericht enthielt die richtige Zahl und die falsche Reichweite

Ein Prüfer erhält vier Angaben: Gruppe 4587 sei aktiviert, ECDHE werde in einem zertifizierten Modul ausgeführt, ML-KEM-768 sei standardkonform implementiert und der Handshake-Test sei grün. Im Abschlussbericht wird daraus ein Satz: Die hybride Verbindung sei FIPS-zertifiziert und gegen den Ausfall einer Komponente abgesichert.

Die einzelnen Angaben können stimmen und der Satz trotzdem zu weit reichen. Das Zertifikat erfasst möglicherweise nur die ECDHE-Operation. Beide Komponenten beziehen Zufall aus demselben Prozess. Die ML-KEM-Bibliothek liegt außerhalb der Zertifikatsgrenze. Ein einziger Operator kann per Rollback beide Implementierungen austauschen. Und der Test hat womöglich nur einen von mehreren TLS-Terminatoren erfasst.

Hier liegt kein Wortklauben vor. Die genaue Trennung entscheidet, ob eine Organisation weiß, was bei einem RNG-Fehler, einer Speicherlücke oder einer fehlerhaften Auslieferung tatsächlich übrig bleibt.

RFC 10024 erschien im August 2026 auf dem IETF Standards Track. Das Dokument definiert drei Post-Quantum-Traditional-Gruppen für TLS 1.3. Jede verbindet einen ephemeren elliptischen Schlüsselaustausch mit ML-KEM. Das kombinierte Sitzungsgeheimnis soll geschützt bleiben, wenn mindestens einer der beiden Mechanismen sicher bleibt.

Die Aussage betrifft die kryptografische Konstruktion unter ihren Voraussetzungen. Die Unabhängigkeit der ausführenden Systeme gehört nicht automatisch dazu.

Ein NamedGroup ist eine fest geordnete Konstruktion

Nach dem Rahmen von RFC 9954 handelt TLS nicht zwei lose Erweiterungen aus. Jede Kombination erscheint als ein undurchsichtiger NamedGroup. Öffentliche Werte oder Chiffrate der Komponenten werden in festgelegter Reihenfolge unmittelbar aneinandergefügt. Dasselbe gilt für die Geheimnisse fester Länge, die anschließend an die Stelle des gewöhnlichen (EC)DHE-Geheimnisses im TLS-1.3-Schlüsselplan treten.

X25519MLKEM768 mit IANA-Wert 4588 beginnt mit ML-KEM. Der Client sendet 1.184 Byte ML-KEM-768-Kapselungsschlüssel und 32 Byte X25519, zusammen 1.216 Byte. Der Server antwortet mit 1.088 Byte ML-KEM-Chiffrat und 32 Byte X25519, zusammen 1.120 Byte. Das Geheimnis besteht aus 32 Byte ML-KEM und danach 32 Byte X25519.

SecP256r1MLKEM768, Wert 4587, beginnt mit P-256: clientseitig 65 Byte unkomprimierter Punkt und 1.184 Byte ML-KEM, serverseitig 65 und 1.088 Byte. Das Geheimnis enthält zunächst 32 Byte ECDHE, dann 32 Byte ML-KEM.

SecP384r1MLKEM1024, Wert 4589, verbindet einen 97-Byte-P-384-Punkt mit 1.568 Byte ML-KEM-1024. Die Key Shares beider Seiten sind 1.665 Byte lang. Das Geheimnis hat 48 Byte ECDHE und 32 Byte ML-KEM.

Die festen Längen machen die Verkettung eindeutig. Sie zeigen auch, dass Reihenfolge, Parameter, Prüfungen und Schlüsselplan zur Konstruktion gehören. Eine ähnlich aussehende Verkettung in einem anderen Protokoll erbt die Analyse nicht.

Der Transcript ist Teil des Sicherheitsbelegs

Das aktuelle TLS 1.3 in RFC 9846 bindet ClientHello, ein mögliches HelloRetryRequest, das zweite ClientHello, ServerHello und die Authentisierungsnachrichten in den Transcript ein. Der ausgewählte Key Share bestimmt den geheimen Eingang des Schlüsselplans. CertificateVerify signiert den Transcript; Finished weist den Besitz der abgeleiteten Schlüssel nach.

RFC 10024 erklärt ausdrücklich, dass seine Sicherheitsanalyse entscheidend auf diesem TLS-Transcript beruht. Nicht die Verkettung allein trägt die Aussage, sondern die Bindung von Angebot, Auswahl und Authentisierung an dieselbe Sitzung.

RFC 9794 setzt auch dem Sprachgebrauch eine Grenze. Ein hybrides PQ/T-Schema enthält mindestens eine Post-Quantum- und eine traditionelle Komponente. „Post-Quantum“ bezeichnet eine beabsichtigte Eigenschaft, keine ewige Garantie gegen jeden klassischen oder quantenbasierten Angriff.

Ein Betriebsnachweis hält deshalb angebotene Gruppen, gesendete Key Shares, HelloRetryRequest, ausgewählte Gruppe, Validierungsfehler, das Signaturverfahren von CertificateVerify und den Abschluss von Finished zusammen. Eine Konfiguration mit der Aufschrift „hybrid aktiviert“ belegt nur eine Absicht.

Protokollprüfungen attestieren keine Fertigungsstraße

Der Server muss den ML-KEM-Kapselungsschlüssel des Clients gemäß FIPS 203 prüfen und bei einem Fehler mit illegal_parameter abbrechen. Der Client prüft die Länge des Chiffrats. ECDHE führt seine Gültigkeitsprüfungen aus; bei X25519 gehört dazu die Zurückweisung eines nur aus Nullen bestehenden Geheimnisses. Ein anderer ML-KEM-Entkapselungsfehler führt zu internal_error.

Diese Ablehnungen verhindern, dass fehlerhaftes Material unbemerkt als Sitzung akzeptiert wird. Sie prüfen weder die Herkunft des Zufalls noch Seitenkanalschutz, gemeinsame Speicherbereiche, Lieferkette oder den tatsächlichen Terminator.

FIPS 203 standardisiert ML-KEM-512, 768 und 1024 und beschreibt ML-KEM als gegen Angreifer mit Quantencomputer für sicher gehalten. Die vorsichtige Formulierung ist sachgerecht: Standardisierung ersetzt keine korrekte Implementierung und keine weitere Kryptoanalyse.

NIST SP 800-227 enthält weitergehende Empfehlungen zum sicheren Einsatz von KEMs, auch zu Kombinationen. Ein Verweis auf das Dokument sagt noch nicht, welche Empfehlung ein konkretes Produktionsmodul erfüllt.

Den gemeinsamen Zufallspfad nennt der RFC selbst

Bei der ML-KEM-Kapselung erzeugt der Server den Zufallswert m. Der Client kann ihn bei der Entkapselung wiedergewinnen. RFC 10024 weist darauf hin, dass dadurch auch Informationen über andere Ausgaben des Generators an den Client gelangen können, wenn m solche Informationen trägt. ECDHE-Skalare benötigen ebenfalls kryptografisch sicheren Zufall, werden aber nicht direkt übertragen.

Daraus folgt die ausdrückliche Warnung: Nutzen beide Algorithmen denselben unsicheren RNG, kann eine Zustandsaufdeckung über die eine Komponente die Sicherheit der anderen beeinträchtigen.

Das Adjektiv „unsicher“ darf nicht entfallen. Ein korrekt entworfener, initialisierter, nachgespeister und geschützter CSPRNG wird nicht allein durch gemeinsame Nutzung schlecht. Der RFC verlangt auch keine zwei physischen Entropiegeräte. Er verlangt, die Abhängigkeit nicht mit der Algorithmenliste zu verwechseln.

RFC 8937 erläutert, wie mangelhafte Anfangsentropie alle daraus initialisierten Generatorinstanzen schwächen kann. Das Dokument schlägt unter anderem eine optionale Hülle vor, die Material aus einer Operation mit einem langlebigen privaten Schlüssel einmischt. Ob diese oder eine andere Technik eingesetzt wird, muss durch Seed-, Reseed-, Fork-, Snapshot-, Rollback- und Health-Test-Daten belegt werden.

Der Zufall ist das ausdrücklich genannte Beispiel. Ein gemeinsamer Bibliotheksfehler, HSM-Firmware, Speicherraum, Build-Schlüssel oder Administrationszugang kann ebenfalls beide Zweige durchqueren. Das ist keine Widerlegung der Mathematik, sondern eine Feststellung über ihre operative Reichweite.

Die FIPS-Reihenfolge verteilt eine konkrete Pflicht

RFC 10024 beschreibt die NIST-Bedingung für HKDF mit zwei verschiedenen Geheimnissen: Das erste muss aus einem FIPS-anerkannten Schlüsselerzeugungsverfahren stammen. Bei SecP256r1MLKEM768 und SecP384r1MLKEM1024 steht ECDHE zuerst. Für die beschriebene Nutzung muss die ECDHE-Implementierung zertifiziert sein; die Reihenfolgebedingung verlangt nicht zugleich die Zertifizierung der ML-KEM-Implementierung. Bei X25519MLKEM768 steht ML-KEM zuerst, also muss dessen Implementierung zertifiziert sein.

„Zuerst“ ist keine Sicherheitsrangliste. Die Zertifizierung einer Komponente umfasst nicht automatisch die zweite, den RNG, das Gesamtprogramm, die Aushandlungspolitik oder den Dienst. Ein belastbarer Bericht nennt Modul, Version, Zertifikat und Außengrenze.

IANA vergibt Bezeichner, keine Betriebsfreigabe

Das IANA-Register der TLS Supported Groups weist den finalen Gruppen 4587, 4588 und 4589 zu. Nur X25519MLKEM768 trägt Recommended Y; die beiden secp-Kombinationen tragen N. Laut IANA bedeutet N nicht zwingend einen Mangel, sondern kann einen begrenzten oder besonderen Einsatzzweck anzeigen.

Die experimentellen Kyber-Draft-Werte 25497 und 25498 sind als veraltet und nicht empfohlen markiert. Telemetrie muss sie von den finalen Codes unterscheiden. Die Sammelanzeige „PQC“ verdeckt unterschiedliche Wire Semantics.

Das Register belegt einen gemeinsamen Namen. Eine Konfiguration belegt lokale Absicht. ClientHello belegt ein Angebot. ServerHello und Transcript belegen die Auswahl einer Verbindung. Flottenabdeckung erfordert Flottenmessung.

Die offizielle Errata-Suche zu RFC 10024 zeigte am 30. August 2026 keinen Eintrag. Das ist ein datierter Registerstand, keine Aussage über sämtliche Implementierungen.

Schlüsselaushandlung und Zertifikatssignatur bleiben getrennt

RFC 9954 schließt Authentisierung der nächsten Generation aus seinem Geltungsbereich aus. TLS 1.3 trennt die Schlüsselaushandlung von Certificate und CertificateVerify. Eine Verbindung kann X25519MLKEM768 korrekt aushandeln und den Server weiterhin mit einem traditionellen Signaturverfahren authentisieren.

Hybrider Schlüsselaustausch adressiert „heute sammeln, später entschlüsseln“. Künftige Identitätsfälschung und Zertifikatsmigration folgen einem anderen Zeitplan. Die Felder für Gruppe, Signatur, Terminator und Anwendungsfreigabe dürfen nicht in „PQC abgeschlossen“ verschwinden.

Heng Lus Running-Code Primacy liefert die Beweisregel: Ausgeführter Transcript und beobachtetes Ergebnis stehen über dem Konfigurationssymbol. Die Lehre von minimaler Anfangsspezifikation und lokalisierter Zukunftsentscheidung erklärt, weshalb ein interoperabler Standard nicht jede Betriebsgrenze zentral festlegt.

Die Analyse von Realitätsebenen und symbolischer Macht trennt das Wort „hybrid“ von den Operationen, für die es steht. Die Betrachtung technischer und praktischer Datenkontrolle fragt, wer Terminator, Bibliothek, Entropie, Telemetrie und Rollback tatsächlich ändern darf. Dort verläuft die wirksame Kontrollgrenze.

TLS kann zwei Geheimnisse regelgerecht kombinieren. Die Organisation muss belegen, dass nicht dieselbe Störung beide auswählt.