2026-08-18 · RESEARCH · El equipo de Offensive Technology

Certificate transparency post-quantum: el 43% de los logs static-CT ya firman con ML-DSA-44

Certificate transparency ha comenzado silenciosamente su migración post-quantum, y ya lleva un 43% de avance en la capa de firma de los logs. Obtuvimos el archivo de checkpoint público de cada uno de los 70 logs static-CT de la lista pública de logs, y 30 de ellos (42.9%) adjuntan una firma post-quantum ML-DSA-44 a cada checkpoint, justo al lado de su firma clásica ECDSA. Esto es notable, porque ninguna superficie comparable se ha movido: DNSSEC está en 0% post-quantum y el handshake TLS apenas está empezando. El giro está en la otra mitad del diseño. La capa de witnesses, el mecanismo que se supone debe detectar a un log mintiendo sobre su propia historia, está apenas desplegada: solo 11 de 70 logs llevan alguna cosignature de witness, vimos solo 6 witnesses distintos en todo el ecosistema, y 0 de ellos son post-quantum. La firma va muy por delante de la vigilancia.

Qué medimos, y por qué un checkpoint es legible

Certificate transparency se está moviendo del viejo protocolo request-response de RFC 6962 hacia el formato static-ct-api, donde un log es solo un conjunto de archivos estáticos en un CDN. Let's Encrypt cerró sus logs clásicos el 28 de febrero de 2026 (su plan de fin de vida tiene el cronograma), y el modelo en tiles ya es el estándar. El pequeño archivo que resume el estado actual de un log estático es su checkpoint: el nombre del log, el tamaño de su árbol, el hash de su raíz Merkle, y luego un bloque de firmas. Es público por diseño, porque monitores de todo el mundo lo obtienen constantemente para mantener honesto al log. Leerlo no toca nada privado ni sondea ningún host; es el mismo GET que realiza un monitor, y es el equivalente en CT de leer un registro DNS público.

Tomamos la lista pública de CT logs, extrajimos cada log en tiles, y obtuvimos el checkpoint de cada uno exactamente una vez. Los 70 respondieron. Luego analizamos el bloque de firmas. En el formato signed-note que usa un checkpoint, cada firma es su propia línea: un marcador de guion, luego el nombre del firmante, y luego un valor base64 que es una pista de clave de cuatro bytes seguida de la firma misma. Ese último detalle es todo el método: la longitud en bytes de la firma indica su algoritmo. Una firma Ed25519 tiene 64 bytes. La firma legacy de tree-head de RFC 6962 es un timestamp más un blob ECDSA corto. Y una firma ML-DSA-44 tiene 2,420 bytes, el tamaño fijo definido por NIST FIPS 204. Así que no tuvimos que confiar en una etiqueta; contamos bytes.

Post-quantum ya está en el 43% de los logs static-CT

Aquí está toda la población, clasificada según lo que realmente aparece en cada checkpoint. Un solo checkpoint suele llevar más de una línea de firma, así que estos son conteos de logs, no de firmas.

La segunda fila es el titular. Treinta logs no solo firman su checkpoint con una clave clásica; añaden encima una firma ML-DSA-44 completa de 2,420 bytes, de modo que cada checkpoint queda firmado de ambas formas. Esto es exactamente lo que pide la especificación de checkpoint. En sus propias palabras, los logs deberían usar cosignatures ML-DSA-44 para firmar el checkpoint, y el formato de cosignature define un tipo post-quantum dedicado, descrito como seguro frente a computadoras cuánticas, situado justo al lado del clásico. Una tasa de adopción del 43% para un debería que la mayoría de operadores podría ignorar es un movimiento rápido. Y está concentrado: las firmas post-quantum se agrupan en una minoría de operadores que gestionan grandes familias de logs de shards temporales, así que la decisión de unos pocos equipos ya cubre casi la mitad de la población. Reportamos el agregado en lugar de una lista de nombrar y avergonzar, porque firmar con más criptografía es algo bueno, no un hallazgo en contra de nadie.

La razón por la que esta capa puede avanzar mientras otras no pueden es el tamaño. Una firma ML-DSA-44 es aproximadamente 38 veces el tamaño de una ECDSA, razón por la cual no cabe en un paquete DNS y por la que el handshake TLS es cauteloso con ella. Pero un checkpoint es un archivo diminuto obtenido por unos pocos miles de monitores, no un campo enviado en miles de millones de handshakes. La capa de transparency tiene el presupuesto de bytes para ir post-quantum primero, y lo está gastando.

