2026-08-18 · RESEARCH · Das Offensive Technology Team

Certificate Transparency Post-Quantum: 43% der static-CT-Logs signieren bereits mit ML-DSA-44

Certificate Transparency hat still und leise mit der Post-Quantum-Migration begonnen und ist auf der Ebene der Log-Signaturen bereits zu 43% durch. Wir haben die öffentliche Checkpoint-Datei jedes der 70 static-CT-Logs aus der öffentlichen Log-Liste abgerufen, und 30 davon (42,9%) hängen an jeden Checkpoint zusätzlich zur klassischen ECDSA-Signatur eine Post-Quantum-Signatur mit ML-DSA-44. Das ist bemerkenswert, denn keine vergleichbare Fläche hat sich bislang bewegt: DNSSEC ist zu 0% post-quantum und der TLS-Handshake fängt gerade erst an. Der Haken liegt in der anderen Hälfte des Designs. Die Witness-Ebene, der Mechanismus, der einen Log dabei ertappen soll, wenn er die eigene Historie umschreibt, ist kaum ausgerollt: Nur 11 von 70 Logs tragen überhaupt eine Witness-Cosignatur, wir haben im gesamten Ökosystem nur 6 verschiedene Witnesses gesehen, und 0 davon sind post-quantum. Das Signieren läuft der Überwachung davon.

Was wir gemessen haben, und warum ein Checkpoint lesbar ist

Certificate Transparency bewegt sich vom alten RFC-6962-Request-Response-Protokoll weg, hin zum static-ct-api-Format, bei dem ein Log nur eine Menge statischer Dateien auf einem CDN ist. Let's Encrypt hat seine klassischen Logs am 28. Februar 2026 abgeschaltet (deren End-of-Life-Plan enthält die Zeitleiste), und das Tiled-Modell ist inzwischen der Mainstream. Die eine kleine Datei, die den aktuellen Zustand eines static Logs zusammenfasst, ist sein Checkpoint: der Name des Logs, seine Baumgröße, sein Merkle-Root-Hash und dann ein Block aus Signaturen. Er ist absichtlich öffentlich, weil Monitore weltweit ihn ständig abrufen, um den Log ehrlich zu halten. Ihn zu lesen berührt nichts Privates und sondiert keinen Host; es ist derselbe GET, den ein Monitor ausführt, und es ist das CT-Äquivalent zum Lesen eines öffentlichen DNS-Records.

Wir haben die veröffentlichte CT-Log-Liste genommen, jeden tiled Log herausgezogen und den Checkpoint jedes einzelnen genau einmal abgerufen. Alle 70 haben geantwortet. Dann haben wir den Signaturblock geparst. Im signed-note-Format, das ein Checkpoint verwendet, ist jede Signatur eine eigene Zeile: ein Bindestrich-Marker, dann der Name des Signierers, dann ein Base64-Wert, der aus einem vier Byte langen Key-Hint gefolgt von der eigentlichen Signatur besteht. Genau dieses letzte Detail ist die ganze Methode: die Byte-Länge der Signatur verrät den Algorithmus. Eine Ed25519-Signatur ist 64 Byte lang. Die alte RFC-6962-Tree-Head-Signatur ist ein Zeitstempel plus ein kurzer ECDSA-Blob. Und eine ML-DSA-44-Signatur ist 2.420 Byte lang, die feste Größe, die in NIST FIPS 204 definiert ist. Wir mussten also keinem Label vertrauen; wir haben Bytes gezählt.

Post-Quantum steckt bereits in 43% der static-CT-Logs

Hier ist die gesamte Population, klassifiziert danach, was tatsächlich in jedem Checkpoint auftaucht. Ein einzelner Checkpoint trägt meist mehr als eine Signaturzeile, daher sind dies Zählungen von Logs, nicht von Signaturen.

