2026-08-18 · RECHERCHE · L'équipe Offensive Technology

Certificate transparency post-quantique : 43% des logs static-CT signent déjà avec ML-DSA-44

La certificate transparency a discrètement entamé sa migration post-quantique, et elle en est déjà à 43% au niveau de la signature des logs. Nous avons récupéré le fichier checkpoint public de chacun des 70 logs static-CT de la liste publique des logs, et 30 d'entre eux (42,9%) attachent une signature post-quantique ML-DSA-44 à chaque checkpoint, juste à côté de leur signature classique ECDSA. C'est remarquable, car aucune surface comparable n'a bougé : DNSSEC est à 0% post-quantique et la poignée de main TLS n'en est qu'à ses débuts. Le rebondissement se trouve dans l'autre moitié du dispositif. La couche des témoins (witnesses), le mécanisme censé détecter un log qui mentirait sur sa propre histoire, est à peine déployée : seuls 11 logs sur 70 portent une quelconque cosignature de témoin, nous n'avons observé que 6 témoins distincts sur l'ensemble de l'écosystème, et 0 d'entre eux sont post-quantiques. La signature va plus vite que la surveillance.

Ce que nous avons mesuré, et pourquoi un checkpoint est lisible

La certificate transparency migre de l'ancien protocole requête-réponse RFC 6962 vers le format static-ct-api, où un log n'est qu'un ensemble de fichiers statiques sur un CDN. Let's Encrypt a arrêté ses logs classiques le 28 février 2026 (leur plan de fin de vie en donne le calendrier), et le modèle en tuiles (tiled) est désormais la norme. Le petit fichier unique qui résume l'état courant d'un log statique est son checkpoint : le nom du log, la taille de son arbre, le hash racine Merkle, puis un bloc de signatures. Il est public par conception, car des moniteurs du monde entier le récupèrent en permanence pour garder le log honnête. Le lire ne touche rien de privé et ne sonde aucun hôte ; c'est le même GET qu'effectue un moniteur, l'équivalent CT de la lecture d'un enregistrement DNS public.

Nous avons pris la liste publique des logs CT, extrait chaque log en tuiles, et récupéré une seule fois le checkpoint de chacun. Les 70 ont répondu. Nous avons ensuite analysé le bloc de signatures. Dans le format signed-note qu'utilise un checkpoint, chaque signature est sur sa propre ligne : un marqueur tiret, puis le nom du signataire, puis une valeur en base64 constituée d'un indice de clé de quatre octets suivi de la signature elle-même. Ce dernier détail contient toute la méthode : la longueur en octets de la signature révèle son algorithme. Une signature Ed25519 fait 64 octets. La signature legacy tree-head du RFC 6962 est un horodatage suivi d'un court blob ECDSA. Et une signature ML-DSA-44 fait 2 420 octets, la taille fixe définie par NIST FIPS 204. Nous n'avons donc pas eu à faire confiance à une étiquette ; nous avons compté les octets.

Le post-quantique équipe déjà 43% des logs static-CT

Voici l'ensemble de la population, classée selon ce qui apparaît réellement dans chaque checkpoint. Un checkpoint donné porte généralement plusieurs lignes de signature, ce sont donc ici des comptages de logs, pas de signatures.

La deuxième ligne est le fait marquant. Trente logs ne se contentent pas de signer leur checkpoint avec une clé classique ; ils ajoutent une signature ML-DSA-44 complète de 2 420 octets par-dessus, si bien que chaque checkpoint est signé des deux façons. C'est exactement ce que demande la spécification du checkpoint. Dans ses propres termes, les logs devraient utiliser des cosignatures ML-DSA-44 pour signer le checkpoint, et le format de cosignature définit un type post-quantique dédié, décrit comme sûr contre les ordinateurs quantiques, placé juste à côté du type classique. Un taux d'adoption de 43% pour un devraient que la plupart des opérateurs pourraient ignorer, c'est un mouvement rapide. Et il est concentré : les signatures post-quantiques se regroupent chez une minorité d'opérateurs qui exploitent de grandes familles de logs à shards temporels, si bien que la décision de quelques équipes couvre déjà près de la moitié de la population. Nous rapportons l'agrégat plutôt qu'une liste nominative, car signer avec davantage de crypto est une bonne chose, pas un constat à charge contre qui que ce soit.

Si cette couche peut avancer là où d'autres ne le peuvent pas, c'est une question de taille. Une signature ML-DSA-44 fait environ 38 fois la taille d'une signature ECDSA, raison pour laquelle elle ne tient pas dans un paquet DNS et pour laquelle la poignée de main TLS s'en méfie. Mais un checkpoint est un tout petit fichier récupéré par quelques milliers de moniteurs, pas un champ envoyé sur des milliards de poignées de main. La couche de transparence dispose du budget d'octets pour passer au post-quantique en premier, et elle l'utilise.