La capa de witnesses es la historia opuesta

Firmar un checkpoint demuestra que el log hizo una declaración. No demuestra que el log hizo la misma declaración a todos. Un log comprometido puede montar un ataque de split-view: mostrar a las víctimas un árbol que contiene un certificado fraudulento, y mostrar a los monitores un árbol limpio que no lo contiene, de modo que el fraude nunca aparezca donde alguien esté auditando. La solución es el witnessing. Un witness es un servicio independiente que recuerda el último checkpoint que vio de un log, verifica que cada nuevo checkpoint es una extensión consistente y de solo apéndice, y solo entonces devuelve una cosignature. Exige suficientes witnesses independientes en un checkpoint y un log ya no puede mantener dos historias, porque ningún witness honesto cofirmará ambas.

Ese es el mecanismo que convierte a un log de confía-en-mí en no-puede-mentir. En el ecosistema en vivo, es escaso:

• Solo 11 de 70 logs (16%) llevan alguna cosignature de witness, y cada uno de esos logs pertenece a la familia de logs de un solo operador. Los checkpoints de cualquier otro operador están firmados únicamente por el log, sin que ninguna parte independiente atestigüe la consistencia.
• Solo aparecen 6 witnesses distintos en todo el ecosistema, y solo 2 de ellos parecen ser servicios de producción. Los otros cuatro se identifican como witnesses de staging, desarrollo o prueba de concepto.
• Cada cosignature de witness es Ed25519 clásico. Ni un solo witness usa el tipo de cosignature post-quantum ML-DSA-44 que la misma especificación define. La capa anti-equivocación está en 0% post-quantum.

Donde el witnessing sí funciona, funciona bien: las cosignatures que vimos llevaban timestamps con una mediana de unos 5 segundos por detrás de nuestra obtención, así que los witnesses cofirman casi en tiempo real. El problema no es la latencia, es la cobertura. Una defensa contra split-view que cubre a un operador y tiene dos participantes de producción es un piloto prometedor, todavía no una garantía de ecosistema.

Dos apuestas distintas sobre el futuro de transparency

Pon las dos capas una al lado de la otra y surge un patrón más interesante que cualquiera de los dos números por separado. Los logs que han pasado a post-quantum y los logs que llevan cosignatures de witness son conjuntos disjuntos, gestionados por operadores distintos. Un bando está invirtiendo su esfuerzo en firmas de log post-quantum y no entrega witnessing. El otro bando está invirtiendo su esfuerzo en la red de witnesses y no entrega firma post-quantum. Nadie en este censo hace ambas cosas.

Esa división merece nombrarse porque las dos inversiones defienden contra amenazas distintas, y la amenaza más difícil es la que se está perdiendo. La firma post-quantum defiende el escenario de futuro lejano en el que una computadora cuántica falsifica la firma de un log. El witnessing defiende el escenario en tiempo presente en el que un log equivoca hoy. El ecosistema ha adelantado colectivamente la amenaza especulativa y ha subinvertido en la concreta. Post-quantum es la mejora visible y demostrable; el witnessing requiere que otras personas operen infraestructura y que los clientes exijan un quórum, lo cual es organizativamente más difícil. Así que la mitad fácil se entregó primero.

Las firmas señuelo, y por qué son una buena señal

Un hallazgo incidental dice algo saludable sobre el ecosistema. En 46 de los 70 logs (66%), el checkpoint lleva una línea de firma bajo el nombre grease.invalid, cuyos bytes son aleatorios y no verifican contra nada. Esto no está en la especificación, así que lo reportamos como observación, no como regla. Pero encaja exactamente con el requisito documentado de que un verificador debe ignorar firmas de claves que no reconoce. Esa regla es lo que hace seguro que un log añada cosignatures de witness o una nueva clave post-quantum sin romper clientes antiguos. Emitir una firma deliberadamente inválida, al estilo de la técnica GREASE de TLS, obliga a cada parser a honrar realmente esa regla de debe-ignorar en lugar de atragantarse con la primera línea desconocida. Que dos tercios de los logs pongan a prueba a sus propios consumidores es señal de un ecosistema que espera que el bloque de firmas siga creciendo, que es precisamente lo que necesita una transición post-quantum.