Die zweite Zeile ist die Schlagzeile. Dreißig Logs signieren ihren Checkpoint nicht nur mit einem klassischen Schlüssel; sie fügen zusätzlich eine vollständige 2.420-Byte-ML-DSA-44-Signatur hinzu, sodass jeder Checkpoint auf beide Arten signiert ist. Genau das verlangt die Checkpoint-Spezifikation. In ihren eigenen Worten sollen Logs ML-DSA-44-Cosignaturen verwenden, um den Checkpoint zu signieren, und das Cosignature-Format definiert einen eigenen Post-Quantum-Typ, beschrieben als sicher gegen Quantencomputer, direkt neben dem klassischen. Eine Adoptionsrate von 43% für ein soll, das die meisten Betreiber ignorieren könnten, ist schnelle Bewegung. Und sie ist konzentriert: Die Post-Quantum-Signaturen ballen sich bei einer Minderheit von Betreibern, die große Familien zeitlich gestaffelter Shard-Logs betreiben, sodass eine Entscheidung weniger Teams bereits fast die Hälfte der Population abdeckt. Wir berichten das Aggregat statt einer Name-and-Shame-Liste, denn mit mehr Kryptografie zu signieren ist eine gute Sache, kein Befund gegen irgendjemanden.

Der Grund, warum sich diese Ebene bewegen kann, während andere es nicht können, ist die Größe. Eine ML-DSA-44-Signatur ist etwa 38-mal so groß wie eine ECDSA-Signatur, weshalb sie nicht in ein DNS-Paket passt und weshalb der TLS-Handshake ihr gegenüber vorsichtig ist. Aber ein Checkpoint ist eine winzige Datei, die von ein paar tausend Monitoren abgerufen wird, kein Feld, das bei Milliarden von Handshakes mitgeschickt wird. Die Transparenzebene hat das Byte-Budget, um zuerst post-quantum zu werden, und sie gibt es aus.

Die Witness-Ebene erzählt die entgegengesetzte Geschichte

Einen Checkpoint zu signieren beweist, dass der Log eine Aussage getroffen hat. Es beweist nicht, dass der Log allen dieselbe Aussage getroffen hat. Ein kompromittierter Log kann einen Split-View-Angriff fahren: Opfern einen Baum zeigen, der ein betrügerisches Zertifikat enthält, und Monitoren einen sauberen Baum zeigen, der es nicht tut, sodass der Betrug nie dort landet, wo jemand prüft. Die Lösung heißt Witnessing. Ein Witness ist ein unabhängiger Dienst, der sich den letzten Checkpoint merkt, den er von einem Log gesehen hat, prüft, dass jeder neue eine konsistente, ausschließlich anhängende Erweiterung ist, und erst dann eine Cosignatur zurückgibt. Verlangt man genug unabhängige Witnesses auf einem Checkpoint, kann ein Log nicht länger zwei Historien pflegen, weil kein ehrlicher Witness beide cosignieren wird.

Das ist der Mechanismus, der aus einem Log von trust-me can't-lie macht. Im lebenden Ökosystem ist er dünn:

• Nur 11 von 70 Logs (16%) tragen überhaupt eine Witness-Cosignatur, und jeder dieser Logs gehört zur Log-Familie eines einzigen Betreibers. Die Checkpoints aller anderen Betreiber sind ausschließlich vom Log selbst signiert, ohne dass eine unabhängige Partei die Konsistenz bezeugt.
• Im gesamten Ökosystem tauchen nur 6 verschiedene Witnesses auf, und nur 2 davon sehen wie Produktionsdienste aus. Die anderen vier bezeichnen sich selbst als Staging-, Dev- oder Proof-of-Concept-Witnesses.
• Jede einzelne Witness-Cosignatur ist klassisches Ed25519. Kein einziger Witness verwendet den Post-Quantum-ML-DSA-44-Cosignaturtyp, den dieselbe Spezifikation definiert. Die Anti-Equivocation-Ebene ist zu 0% post-quantum.

Wo Witnessing läuft, läuft es gut: Die Cosignaturen, die wir gesehen haben, trugen Zeitstempel, die im Median etwa 5 Sekunden hinter unserem Abruf lagen, Witnesses cosignieren also nahezu in Echtzeit. Das Problem ist nicht die Latenz, es ist die Abdeckung. Eine Split-View-Verteidigung, die einen Betreiber abdeckt und zwei Produktionsteilnehmer hat, ist ein vielversprechender Pilot, aber noch keine Ökosystem-Garantie.

Zwei unterschiedliche Wetten auf die Zukunft der Transparenz

Legt man die beiden Ebenen nebeneinander, ergibt sich ein Muster, das interessanter ist als jede der beiden Zahlen für sich. Die Logs, die post-quantum geworden sind, und die Logs, die Witness-Cosignaturen tragen, sind disjunkte Mengen, betrieben von unterschiedlichen Betreibern. Ein Lager steckt seinen Aufwand in Post-Quantum-Log-Signaturen und liefert kein Witnessing. Das andere Lager steckt seinen Aufwand in das Witness-Netzwerk und liefert keine Post-Quantum-Signatur. Niemand in dieser Erhebung macht beides.