La couche des témoins raconte l'histoire inverse

Signer un checkpoint prouve que le log a fait une déclaration. Cela ne prouve pas que le log a fait la même déclaration à tout le monde. Un log compromis peut monter une attaque par vue scindée (split-view) : montrer aux victimes un arbre contenant un certificat frauduleux, et montrer aux moniteurs un arbre propre qui ne le contient pas, de sorte que la fraude n'atterrisse jamais là où quelqu'un audite. Le remède, c'est le témoignage (witnessing). Un témoin est un service indépendant qui mémorise le dernier checkpoint qu'il a vu d'un log, vérifie que chaque nouveau checkpoint en constitue une extension cohérente et strictement additive, et ne renvoie une cosignature qu'à cette condition. Exiger suffisamment de témoins indépendants sur un checkpoint, et un log ne peut plus maintenir deux historiques, car aucun témoin honnête ne cosignera les deux.

C'est le mécanisme qui fait passer un log du statut de « faites-moi confiance » à celui de « ne peut pas mentir ». Dans l'écosystème réel, il est ténu :

• Seuls 11 logs sur 70 (16%) portent une quelconque cosignature de témoin, et chacun de ces logs appartient à la famille de logs d'un seul et même opérateur. Les checkpoints de tous les autres opérateurs sont signés par le log seul, sans qu'aucune partie indépendante n'atteste de leur cohérence.
• Seuls 6 témoins distincts apparaissent sur l'ensemble de l'écosystème, et 2 d'entre eux seulement ressemblent à des services de production. Les quatre autres se présentent comme des témoins de staging, de développement, ou de preuve de concept.
• Chaque cosignature de témoin, sans exception, est en Ed25519 classique. Aucun témoin n'utilise le type de cosignature post-quantique ML-DSA-44 que la même spécification définit pourtant. La couche anti-équivoque est à 0% post-quantique.

Là où le témoignage fonctionne, il fonctionne bien : les cosignatures observées portaient des horodatages en retard d'une médiane d'environ 5 secondes sur notre récupération, donc les témoins cosignent quasiment en temps réel. Le problème n'est pas la latence, c'est la couverture. Une défense contre les vues scindées qui ne couvre qu'un opérateur et compte deux participants en production est un pilote prometteur, pas encore une garantie à l'échelle de l'écosystème.

Deux paris différents sur l'avenir de la transparence

Placez les deux couches côte à côte, et un schéma se dégage, plus intéressant que chaque chiffre pris isolément. Les logs passés au post-quantique et les logs porteurs de cosignatures de témoins sont des ensembles disjoints, gérés par des opérateurs différents. Un camp consacre son effort aux signatures de log post-quantiques et ne déploie aucun témoignage. L'autre camp consacre son effort au réseau de témoins et ne déploie aucune signature post-quantique. Personne, dans ce recensement, ne fait les deux.

Cette scission mérite d'être nommée, car les deux investissements défendent contre des menaces différentes, et la menace la plus difficile est celle qu'on est en train de perdre. La signature post-quantique défend contre le scénario d'un futur lointain où un ordinateur quantique forgerait la signature d'un log. Le témoignage défend contre le scénario au présent où un log équivoque aujourd'hui même. L'écosystème a collectivement priorisé la menace spéculative et sous-investi dans la menace concrète. Le post-quantique est la mise à niveau visible et démontrable ; le témoignage exige que d'autres acteurs exploitent une infrastructure et que les clients exigent un quorum, ce qui est organisationnellement plus difficile. La moitié facile a donc été livrée en premier.

Les signatures leurres, et pourquoi c'est bon signe

Une découverte incidente dit quelque chose de sain sur l'écosystème. Sur 46 des 70 logs (66%), le checkpoint porte une ligne de signature sous le nom grease.invalid, dont les octets sont aléatoires et ne vérifient contre rien. Ce n'est pas prévu par la spécification, nous le rapportons donc comme une observation, pas comme une règle. Mais cela correspond exactement à l'exigence documentée selon laquelle un vérificateur doit ignorer les signatures provenant de clés qu'il ne reconnaît pas. C'est cette règle qui permet à un log d'ajouter en toute sécurité des cosignatures de témoins ou une nouvelle clé post-quantique sans casser les anciens clients. Émettre une signature délibérément invalide, dans l'esprit de la technique GREASE issue de TLS, force chaque analyseur à réellement respecter cette règle d'ignorance obligatoire plutôt qu'à s'étouffer sur la première ligne non reconnue. Que deux tiers des logs testent ainsi la robustesse de leurs propres consommateurs est le signe d'un écosystème qui s'attend à voir le bloc de signatures continuer de grandir, ce qui est précisément ce qu'exige une transition post-quantique.