Cómo lo medimos, para que un escéptico pueda confiar en los números

El conjunto de datos es nuestro, construido solo a partir de archivos públicos, y reportado en agregado. No escaneamos, sondeamos, enviamos a, ni nos conectamos a ningún log más allá de obtener el único archivo de checkpoint público que cada uno publica exactamente para este propósito. No existen datos privados en un checkpoint; es un tamaño de árbol, un hash y firmas. No nombramos a ningún operador como deficiente, porque ninguno lo es: esto es una instantánea de un ecosistema en plena actualización.

• La población. Cada log en tiles de la lista pública de CT logs, 70 en total. Los 70 devolvieron un checkpoint parseable en la fecha de medición. Muchos son shards temporales, así que el conteo de logs es mayor que el conteo de operadores.
• La clasificación. Para cada línea de firma decodificamos el base64, descartamos la pista de clave de cuatro bytes, y leímos la longitud restante. 2,420 bytes (en un sobre con timestamp) es una firma ML-DSA-44 según FIPS 204; 64 es Ed25519; el blob corto con timestamp es la firma de tree-head de RFC 6962. Algoritmo por construcción, no por etiqueta.
• Log versus witness. Una firma cuyo nombre coincide con el origen propio del log es el log firmándose a sí mismo. Una cosignature bajo una identidad de witness separada es una atestación independiente. Los contamos por separado, razón por la cual el conteo post-quantum y el conteo de witnesses describen capas distintas.
• Post-quantum por tamaño. Los 30 logs post-quantum llevan cada uno una firma exactamente de la longitud ML-DSA-44, en el sobre de cosignature que define la especificación para ello. Un esquema clásico no puede producir accidentalmente una firma de 2,420 bytes, así que el conteo no es una estimación.

Por qué esto importa, y los límites honestos

Certificate transparency es un fundamento sobre el que se apoyan otras defensas. Es cómo el mundo detecta un certificado mal emitido para un banco o un proveedor de correo, y respalda controles como las garantías que puedes leer directamente de un certificado y restricciones de emisión como CAA. Al igual que DNSSEC, CT firma en lugar de cifrar, así que el riesgo cuántico es la falsificación futura, no el harvest-now-decrypt-later. Eso significa que el resultado del 43% post-quantum va genuinamente por delante de la amenaza, lo cual es una buena noticia y algo poco común. Pero la otra cara es la parte que debería recibir más atención: el mecanismo que hace confiable a un log frente a un atacante actual, no cuántico, el witnessing independiente, es el que está escaso y es clásico. Si estás apostando por transparency para detectar la próxima mala emisión, la red de witnesses es el número a vigilar, no el algoritmo de firma.

Un resultado sin sus límites es marketing, así que aquí están los límites.

• Una lista, un día. Esto es la lista pública de logs en una sola fecha. Se añaden y rotan shards, y el witnessing se está desplegando activamente, así que los conteos exactos cambiarán. El hallazgo estructural, que la firma ha superado al witnessing, es la parte duradera.
• Solo checkpoints servidos. Leímos lo que cada log sirve en su propio endpoint de checkpoint. Un witness que cofirma un log pero distribuye sus cosignatures en otro lugar no aparecería aquí, así que la cantidad real de actividad de witnessing es un piso, no un techo. El punto se mantiene: los checkpoints que los clientes realmente obtienen están mayormente sin witness.
• Presencia, no verificación. Clasificamos las firmas por algoritmo e identidad, no verificando criptográficamente cada una contra su clave. Una firma ML-DSA-44 presente del tamaño correcto es evidencia sólida de firma post-quantum; confirmar que cada firma valida es un ejercicio aparte.
• La línea GREASE es inferida. El señuelo grease.invalid es nuestra lectura de un comportamiento no documentado pero consistente, no una característica exigida por la especificación.

Preguntas frecuentes

¿Qué es un static CT log?

Un static CT log es un log de certificate transparency servido como archivos estáticos, llamados tiles, desde almacenamiento de objetos o un CDN, siguiendo la especificación C2SP static-ct-api. En lugar de la API request-response de RFC 6962, publica tiles de solo apéndice de 256 entradas más un pequeño checkpoint firmado que indica el tamaño actual del árbol y el hash de la raíz. Los monitores leen los archivos directamente, lo que hace que operar y replicar logs sea barato. Este diseño, llamado originalmente Sunlight API, se volvió estándar entre los operadores de CT en 2025 y 2026.