Diese Aufspaltung ist es wert, benannt zu werden, weil die beiden Investitionen gegen unterschiedliche Bedrohungen verteidigen, und die schwerer wiegende Bedrohung ist die, die verliert. Post-Quantum-Signierung verteidigt das ferne Zukunftsszenario, in dem ein Quantencomputer die Signatur eines Logs fälscht. Witnessing verteidigt das Präsens-Szenario, in dem ein Log heute widersprüchlich handelt. Das Ökosystem hat kollektiv die spekulative Bedrohung vorgezogen und in die konkrete zu wenig investiert. Post-Quantum ist das sichtbare, vorzeigbare Upgrade; Witnessing verlangt, dass andere Leute Infrastruktur betreiben und Clients ein Quorum einfordern, was organisatorisch schwerer ist. Also wurde die leichte Hälfte zuerst ausgeliefert.

Die Decoy-Signaturen, und warum sie ein gutes Zeichen sind

Ein Nebenbefund sagt etwas Gesundes über das Ökosystem aus. Bei 46 der 70 Logs (66%) trägt der Checkpoint eine Signaturzeile unter dem Namen grease.invalid, deren Bytes zufällig sind und gegen nichts verifizieren. Das steht nicht in der Spezifikation, daher berichten wir es als Beobachtung, nicht als Regel. Aber es passt exakt zur dokumentierten Anforderung, dass ein Verifizierer Signaturen von ihm unbekannten Schlüsseln ignorieren muss. Genau diese Regel macht es sicher für einen Log, Witness-Cosignaturen oder einen neuen Post-Quantum-Schlüssel hinzuzufügen, ohne alte Clients zu brechen. Eine absichtlich ungültige Signatur auszusenden, im Stil der GREASE-Technik aus TLS, zwingt jeden Parser, diese Must-Ignore-Regel tatsächlich zu respektieren, statt an der ersten unbekannten Zeile zu ersticken. Dass zwei Drittel der Logs ihre eigenen Konsumenten stresstesten, ist ein Zeichen für ein Ökosystem, das erwartet, dass der Signaturblock weiter wächst, genau das, was ein Post-Quantum-Übergang braucht.

Wie wir es gemessen haben, damit ein Skeptiker den Zahlen vertrauen kann

Der Datensatz ist unser eigener, ausschließlich aus öffentlichen Dateien aufgebaut und im Aggregat berichtet. Wir haben keinen Log gescannt, sondiert, dort etwas eingereicht oder uns über den Abruf der einen öffentlichen Checkpoint-Datei hinaus, die jeder genau zu diesem Zweck veröffentlicht, mit ihm verbunden. In einem Checkpoint existieren keine privaten Daten; er ist eine Baumgröße, ein Hash und Signaturen. Wir nennen keinen Betreiber als mangelhaft, weil keiner es ist: Dies ist eine Momentaufnahme eines Ökosystems mitten im Upgrade.

• Die Population. Jeder tiled Log in der öffentlichen CT-Log-Liste, 70 insgesamt. Alle 70 lieferten am Messtag einen parsbaren Checkpoint. Viele sind zeitliche Shards, daher ist die Log-Zahl größer als die Betreiberzahl.
• Die Klassifikation. Für jede Signaturzeile haben wir das Base64 dekodiert, den vier Byte langen Key-Hint verworfen und die verbleibende Länge gelesen. 2.420 Byte (in einem zeitgestempelten Umschlag) ist eine ML-DSA-44-Signatur nach FIPS 204; 64 ist Ed25519; der kurze zeitgestempelte Blob ist die RFC-6962-Tree-Head-Signatur. Algorithmus durch Konstruktion, nicht durch Label.
• Log gegenüber Witness. Eine Signatur, deren Name mit dem eigenen Origin des Logs übereinstimmt, ist der Log, der sich selbst signiert. Eine Cosignatur unter einer separaten Witness-Identität ist ein unabhängiges Attest. Wir haben sie getrennt gezählt, weshalb die Post-Quantum-Zahl und die Witness-Zahl unterschiedliche Ebenen beschreiben.
• Post-Quantum nach Größe. Die 30 Post-Quantum-Logs tragen jeweils eine Signatur genau der ML-DSA-44-Länge, im Cosignature-Umschlag, den die Spezifikation dafür definiert. Ein klassisches Schema kann nicht versehentlich eine 2.420-Byte-Signatur erzeugen, die Zahl ist also keine Schätzung.