Comment nous l'avons mesuré, pour qu'un sceptique puisse faire confiance aux chiffres

Le jeu de données est le nôtre, construit uniquement à partir de fichiers publics, et rapporté de façon agrégée. Nous n'avons scanné, sondé, soumis, ni connecté aucun log au-delà de la récupération de l'unique fichier checkpoint public que chacun publie précisément à cette fin. Aucune donnée privée n'existe dans un checkpoint ; ce n'est qu'une taille d'arbre, un hash, et des signatures. Nous ne désignons aucun opérateur comme déficient, car aucun ne l'est : ceci est l'instantané d'un écosystème en pleine mise à niveau.

• La population. Chaque log en tuiles de la liste publique des logs CT, soit 70 au total. Les 70 ont renvoyé un checkpoint analysable à la date de la mesure. Beaucoup sont des shards temporels, si bien que le nombre de logs dépasse le nombre d'opérateurs.
• La classification. Pour chaque ligne de signature, nous avons décodé le base64, retiré l'indice de clé de quatre octets, et lu la longueur restante. 2 420 octets (dans une enveloppe horodatée) correspondent à une signature ML-DSA-44 selon FIPS 204 ; 64 octets correspondent à Ed25519 ; le court blob horodaté correspond à la signature tree-head du RFC 6962. L'algorithme est déduit de la construction, pas d'une étiquette.
• Log contre témoin. Une signature dont le nom correspond à l'origine propre du log est le log qui se signe lui-même. Une cosignature sous une identité de témoin distincte est une attestation indépendante. Nous les avons comptées séparément, ce qui explique pourquoi le compte post-quantique et le compte de témoins décrivent des couches différentes.
• Post-quantique par la taille. Chacun des 30 logs post-quantiques porte une signature exactement de la longueur ML-DSA-44, dans l'enveloppe de cosignature définie à cet effet par la spécification. Un schéma classique ne peut pas produire accidentellement une signature de 2 420 octets, ce comptage n'est donc pas une estimation.

Pourquoi cela compte, et les limites honnêtes

La certificate transparency est un socle sur lequel reposent d'autres défenses. C'est ce qui permet au monde de remarquer un certificat mal émis pour une banque ou un fournisseur de messagerie, et cela vient appuyer des contrôles comme les garanties que l'on peut lire sur un certificat et les restrictions d'émission telles que CAA. Comme DNSSEC, CT signe plutôt qu'elle ne chiffre, donc le risque quantique est celui de la falsification future, pas du harvest-now-decrypt-later. Cela signifie que le résultat de 43% post-quantique est véritablement en avance sur la menace, ce qui est une bonne nouvelle, et rare. Mais l'envers du décor mérite plus d'attention : le mécanisme qui rend un log digne de confiance face à un attaquant présent, non quantique, à savoir le témoignage indépendant, est celui qui est ténu et classique. Si vous misez sur la transparence pour détecter la prochaine mauvaise émission, c'est le réseau de témoins qu'il faut surveiller, pas l'algorithme de signature.

Un résultat sans ses limites relève du marketing, voici donc les bornes.

• Une liste, un jour. Ceci est la liste publique des logs à une date donnée. Des shards sont ajoutés et tournent, et le témoignage est en cours de déploiement actif, donc les chiffres exacts vont évoluer. Le constat structurel, à savoir que la signature a devancé le témoignage, est la partie durable.
• Uniquement les checkpoints servis. Nous avons lu ce que chaque log sert sur son propre endpoint de checkpoint. Un témoin qui cosigne un log mais distribue ses cosignatures ailleurs n'apparaîtrait pas ici, donc le volume réel d'activité de témoignage est un plancher, pas un plafond. Le constat tient malgré tout : les checkpoints que les clients récupèrent réellement sont majoritairement non témoignés.
• Présence, pas vérification. Nous avons classé les signatures par algorithme et par identité, pas en les vérifiant cryptographiquement une à une contre leur clé. Une signature ML-DSA-44 présente et de la bonne taille est un indice solide de signature post-quantique ; confirmer que chaque signature est valide est un exercice distinct.
• La ligne GREASE est déduite. Le grease.invalid leurre est notre lecture d'un comportement non documenté mais cohérent, pas une fonctionnalité imposée par la spécification.

Questions fréquentes

Qu'est-ce qu'un log CT statique ?

Un log CT statique est un log de certificate transparency servi sous forme de fichiers statiques, appelés tuiles, depuis un stockage d'objets ou un CDN, en suivant la spécification C2SP static-ct-api. Plutôt que l'API requête-réponse du RFC 6962, il publie des tuiles strictement additives de 256 entrées, plus un petit checkpoint signé indiquant la taille courante de l'arbre et le hash racine. Les moniteurs lisent directement ces fichiers, ce qui rend un log bon marché à exploiter et à répliquer. Cette conception, d'abord appelée Sunlight API, s'est généralisée chez les opérateurs de CT en 2025 et 2026.

