Let’s Encrypt acelera transição pós-quântica da web com Merkle Tree Certificates

A Let’s Encrypt anunciou que esta avancando com o trabalho para emitir certificados pos-quanticos em escala web, usando uma abordagem chamada Merkle Tree Certificates (MTCs). O objetivo e oferecer autenticacao resistente a computadores quanticos para o ecossistema TLS sem sacrificar a velocidade e a confiabilidade que tornaram a tecnologia universal. A autoridade certificadora planeja um ambiente de staging para emissao de MTCs ainda em 2026, com producao prevista para 2027.

O que aconteceu

Andrew Gabbitas, engenheiro de software da Let’s Encrypt, explicou em comunicado oficial que a discussao sobre criptografia pos-quantica vinha sendo dominada por preocupacoes com criptografia de transporte, dado o cenario “harvest now, decrypt later” – atacantes que armazenam trafego cifrado hoje para descriptografar quando computadores quanticos estiverem disponiveis. A autenticacao, parte do TLS que verifica a identidade de um servidor, recebeu menos atencao, mas e justamente onde a Let’s Encrypt esta mirando agora.

A migracao envolve atualizar emissao de certificados, ACME, sistemas de revogacao, ferramentas operacionais e a infraestrutura de transparencia que os MTCs incorporam. A Let’s Encrypt esta participando dos grupos de trabalho IETF PLANTS e ACME enquanto os padroes evoluem, e acompanhando padronizacao de assinaturas ML-DSA em X.509 e TLS, alem de mudancas como o suporte a ML-DSA na biblioteca padrao do Go.

Por que MTCs e nao apenas ML-DSA-X.509

O grande desafio tecnico da autenticacao pos-quantica e o tamanho. Um handshake TLS tipico carrega cinco assinaturas e duas chaves publicas. Com algoritmos classicos como ECDSA P-256, esses elementos ocupam centenas de bytes. Com ML-DSA – o esquema padronizado pelo NIST – cada assinatura pode ultrapassar 2KB e cada chave publica passa de 1KB. Multiplicado por handshake, isso significa inflar o trafego inicial de TLS em ordens de magnitude, com impacto direto em latencia, mobile, IoT e ate em ataques de amplificacao.

Os Merkle Tree Certificates atacam o problema por outro angulo: em vez de carregar uma cadeia completa de certificados em cada handshake, o servidor envia uma evidencia compacta de inclusao em uma arvore Merkle publica, transparente e auditavel. O cliente verifica que o certificado faz parte de um conjunto conhecido sem precisar processar cada certificado intermediario. Isso resolve o problema de tamanho e abre espaco para emissao com algoritmos pos-quanticos sem destruir a performance.

“A web PKI nao deve adiar a autenticacao pos-quantica. Chaves de longa duracao – como raizes de CA, chaves de assinatura de codigo e sistemas de identidade – continuam sendo alvos valiosos.”

Andrew Gabbitas, Let’s Encrypt

O cenario regulatorio que esta pressionando o calendario

A migracao para criptografia pos-quantica deixou de ser exercicio academico e virou agenda regulatoria. A NSA, atraves da CNSA 2.0, exige que sistemas de seguranca nacional dos EUA migrem entre 2030 e 2035. O NIST publicou guidance preliminar para depreciar RSA-2048 e P-256 apos 2030 e prolibilos apos 2035. A Uniao Europeia tem como meta sistemas de alto risco em 2030 e migracao ampla ate 2035. Esses prazos definem o cronograma para autoridades certificadoras, fabricantes de navegadores e operadores de infraestrutura.

Em 2026, Google anunciou planos para migrar seus servicos ate 2029, com a Cloudflare assumindo compromisso similar. O Go 1.27 adicionou ML-DSA a sua biblioteca padrao. O movimento se acelera porque, embora um computador quantico criptograficamente relevante (CRQC) ainda nao exista, a janela entre seu surgimento e a substituicao de toda a Web PKI e muito maior do que parece – e raizes de CA emitidas hoje podem ter validade de 25 anos ou mais.

Quem e afetado

• Operadores de servicos publicos em HTTPS – de gigantes da web a pequenos servidores corporativos – precisarao validar suporte a MTCs em clientes e servidores nos proximos 2-3 anos.
• Fabricantes de browsers (Chromium, Firefox, Safari) devem implementar codigo de verificacao de MTC, em coordenacao com a IETF.
• Empresas que dependem de TLS Mutual Authentication em VPNs corporativas e APIs interno-externas devem revisar suas politicas de PKI privada.
• Times de DevOps e SRE precisarao testar emissao automatizada via ACME em ambientes de staging para validar latencia de handshake.
• Fornecedores de HSMs e CAs privadas terao que adicionar suporte a ML-DSA e a primitivas pos-quanticas como ML-KEM.

Analise

A Let’s Encrypt esta executando um dos movimentos mais interessantes da transicao pos-quantica. Ao escolher MTCs, ela ataca o problema real (tamanho) com uma solucao que ja tem precedente operacional – Certificate Transparency, lancada pelo Google em 2013, demonstrou que a indústria consegue operar arvores Merkle publicas em escala global. Os MTCs sao, em essencia, a generalizacao desse modelo para conter chave publica e assinatura, nao apenas para auditoria.

Vale comparar com a aposta alternativa do mercado, que e a transicao direta para certificados X.509 assinados com ML-DSA. Essa rota e mais simples de implementar – basta trocar o algoritmo – mas tem o custo de inflar handshakes em algumas centenas de bytes a alguns kilobytes por conexao. Em situacoes de latencia critica como mobile com handshake repetido, IoT, voz sobre IP e ambientes embarcados, essa carga pode ser inaceitavel. Os MTCs preservam o tamanho do handshake atual mesmo sob criptografia pos-quantica, oferecendo uma curva de migracao mais suave.

O risco e fragmentacao. Se navegadores demoram a implementar MTC enquanto outras CAs migram direto para ML-DSA-X.509, podemos ter um periodo de incompatibilidade onde sites usando MTC perdem suporte em parte do ecossistema. A coordenacao via IETF e crucial. Tambem vale lembrar que a Let’s Encrypt sozinha emite milhoes de certificados por dia – sua escolha tecnica vai forcar outros players a se posicionar.

Recomendacoes praticas

• Comece um inventario formal de tudo que sua organizacao tem em PKI: certificados publicos, raizes privadas, chaves de assinatura de codigo, identidade de dispositivos, mutual TLS em APIs internas.
• Garanta que seus clientes ACME (Certbot, lego, acme.sh) estejam em versoes ativas e monitore os roadmaps para suporte a MTCs e ML-DSA.
• Testes de regressao de TLS em CI devem incluir cenarios com handshakes maiores, simulando o overhead pos-quantico em RTTs mais lentos.
• Para times de seguranca de produto, revise dependencias criptograficas que ainda usam SHA-1, RSA-1024 ou P-192 – se sua casa ainda nao esta em ordem para o presente, nao estara para o futuro pos-quantico.
• Acompanhe os drafts da IETF dos grupos PLANTS e ACME para entender quando MTCs entrarao em browsers e bibliotecas.
• Para organizacoes em setores regulados, comece a discutir com fornecedores de HSM o cronograma de suporte a ML-DSA e ML-KEM.

Fonte: Help Net Security