Warum das wichtig ist, und die ehrlichen Grenzen

Certificate Transparency ist ein Fundament, auf dem andere Verteidigungen stehen. Es ist der Mechanismus, mit dem die Welt ein fehlerhaft ausgestelltes Zertifikat für eine Bank oder einen Mail-Anbieter bemerkt, und es untermauert Kontrollen wie die Zusicherungen, die man von einem Zertifikat ablesen kann, und Ausstellungsbeschränkungen wie CAA. Wie DNSSEC signiert CT, statt zu verschlüsseln, daher ist das Quantenrisiko zukünftige Fälschung, nicht Harvest-now-decrypt-later. Das bedeutet, das 43%-Post-Quantum-Ergebnis liegt tatsächlich vor der Bedrohung, was gute Nachrichten sind und selten sind. Aber die Kehrseite ist der Teil, der mehr Aufmerksamkeit verdient: der Mechanismus, der einen Log gegen einen heutigen, nicht-quantenfähigen Angreifer vertrauenswürdig macht, unabhängiges Witnessing, ist genau der, der dünn und klassisch ist. Wer darauf wettet, dass Transparency die nächste Fehlausstellung fängt, sollte das Witness-Netzwerk beobachten, nicht den Signaturalgorithmus.

Ein Ergebnis ohne seine Grenzen ist Marketing, hier also die Grenzen.

• Eine Liste, ein Tag. Dies ist die öffentliche Log-Liste an einem einzigen Datum. Shards werden hinzugefügt und rotiert, und Witnessing wird aktiv ausgerollt, daher werden sich die genauen Zahlen bewegen. Der strukturelle Befund, dass die Signierung dem Witnessing davongelaufen ist, ist der dauerhafte Teil.
• Nur ausgelieferte Checkpoints. Wir haben gelesen, was jeder Log an seinem eigenen Checkpoint-Endpunkt ausliefert. Ein Witness, der einen Log cosigniert, seine Cosignaturen aber anderswo verteilt, würde hier nicht auftauchen, daher ist das tatsächliche Ausmaß an Witnessing-Aktivität eine Untergrenze, keine Obergrenze. Der Punkt bleibt bestehen, dass die Checkpoints, die Clients tatsächlich abrufen, größtenteils unbezeugt sind.
• Präsenz, nicht Verifikation. Wir haben Signaturen nach Algorithmus und Identität klassifiziert, nicht durch kryptografische Verifikation jeder einzelnen gegen ihren Schlüssel. Eine vorhandene ML-DSA-44-Signatur der korrekten Größe ist ein starker Beleg für Post-Quantum-Signierung; zu bestätigen, dass jede Signatur valide ist, ist eine separate Übung.
• Die GREASE-Zeile ist abgeleitet. Das grease.invalid-Decoy ist unsere Lesart eines undokumentierten, aber konsistenten Verhaltens, kein spezifikationsvorgeschriebenes Feature.

Häufig gestellte Fragen

Was ist ein static CT log?

Ein static CT log ist ein Certificate-Transparency-Log, das als statische Dateien, genannt Tiles, aus Object Storage oder einem CDN ausgeliefert wird, nach der C2SP-static-ct-api-Spezifikation. Statt der RFC-6962-Request-Response-API veröffentlicht es ausschließlich anhängende Tiles zu je 256 Einträgen plus einen kleinen signierten Checkpoint, der die aktuelle Baumgröße und den Root-Hash angibt. Monitore lesen die Dateien direkt, was Logs günstig im Betrieb und Mirroring macht. Dieses Design, ursprünglich Sunlight API genannt, wurde 2025 und 2026 bei den CT-Betreibern zum Mainstream.

Sind Certificate-Transparency-Logs schon post-quantum?

Teilweise, und früher als die meisten annehmen. In unserer Erhebung aller 70 static-CT-Logs hängen 30 davon (43%) bereits an jeden Checkpoint eine ML-DSA-44-Signatur, zusätzlich zu ihrer klassischen Signatur. ML-DSA-44 ist das Gitter-Schema aus FIPS 204, das Quantenangriffen widersteht, und genau das empfiehlt die Checkpoint-Spezifikation. Die Log-Signierungsebene steckt also schon tief in ihrer Post-Quantum-Migration. Die Witness-Ebene, die diese Checkpoints cosigniert, ist immer noch zu 0% post-quantum; jede Witness-Cosignatur, die wir gesehen haben, war klassisches Ed25519.

