2026-08-18 · INVESTIGAÇÃO · A equipa da Offensive Technology

Certificate transparency pós-quântico: 43% dos static-CT logs já assinam com ML-DSA-44

O certificate transparency começou discretamente a sua migração pós-quântica, e já está a 43% do caminho na camada de assinatura dos logs. Recolhemos o ficheiro checkpoint público de cada um dos 70 static-CT logs na lista pública de logs, e 30 deles (42,9%) anexam uma assinatura pós-quântica ML-DSA-44 a cada checkpoint, mesmo ao lado da sua assinatura clássica ECDSA. Isto é notável, porque nenhuma superfície comparável se moveu: o DNSSEC está a 0% pós-quântico e o handshake TLS está apenas a começar. A reviravolta é a outra metade do design. A camada de witness, o mecanismo suposto de apanhar um log a mentir sobre a sua própria história, está pouco implementada: apenas 11 dos 70 logs têm alguma cosignature de witness, vimos apenas 6 witnesses distintos em todo o ecossistema, e 0 deles são pós-quânticos. A assinatura está a avançar mais depressa do que a vigilância.

O que medimos, e porque um checkpoint é legível

O certificate transparency está a migrar do antigo protocolo de pedido-resposta RFC 6962 para o formato static-ct-api, onde um log é apenas um conjunto de ficheiros estáticos numa CDN. A Let's Encrypt encerrou os seus logs clássicos a 28 de fevereiro de 2026 (o seu plano de fim de vida tem o calendário), e o modelo em tiles é agora o mainstream. O pequeno ficheiro que resume o estado atual de um log estático é o seu checkpoint: o nome do log, o tamanho da sua árvore, o hash da raiz Merkle, e depois um bloco de assinaturas. É público por design, porque monitores em todo o mundo o recolhem constantemente para manter o log honesto. Lê-lo não toca em nada privado nem sonda nenhum host; é o mesmo GET que um monitor executa, e é o equivalente em CT a ler um registo DNS público.

Recolhemos a lista de CT logs publicada, extraímos todos os logs em tiles, e recolhemos o checkpoint de cada um exatamente uma vez. Todos os 70 responderam. Depois analisámos o bloco de assinaturas. No formato signed-note que um checkpoint usa, cada assinatura é a sua própria linha: um marcador de traço, depois o nome do assinante, depois um valor base64 que é uma dica de chave de quatro bytes seguida da própria assinatura. Esse último detalhe é todo o método: o comprimento em bytes da assinatura indica o seu algoritmo. Uma assinatura Ed25519 tem 64 bytes. A assinatura legada de tree-head do RFC 6962 é um timestamp mais um pequeno blob ECDSA. E uma assinatura ML-DSA-44 tem 2.420 bytes, o tamanho fixo definido pela NIST FIPS 204. Portanto não tivemos de confiar num rótulo; contámos bytes.

O pós-quântico já está em 43% dos static-CT logs

Eis a população completa, classificada pelo que realmente aparece em cada checkpoint. Um único checkpoint costuma ter mais do que uma linha de assinatura, por isso estas são contagens de logs, não de assinaturas.

A segunda linha é a manchete. Trinta logs não se limitam a assinar o seu checkpoint com uma chave clássica; acrescentam uma assinatura ML-DSA-44 completa de 2.420 bytes por cima, pelo que cada checkpoint fica assinado das duas formas. É exatamente o que a especificação do checkpoint pede. Nas suas próprias palavras, os logs devem usar cosignatures ML-DSA-44 para assinar o checkpoint, e o formato de cosignature define um tipo pós-quântico dedicado, descrito como seguro contra computadores quânticos, mesmo ao lado do clássico. Uma taxa de adoção de 43% para um devem que a maioria dos operadores poderia ignorar é um avanço rápido. E está concentrado: as assinaturas pós-quânticas concentram-se numa minoria de operadores que gerem grandes famílias de logs de shards temporais, pelo que a decisão de algumas equipas já cobre quase metade da população. Reportamos o agregado em vez de uma lista de nomes e vergonha, porque assinar com mais criptografia é uma coisa boa, não uma falha contra ninguém.

A razão pela qual esta camada consegue avançar enquanto outras não conseguem é o tamanho. Uma assinatura ML-DSA-44 tem aproximadamente 38 vezes o tamanho de uma ECDSA, razão pela qual não cabe num pacote DNS e pela qual o handshake TLS é cauteloso com ela. Mas um checkpoint é um ficheiro minúsculo recolhido por alguns milhares de monitores, não um campo enviado em milhares de milhões de handshakes. A camada de transparência tem o orçamento de bytes para avançar primeiro para o pós-quântico, e está a gastá-lo.