Les logs de certificate transparency sont-ils déjà post-quantiques ?

En partie, et plus tôt que la plupart ne l'imaginent. Dans notre recensement des 70 logs static-CT, 30 d'entre eux (43%) attachent déjà une signature ML-DSA-44 à chaque checkpoint, en plus de leur signature classique. ML-DSA-44 est le schéma à réseaux euclidiens de FIPS 204 qui résiste aux attaques quantiques, et c'est exactement ce que recommande la spécification du checkpoint. La couche de signature des logs est donc bien engagée dans sa migration post-quantique. La couche des témoins qui cosignent ces checkpoints, elle, est encore à 0% post-quantique ; chaque cosignature de témoin observée était en Ed25519 classique.

Qu'est-ce que ML-DSA-44 et pourquoi est-il utilisé ici ?

ML-DSA-44 est le plus petit jeu de paramètres de ML-DSA, le standard de signature à réseaux euclidiens modulaires de NIST FIPS 204, dérivé de CRYSTALS-Dilithium. Ses signatures font 2 420 octets et ses clés 1 312 octets, bien plus qu'une signature Ed25519 de 64 octets, mais il n'est pas cassé par l'algorithme de Shor. La certificate transparency peut absorber cette taille car un checkpoint est récupéré occasionnellement par des moniteurs, et non envoyé à chaque poignée de main, ce qui explique pourquoi CT peut adopter des signatures post-quantiques des années avant DNSSEC ou la poignée de main TLS.

Qu'est-ce qu'un témoin CT et une cosignature de témoin ?

Un témoin est un service indépendant, identifié par un nom et une clé publique, qui surveille les checkpoints d'un log. Avant de cosigner un nouveau checkpoint, il vérifie que le nouvel arbre est cohérent avec le dernier qu'il a vu, ce qui signifie que le log s'est contenté d'ajouter des entrées sans jamais réécrire son historique, puis il renvoie une cosignature horodatée définie par les spécifications C2SP tlog-witness et tlog-cosignature. Un checkpoint portant des cosignatures de plusieurs témoins indépendants est beaucoup plus difficile à falsifier pour un log compromis.

Comment une cosignature de témoin empêche-t-elle une vue scindée ?

Une attaque par vue scindée consiste, pour un log, à montrer un arbre aux victimes et un arbre différent et honnête aux moniteurs, de sorte que les certificats frauduleux n'apparaissent jamais là où quelqu'un audite. Comme un témoin ne cosigne qu'après avoir vérifié la cohérence avec l'historique qu'il détient déjà, un log ne peut pas faire cosigner deux checkpoints contradictoires par le même témoin honnête. Si les clients exigent des cosignatures d'un quorum de témoins indépendants, le log doit montrer à tout le monde le même arbre strictement additif, ce qui referme la brèche que laisse ouverte une simple journalisation.

Quand les logs de certificate transparency RFC 6962 ont-ils fermé ?

La migration s'est étalée sur 2025 et 2026. Let's Encrypt a annoncé la fin de vie de ses logs RFC 6962 en août 2025, les a basculés en lecture seule le 30 novembre 2025, et les a définitivement arrêtés le 28 février 2026, au profit de ses logs statiques Sycamore et Willow. Chrome a ajouté la prise en charge de static-ct-api début 2025 et supprime progressivement l'exigence qu'au moins un SCT provienne d'un ancien log RFC 6962.

Combien de logs de certificate transparency existe-t-il en 2026 ?

La liste publique des logs CT que nous avons utilisée contient 70 logs statiques en tuiles répartis chez une poignée d'opérateurs, en plus des logs classiques restants. Beaucoup des 70 sont des shards temporels, chacun couvrant une plage de dates d'expiration de certificats, si bien qu'un même opérateur en exploite plusieurs à la fois. Les 70 logs statiques ont tous servi un checkpoint lisible au moment de notre mesure.

Lectures liées

• Préparation post-quantique de DNSSEC : 0% des 30 000 premiers domaines. La même question post-quantique sur une surface qui ne peut pas encore bouger, car les signatures ne tiennent pas dans un paquet DNS.
• FIPS désactive-t-il le TLS post-quantique ? La transition post-quantique mesurée sur la poignée de main TLS plutôt que sur la couche de transparence.
• Ce que prouvent les certificats. Lire les garanties cryptographiques sur des enregistrements publics plutôt que de faire confiance à l'étiquette, la même méthode appliquée aux certificats eux-mêmes.
• Combien de domaines majeurs restreignent l'émission de certificats ? L'écosystème des certificats mesuré passivement à partir de données publiques.