Was ist ML-DSA-44 und warum wird es hier eingesetzt?

ML-DSA-44 ist das kleinste Parameter-Set von ML-DSA, dem Modul-Gitter-Signaturstandard in NIST FIPS 204, abgeleitet von CRYSTALS-Dilithium. Seine Signaturen sind 2.420 Byte groß und seine Schlüssel 1.312 Byte, weit größer als eine 64-Byte-Ed25519-Signatur, aber es wird nicht durch Shors Algorithmus gebrochen. Certificate Transparency kann die Größe verkraften, weil ein Checkpoint gelegentlich von Monitoren abgerufen wird, nicht bei jedem Handshake mitgeschickt wird, weshalb CT Post-Quantum-Signaturen Jahre vor DNSSEC oder dem TLS-Handshake übernehmen kann.

Was ist ein CT-Witness und eine Witness-Cosignatur?

Ein Witness ist ein unabhängiger Dienst, identifiziert durch einen Namen und einen öffentlichen Schlüssel, der die Checkpoints eines Logs beobachtet. Bevor er einen neuen Checkpoint cosigniert, prüft er, dass der neue Baum konsistent mit dem letzten ist, den er gesehen hat, das heißt, der Log hat nur angehängt und nie die Historie umgeschrieben, und gibt dann eine zeitgestempelte Cosignatur zurück, definiert durch die C2SP-tlog-witness- und tlog-cosignature-Spezifikationen. Ein Checkpoint mit Cosignaturen mehrerer unabhängiger Witnesses ist für einen kompromittierten Log deutlich schwerer zu belügen.

Wie verhindert eine Witness-Cosignatur einen Split View?

Ein Split-View-Angriff ist ein Log, der Opfern einen Baum und Monitoren einen anderen, ehrlichen Baum zeigt, sodass betrügerische Zertifikate nie dort auftauchen, wo jemand prüft. Weil ein Witness einen Checkpoint erst cosigniert, nachdem er die Konsistenz mit der bereits gehaltenen Historie geprüft hat, kann ein Log nicht zwei widersprüchliche Checkpoints vom selben ehrlichen Witness cosigniert bekommen. Verlangen Clients Cosignaturen von einem Quorum unabhängiger Witnesses, muss der Log allen denselben ausschließlich anhängenden Baum zeigen, was die Lücke schließt, die reines Logging offen lässt.

Wann wurden RFC-6962-Certificate-Transparency-Logs abgeschaltet?

Die Migration lief durch 2025 und 2026. Let's Encrypt kündigte im August 2025 das End-of-Life für seine RFC-6962-Logs an, stellte sie am 30. November 2025 auf Read-only und schaltete sie am 28. Februar 2026 vollständig ab, zugunsten seiner static Sycamore- und Willow-Logs. Chrome fügte Anfang 2025 Unterstützung für static-ct-api hinzu und phast die Anforderung aus, dass mindestens ein SCT von einem alten RFC-6962-Log stammen muss.

Wie viele Certificate-Transparency-Logs gibt es 2026?

Die öffentliche CT-Log-Liste, die wir verwendet haben, enthält 70 static, tiled Logs bei einer Handvoll Betreiber, zusätzlich zu den verbleibenden klassischen Logs. Viele der 70 sind zeitliche Shards, jeder deckt einen Bereich von Zertifikatsablaufdaten ab, sodass ein Betreiber mehrere gleichzeitig betreibt. Alle 70 static Logs lieferten einen lesbaren Checkpoint, als wir sie gemessen haben.

Verwandte Beiträge

• DNSSEC Post-Quantum-Bereitschaft: 0% der Top-30.000-Domains. Dieselbe Post-Quantum-Frage auf einer Fläche, die sich noch nicht bewegen kann, weil die Signaturen nicht in ein DNS-Paket passen.
• Deaktiviert FIPS Post-Quantum-TLS? Der Post-Quantum-Übergang gemessen am TLS-Handshake statt an der Transparenzebene.
• Was die Zertifikate beweisen. Kryptografische Zusicherungen aus öffentlichen Records lesen, statt dem Label zu vertrauen, dieselbe Methode angewandt auf Zertifikate selbst.
• Wie viele Top-Domains beschränken die Zertifikatsausstellung? Das Zertifikats-Ökosystem passiv aus öffentlichen Daten gemessen.