A camada de witness é a história oposta

Assinar um checkpoint prova que o log fez uma declaração. Não prova que o log fez a mesma declaração a todos. Um log comprometido pode montar um ataque de split-view: mostrar às vítimas uma árvore que contém um certificado fraudulento, e mostrar aos monitores uma árvore limpa que não o contém, de forma a que a fraude nunca apareça onde alguém está a auditar. A correção é a vigilância por witness. Um witness é um serviço independente que memoriza o último checkpoint que viu de um log, verifica se cada novo checkpoint é uma extensão consistente e apenas de acréscimo, e só então devolve uma cosignature. Exija-se witnesses independentes suficientes num checkpoint e um log deixa de conseguir manter duas histórias, porque nenhum witness honesto vai co-assinar ambas.

É esse o mecanismo que transforma um log de confia-em-mim em não-pode-mentir. No ecossistema em produção, é ténue:

• Apenas 11 dos 70 logs (16%) têm alguma cosignature de witness, e cada um desses logs pertence à família de logs de um único operador. Os checkpoints de todos os outros operadores são assinados apenas pelo log, sem nenhuma parte independente a atestar a consistência.
• Apenas 6 witnesses distintos aparecem em todo o ecossistema, e apenas 2 deles parecem serviços em produção. Os outros quatro identificam-se como witnesses de staging, dev, ou prova de conceito.
• Todas as cosignatures de witness são Ed25519 clássico. Nenhum witness usa o tipo de cosignature pós-quântica ML-DSA-44 que a mesma especificação define. A camada anti-equivocação está a 0% pós-quântico.

Onde a vigilância por witness funciona, funciona bem: as cosignatures que vimos tinham timestamps com uma mediana de cerca de 5 segundos atrás da nossa recolha, pelo que os witnesses estão a co-assinar quase em tempo real. O problema não é a latência, é a cobertura. Uma defesa contra split-view que cobre um operador e tem dois participantes em produção é um piloto promissor, ainda não uma garantia de ecossistema.

Duas apostas diferentes no futuro da transparência

Coloque as duas camadas lado a lado e surge um padrão mais interessante do que qualquer um dos números isolados. Os logs que já avançaram para o pós-quântico e os logs que têm cosignatures de witness são conjuntos disjuntos, geridos por operadores diferentes. Um grupo está a investir o seu esforço nas assinaturas de log pós-quânticas e não implementa vigilância por witness. O outro grupo está a investir o seu esforço na rede de witnesses e não implementa assinatura pós-quântica. Ninguém neste levantamento faz ambas as coisas.

Essa divisão vale a pena nomear porque os dois investimentos defendem contra ameaças diferentes, e a ameaça mais difícil é a que se está a perder. A assinatura pós-quântica defende o cenário de futuro distante em que um computador quântico forja a assinatura de um log. A vigilância por witness defende o cenário de presente em que um log se equivoca hoje. O ecossistema, coletivamente, antecipou o investimento na ameaça especulativa e subinvestiu na concreta. O pós-quântico é a atualização visível e demonstrável; a vigilância por witness exige que outras pessoas mantenham infraestrutura e que os clientes exijam um quórum, o que é organizacionalmente mais difícil. Por isso a metade fácil foi lançada primeiro.

As assinaturas-isco, e porque são um bom sinal

Uma descoberta incidental diz algo saudável sobre o ecossistema. Em 46 dos 70 logs (66%), o checkpoint tem uma linha de assinatura sob o nome grease.invalid, cujos bytes são aleatórios e não verificam contra nada. Isto não consta da especificação, por isso reportamo-lo como uma observação, não como uma regra. Mas alinha-se exatamente com o requisito documentado de que um verificador deve ignorar assinaturas de chaves que não reconhece. Essa regra é o que torna seguro para um log acrescentar cosignatures de witness ou uma nova chave pós-quântica sem quebrar clientes antigos. Emitir uma assinatura deliberadamente inválida, ao estilo da técnica GREASE do TLS, obriga cada parser a respeitar de facto essa regra de deve-ignorar em vez de falhar na primeira linha desconhecida. Dois terços dos logs a testar sob stress os seus próprios consumidores é um sinal de um ecossistema que espera que o bloco de assinaturas continue a crescer, que é precisamente o que uma transição pós-quântica exige.

