TLS pós-quântico: por que seu certificado HTTPS precisa mudar
O algoritmo de Shor torna RSA e ECDSA obsoletos assim que surgir um computador quântico criptograficamente relevante. A migração para o HTTPS pós-quântico tem duas frentes, e apenas uma delas está avançando bem.
Toda conexão HTTPS depende de dois componentes de criptografia assimétrica: um acordo de chaves que deriva o segredo da sessão e uma assinatura digital que comprova que o servidor é quem afirma ser. Em princípio, ambos já podem ser quebrados pelo algoritmo de Shor executado em um computador quântico suficientemente grande. A migração para o HTTPS pós-quântico já está bem avançada no acordo de chaves, mas mal começou na autenticação. Essas duas frentes não seguem o mesmo cronograma, e entender o motivo é muito importante para quem planeja e desenvolve software todos os dias.
O que um adversário quântico realmente quebra
O handshake do TLS 1.3 combina uma troca efêmera de chaves, normalmente X25519, uma variante do Diffie–Hellman sobre curvas elípticas, com uma assinatura do servidor sobre o transcript da conexão, usando RSA, ECDSA ou Ed25519. A identidade do servidor, por sua vez, é atestada por uma cadeia de certificados X.509, que consiste em uma sequência de assinaturas terminando em uma raiz presente no repositório de confiança do cliente.
O algoritmo de Shor fatoriza números inteiros em tempo polinomial, O((\log N)^3), e resolve o problema do logaritmo discreto em curvas elípticas com a mesma complexidade assintótica. Isso compromete simultaneamente RSA, DH, ECDH, ECDSA e Ed25519. Já o algoritmo de Grover oferece apenas uma aceleração quadrática contra primitivas simétricas, de modo que AES-256 e SHA-384 continuam oferecendo uma margem confortável de segurança.
Portanto, o modelo de ameaça para o HTTPS é restrito, mas total: toda a camada assimétrica precisa ser substituída, enquanto a camada simétrica pode permanecer.
Duas migrações, não uma
Esta é a perspectiva mais importante quando se fala sobre HTTPS pós-quântico, e ela vem diretamente das equipes que estão implementando essas mudanças. Os responsáveis pela criptografia do Chrome explicaram assim:
“Um adversário poderia armazenar tráfego criptografado agora, esperar até que um CRQC se torne viável e, então, usá-lo para descriptografar esse tráfego posteriormente.” — Adrian, Beck, Benjamin, O'Brien, Advancing Our Amazing Bet on Asymmetric Cryptography, Google, maio de 2024.
Esse ataque, conhecido como harvest now, decrypt later, “coletar agora, descriptografar depois”, é o motivo pelo qual a migração do acordo de chaves não pode esperar. O tráfego criptografado é capturado hoje; o computador quântico só precisa existir em algum momento no futuro.
A autenticação tem a propriedade oposta. Uma assinatura forjada só é útil enquanto o invasor está online. Até que um computador quântico criptograficamente relevante, CRQC, exista fisicamente, ninguém conseguirá falsificar essas assinaturas. Como resumiu a Cloudflare:
“As organizações enfrentam duas migrações pós-quânticas separadas: o acordo de chaves é urgente; as assinaturas são muito mais complexas, mas menos críticas em termos de prazo.” — Westerbaan, The State of the Post-Quantum Internet, Cloudflare, março de 2024.
Por isso, o setor está implementando primeiro, e de forma agressiva, o acordo de chaves; a autenticação vem depois, com mais cautela.
Os novos componentes fundamentais
O NIST finalizou três padrões em agosto de 2024. Um quarto ainda está em fase de rascunho.
| Padrão | Algoritmo | Finalidade | Problema matemático subjacente |
|---|---|---|---|
| FIPS 203 | ML-KEM (Kyber) | Encapsulamento de chaves | Module-LWE em reticulados |
| FIPS 204 | ML-DSA (Dilithium) | Assinaturas | Module-LWE / Module-SIS |
| FIPS 205 | SLH-DSA (SPHINCS+) | Assinaturas sem estado baseadas em hash | Segurança de funções de hash |
| Rascunho | FN-DSA (Falcon) | Assinaturas compactas | Reticulados NTRU |
Em março de 2025, o NIST também selecionou o HQC como KEM de contingência baseado em códigos, criando uma alternativa caso as hipóteses de segurança dos esquemas baseados em reticulados venham a ser comprometidas.
Os tamanhos das chaves e assinaturas estão na origem de todos os problemas operacionais descritos a seguir:
| Algoritmo | Chave pública | Assinatura / texto cifrado |
|---|---|---|
| X25519 | 32 B | 32 B |
| Ed25519 | 32 B | 64 B |
| ECDSA P-256 | 64 B | ~70 B |
| RSA-2048 | 256 B | 256 B |
| ML-KEM-768 | 1.184 B | 1.088 B |
| ML-DSA-44 | 1.312 B | 2.420 B |
| SLH-DSA-128s | 32 B | 7.856 B |
| FN-DSA-512 | 897 B | 666 B |
KEMs baseados em reticulados são viáveis. Assinaturas baseadas em reticulados são pouco práticas. Assinaturas baseadas em hash são grandes. Assinaturas compactas, como Falcon, exigem aritmética de ponto flutuante durante a assinatura, o que cria uma categoria especialmente difícil de implementações em tempo constante.
O acordo híbrido de chaves já é o padrão
A implementação do acordo de chaves no TLS é híbrida: uma curva clássica e um KEM pós-quântico são executados em paralelo, e o segredo da sessão é derivado de ambos:
Se qualquer uma das duas primitivas permanecer segura, a sessão também permanece segura. O identificador padronizado é X25519MLKEM768 (0x11EC no TLS), que substitui o identificador experimental anterior X25519Kyber768Draft00 (0x6399). Essa alteração foi necessária porque o padrão final do ML-KEM é incompatível no nível do protocolo com o rascunho do Kyber no qual ele se baseava.
Os números de adoção são expressivos. Segundo o relatório da Cloudflare de 2025:
“Mais da metade do tráfego iniciado por pessoas na Cloudflare está protegida contra ataques do tipo "harvest now, decrypt later" por meio de criptografia pós-quântica.” — Westerbaan, State of the Post-Quantum Internet in 2025, Cloudflare, outubro de 2025.
O Chrome ativou por padrão o acordo híbrido de chaves com ML-KEM na versão 124 para computadores e relatou um aumento mediano de 4% na latência do handshake. Não é zero, mas é pequeno o suficiente para justificar a adoção. O ML-KEM acrescenta aproximadamente 1,1 a 1,2 kB ao ClientHello e ao ServerHello. Esse é o único custo da proteção contra ataques de coleta imediata e descriptografia futura, e o setor decidiu aceitá-lo.
A parte difícil: os certificados
Enquanto a migração do acordo de chaves está praticamente concluída, a migração dos certificados ainda não começou em produção. A aritmética explica o motivo.
Um handshake TLS moderno inclui um certificado de entidade final, um ou dois certificados intermediários, dois carimbos de data e hora assinados, SCTs, para Certificate Transparency e uma assinatura sobre o transcript do handshake. Hoje, a cadeia mediana tem cerca de 3,2 kB. Com assinaturas ML-DSA-44, em uma implementação direta:
- apenas dois SCTs e uma assinatura do certificado final acrescentam 7.260 bytes de sobrecarga de autenticação;
- uma cadeia híbrida completa, com assinaturas clássicas e pós-quânticas, eleva o tamanho total do handshake para mais de 15 kB.
Esse número importa porque existe uma queda de desempenho bem documentada:
“Alguns clientes ou middleboxes não lidam bem com cadeias de certificados maiores que 10 kB. Ultrapassar esse limite provoca viagens adicionais de ida e volta e causa uma redução de desempenho superior a 60%.” — Experimento de TLS pós-quântico da Cloudflare em 2021, retomado em State of the Post-Quantum Internet, 2024.
Esse é o problema da ossificação de protocolos em termos concretos. A janela inicial de congestionamento do TCP, o limite antialavancagem do QUIC, as suposições de MTU em middleboxes e os tamanhos de buffer ASN.1 em pilhas legadas: todas as camadas absorveram informalmente a premissa de que um handshake TLS é pequeno.
A saída: certificados em árvore de Merkle
A resposta estrutural mais promissora são os Merkle Tree Certificates, MTC, definidos em um rascunho da IETF elaborado por uma equipe conjunta da Google, Cloudflare, Apple e Geomys no grupo de trabalho PLANTS:
“O ML-DSA-44 usa 1.312 bytes por chave pública e 2.420 bytes por assinatura. Dois SCTs e uma assinatura de certificado final acrescentam 7.260 bytes de sobrecarga de autenticação. Certificados em árvore de Merkle são significativamente menores que uma única assinatura ML-DSA-44 e quase dez vezes menores que as três assinaturas necessárias para incluir SCTs pós-quânticos.” — Benjamin, O'Brien, Westerbaan, Valenta, Valsorda, draft-ietf-plants-merkle-tree-certs.
A ideia inverte a cadeia tradicional. Em vez de cada certificado final carregar sua própria assinatura, a autoridade certificadora mantém um registro somente de anexação, assina periodicamente uma raiz de Merkle correspondente ao conteúdo atual desse registro e fornece a cada assinante uma prova de inclusão: um caminho de autenticação de tamanho logarítmico entre a folha e a raiz.
Para uma autoridade certificadora que emite 10^9 certificados, a prova teria aproximadamente 30 \times 32 = 960 bytes, enquanto a assinatura ML-DSA, mais cara, existiria apenas uma vez, na raiz. Segundo o mesmo rascunho, isso reduziria a carga de autenticação para menos de 800 bytes por conexão, um valor inferior ao das cadeias RSA atuais.
Mas existem desvantagem: os clientes precisam manter raízes de Merkle previamente distribuídas; os certificados só se tornam utilizáveis depois que o próximo marco é assinado, introduzindo um atraso na emissão; e o sistema exige uma infraestrutura de registros que vai além do que Certificate Transparency oferece hoje. Ainda assim, MTC é a única proposta que combina segurança pós-quântica + Certificate Transparency e um tamanho razoável na transmissão.
Estado atual da migração
| Área | Situação em meados de 2026 |
|---|---|
| Criptografia simétrica - AES, SHA-2/3 | Nenhuma alteração necessária |
| Acordo de chaves TLS - X25519MLKEM768 | Padrão no Chrome, Firefox e na borda da Cloudflare; mais de 50% do tráfego humano da rede |
| Acordo de chaves no servidor de origem | Aproximadamente 3,7% das origens em 2025 |
| Autenticação TLS - certificados pós-quânticos | Em elaboração; primeiros certificados de teste esperados entre 2026 e 2027 |
| Migração das raízes das autoridades certificadoras | Ainda não iniciada na infraestrutura pública de chaves |
| OCSP e revogação no cenário pós-quântico | Problema em aberto |
| Compatibilidade com middleboxes e appliances | Ainda não testada em grande escala |
Os prazos regulatórios variam. A CNSA 2.0 da NSA exige criptografia pós-quântica para sistemas de segurança nacional dos Estados Unidos até 2033. As orientações da União Europeia e do Reino Unido estabelecem metas entre 2030 e 2035 para setores sensíveis. Nenhum desses prazos será viável sem uma solução para certificados implementada vários anos antes.
Observações finais
A dificuldade dessa migração não está na matemática. ML-KEM e ML-DSA são primitivas maduras, revisadas por especialistas, e suas implementações são abertas. O problema é que o HTTPS é uma estrutura com dezenas de camadas: um handshake TLS envolve uma autoridade certificadora, um registro de Certificate Transparency, um respondedor OCSP, o repositório de confiança do navegador, a pilha TCP do kernel, um balanceador de carga, um HSM, um middlebox com MTU fixa e um analisador ASN.1 escrito em 2003. Cada um desses componentes tem sua própria ideia sobre o tamanho máximo aceitável de um certificado.
Trocar os algoritmos é a parte fácil, mas redimensionar toda essa estrutura sem derrubá-la é a parte difícil.
“A criptografia raramente é quebrada; ela é contornada.”
— Adi Shamir
Mais do que qualquer contagem de qubits, é isso que determinará se o HTTPS atravessará essa transição sem grandes problemas.
Referências
- Westerbaan, B. State of the Post-Quantum Internet in 2025. Cloudflare, outubro de 2025. blog.cloudflare.com/pq-2025
- Westerbaan, B. The State of the Post-Quantum Internet. Cloudflare, março de 2024. blog.cloudflare.com/pq-2024
- Adrian, D.; Beck, B.; Benjamin, D.; O'Brien, D. Advancing Our Amazing Bet on Asymmetric Cryptography. Google / Chromium, maio de 2024. blog.google/chromium/advancing-our-amazing-bet-on-asymmetric
- Benjamin, D.; O'Brien, D.; Westerbaan, B.; Valenta, L.; Valsorda, F. Merkle Tree Certificates. Rascunho IETF draft-ietf-plants-merkle-tree-certs. datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs
- NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. Agosto de 2024. csrc.nist.gov/pubs/fips/203/final
- NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. Agosto de 2024.
- NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard. Agosto de 2024.
- Cloudflare. Post-quantum cryptography (PQC) — SSL/TLS docs. developers.cloudflare.com/ssl/post-quantum-cryptography