¿Los logs de certificate transparency ya son post-quantum?

En parte, y antes de lo que la mayoría asume. En nuestro censo de los 70 logs static-CT, 30 de ellos (43%) ya adjuntan una firma ML-DSA-44 a cada checkpoint, junto a su firma clásica. ML-DSA-44 es el esquema de retícula de FIPS 204 que resiste ataques cuánticos, y es lo que recomienda la especificación de checkpoint. Así que la capa de firma de logs está bien avanzada en su migración post-quantum. La capa de witnesses que cofirma esos checkpoints sigue en 0% post-quantum; toda cosignature de witness que vimos fue Ed25519 clásico.

¿Qué es ML-DSA-44 y por qué se usa aquí?

ML-DSA-44 es el conjunto de parámetros más pequeño de ML-DSA, el estándar de firma de retícula modular en NIST FIPS 204, derivado de CRYSTALS-Dilithium. Sus firmas tienen 2,420 bytes y sus claves 1,312 bytes, mucho más grandes que una firma Ed25519 de 64 bytes, pero no lo rompe el algoritmo de Shor. Certificate transparency puede absorber el tamaño porque un checkpoint es obtenido ocasionalmente por monitores, no enviado en cada handshake, razón por la cual CT puede adoptar firmas post-quantum años antes que DNSSEC o el handshake TLS.

¿Qué es un witness de CT y una cosignature de witness?

Un witness es un servicio independiente, identificado por un nombre y una clave pública, que observa los checkpoints de un log. Antes de cofirmar un nuevo checkpoint verifica que el nuevo árbol es consistente con el último que vio, es decir, que el log solo añadió y nunca reescribió la historia, y luego devuelve una cosignature con timestamp definida por las especificaciones C2SP tlog-witness y tlog-cosignature. Un checkpoint que lleva cosignatures de varios witnesses independientes es mucho más difícil de falsificar para un log comprometido.

¿Cómo previene una cosignature de witness un split view?

Un ataque de split-view es un log que muestra un árbol a las víctimas y un árbol distinto y honesto a los monitores, de modo que los certificados fraudulentos nunca aparecen donde alguien audita. Como un witness solo cofirma después de comprobar la consistencia con la historia que ya tiene, un log no puede conseguir que el mismo witness honesto cofirme dos checkpoints contradictorios. Si los clientes exigen cosignatures de un quórum de witnesses independientes, el log tiene que mostrar a todos el mismo árbol de solo apéndice, lo que cierra la brecha que deja abierta el logging simple.

¿Cuándo se cerraron los logs de certificate transparency de RFC 6962?

La migración se extendió durante 2025 y 2026. Let's Encrypt anunció el fin de vida de sus logs RFC 6962 en agosto de 2025, los pasó a solo lectura el 30 de noviembre de 2025, y los cerró por completo el 28 de febrero de 2026, en favor de sus logs estáticos Sycamore y Willow. Chrome añadió soporte para static-ct-api a inicios de 2025 y está eliminando gradualmente el requisito de que al menos un SCT provenga de un log RFC 6962 antiguo.

¿Cuántos logs de certificate transparency hay en 2026?

La lista pública de CT logs que usamos contiene 70 logs estáticos en tiles repartidos entre un puñado de operadores, además de los logs clásicos restantes. Muchos de los 70 son shards temporales, cada uno cubriendo un rango de fechas de expiración de certificados, así que un solo operador gestiona varios a la vez. Los 70 logs estáticos sirvieron un checkpoint legible cuando los medimos.

Lecturas relacionadas

• DNSSEC post-quantum readiness: 0% de los 30,000 dominios principales. La misma pregunta post-quantum en una superficie que todavía no puede moverse, porque las firmas no caben en un paquete DNS.
• ¿FIPS deshabilita TLS post-quantum? La transición post-quantum medida en el handshake TLS en lugar de en la capa de transparency.
• Lo que prueban los certificados. Leer garantías criptográficas directamente de registros públicos en lugar de confiar en la etiqueta, el mismo método aplicado a los certificados mismos.
• ¿Cuántos dominios principales restringen la emisión de certificados? El ecosistema de certificados medido pasivamente a partir de datos públicos.