Como o medimos, para que um cético possa confiar nos números

O conjunto de dados é nosso, construído apenas a partir de ficheiros públicos, e reportado de forma agregada. Não fizemos scan, sondagem, submissão, nem ligação a nenhum log para além de recolher o único ficheiro de checkpoint público que cada um publica exatamente para este fim. Não existe nenhum dado privado num checkpoint; é um tamanho de árvore, um hash, e assinaturas. Não identificamos nenhum operador como deficiente, porque nenhum o é: isto é uma fotografia de um ecossistema a meio de uma atualização.

• A população. Todos os logs em tiles da lista pública de CT logs, 70 no total. Todos os 70 devolveram um checkpoint analisável na data da medição. Muitos são shards temporais, pelo que a contagem de logs é maior do que a contagem de operadores.
• A classificação. Para cada linha de assinatura descodificámos o base64, descartámos a dica de chave de quatro bytes, e lemos o comprimento restante. 2.420 bytes (num invólucro com timestamp) é uma assinatura ML-DSA-44 pela FIPS 204; 64 é Ed25519; o pequeno blob com timestamp é a assinatura de tree-head do RFC 6962. Algoritmo por construção, não por rótulo.
• Log versus witness. Uma assinatura cujo nome corresponde à própria origem do log é o log a assinar-se a si próprio. Uma cosignature sob uma identidade de witness separada é uma atestação independente. Contámo-las separadamente, razão pela qual a contagem pós-quântica e a contagem de witnesses descrevem camadas diferentes.
• Pós-quântico por tamanho. Os 30 logs pós-quânticos têm cada um uma assinatura exatamente do comprimento ML-DSA-44, no invólucro de cosignature que a especificação define para o efeito. Um esquema clássico não pode produzir acidentalmente uma assinatura de 2.420 bytes, pelo que a contagem não é uma estimativa.

Porque é que isto importa, e os limites honestos

O certificate transparency é uma fundação sobre a qual assentam outras defesas. É como o mundo repara num certificado mal emitido para um banco ou um fornecedor de mail, e sustenta controlos como as garantias que se conseguem ler num certificado e restrições de emissão como o CAA. Tal como o DNSSEC, o CT assina em vez de encriptar, pelo que o risco quântico é a forja futura, não o harvest-now-decrypt-later. Isso significa que o resultado de 43% pós-quântico está genuinamente à frente da ameaça, o que são boas notícias e raras. Mas o reverso da moeda é a parte que devia receber mais atenção: o mecanismo que torna um log fiável contra um atacante atual, não quântico, a vigilância independente por witness, é o que está ténue e clássico. Se está a apostar na transparência para apanhar a próxima má emissão, a rede de witnesses é o número a observar, não o algoritmo de assinatura.

Um resultado sem os seus limites é marketing, por isso aqui estão as fronteiras.

• Uma lista, um dia. Isto é a lista pública de logs numa única data. Os shards são adicionados e rodados, e a vigilância por witness está a ser ativamente implementada, pelo que as contagens exatas vão mudar. A descoberta estrutural, de que a assinatura ultrapassou a vigilância, é a parte duradoura.
• Apenas checkpoints servidos. Lemos o que cada log serve no seu próprio endpoint de checkpoint. Um witness que co-assina um log mas distribui as suas cosignatures noutro lugar não apareceria aqui, pelo que a quantidade real de atividade de vigilância por witness é um mínimo, não um máximo. O ponto mantém-se: os checkpoints que os clientes realmente recolhem estão maioritariamente sem vigilância.
• Presença, não verificação. Classificámos as assinaturas por algoritmo e identidade, não por verificação criptográfica de cada uma contra a sua chave. Uma assinatura ML-DSA-44 presente e do tamanho correto é forte evidência de assinatura pós-quântica; confirmar que cada assinatura valida é um exercício separado.
• A linha do GREASE é inferida. O grease.invalid isco é a nossa leitura de um comportamento não documentado mas consistente, não uma funcionalidade exigida pela especificação.

Perguntas frequentes

O que é um static CT log?

Um static CT log é um log de certificate transparency servido como ficheiros estáticos, chamados tiles, a partir de armazenamento de objetos ou de uma CDN, seguindo a especificação C2SP static-ct-api. Em vez da API de pedido-resposta do RFC 6962, publica tiles apenas de acréscimo com 256 entradas cada, mais um pequeno checkpoint assinado que indica o tamanho atual da árvore e o hash da raiz. Os monitores leem os ficheiros diretamente, o que torna os logs baratos de gerir e replicar. Este design, inicialmente chamado Sunlight API, tornou-se mainstream entre os operadores de CT em 2025 e 2026.

Os logs de certificate transparency já são pós-quânticos?

Em parte, e mais cedo do que a maioria assume. No nosso levantamento de todos os 70 static-CT logs, 30 deles (43%) já anexam uma assinatura ML-DSA-44 a cada checkpoint, ao lado da sua assinatura clássica. O ML-DSA-44 é o esquema em retículo (lattice) da FIPS 204 que resiste a ataques quânticos, e é o que a especificação do checkpoint recomenda. Portanto a camada de assinatura de logs está bem avançada na sua migração pós-quântica. A camada de witness que co-assina esses checkpoints continua a 0% pós-quântico; todas as cosignatures de witness que vimos eram Ed25519 clássico.

O que é o ML-DSA-44 e porque é usado aqui?

O ML-DSA-44 é o conjunto de parâmetros mais pequeno do ML-DSA, o padrão de assinatura em retículo modular da NIST FIPS 204, derivado do CRYSTALS-Dilithium. As suas assinaturas têm 2.420 bytes e as suas chaves 1.312 bytes, muito maiores do que uma assinatura Ed25519 de 64 bytes, mas não é quebrado pelo algoritmo de Shor. O certificate transparency consegue absorver o tamanho porque um checkpoint é recolhido ocasionalmente por monitores, não enviado em cada handshake, razão pela qual o CT consegue adotar assinaturas pós-quânticas anos antes do DNSSEC ou do handshake TLS.

O que é um witness de CT e uma cosignature de witness?

Um witness é um serviço independente, identificado por um nome e uma chave pública, que vigia os checkpoints de um log. Antes de co-assinar um novo checkpoint, verifica se a nova árvore é consistente com a última que viu, ou seja, que o log apenas acrescentou e nunca reescreveu história, e só depois devolve uma cosignature com timestamp, definida pelas especificações C2SP tlog-witness e tlog-cosignature. Um checkpoint com cosignatures de vários witnesses independentes é muito mais difícil de falsificar por um log comprometido.

Como é que uma cosignature de witness previne um split view?

Um ataque de split-view é um log mostrar uma árvore às vítimas e uma árvore diferente e honesta aos monitores, de forma a que os certificados fraudulentos nunca apareçam onde alguém audita. Como um witness só co-assina depois de verificar a consistência com a história que já detém, um log não consegue ter dois checkpoints contraditórios co-assinados pelo mesmo witness honesto. Se os clientes exigirem cosignatures de um quórum de witnesses independentes, o log tem de mostrar a todos a mesma árvore apenas de acréscimo, o que fecha a brecha que o logging simples deixa aberta.

Quando é que os logs de certificate transparency do RFC 6962 foram encerrados?

A migração decorreu ao longo de 2025 e 2026. A Let's Encrypt anunciou o fim de vida dos seus logs RFC 6962 em agosto de 2025, passou-os a apenas leitura a 30 de novembro de 2025, e encerrou-os completamente a 28 de fevereiro de 2026, em favor dos seus logs estáticos Sycamore e Willow. O Chrome adicionou suporte para static-ct-api no início de 2025 e está a eliminar progressivamente o requisito de que pelo menos um SCT venha de um antigo log RFC 6962.

Quantos logs de certificate transparency existem em 2026?

A lista pública de CT logs que usámos contém 70 logs estáticos em tiles espalhados por um punhado de operadores, mais os restantes logs clássicos. Muitos dos 70 são shards temporais, cada um cobrindo um intervalo de datas de expiração de certificados, pelo que um operador gere vários em simultâneo. Todos os 70 logs estáticos serviram um checkpoint legível quando os medimos.

Leitura relacionada

• DNSSEC: preparação pós-quântica de 0% dos 30.000 domínios de topo. A mesma questão pós-quântica numa superfície que ainda não consegue avançar, porque as assinaturas não cabem num pacote DNS.
• O FIPS desativa o TLS pós-quântico? A transição pós-quântica medida no handshake TLS em vez da camada de transparência.
• O que os certificados provam. Ler garantias criptográficas a partir de registos públicos em vez de confiar no rótulo, o mesmo método aplicado aos próprios certificados.
• Quantos domínios de topo restringem a emissão de certificados? O ecossistema de certificados medido de forma passiva a partir de dados públicos.