A migração para a criptografia pós-quântica (PQC) já começou e, para boa parte do tráfego da internet, aconteceu sem que ninguém percebesse. O Chrome negocia chaves com ML-KEM por padrão desde a versão 131, o OpenSSH 10.0 adotou um esquema pós-quântico como padrão em abril de 2025 e o iOS 26 ativou o recurso nas conexões TLS dos aplicativos. Quem ainda não começou é, em geral, o sistema interno da empresa: o VPN antigo, o certificado com validade de dez anos, o equipamento industrial que nunca recebe atualização.
Este guia resume o que foi padronizado, quem já adotou (com versões e datas) e um roteiro de seis etapas para equipes de TI. O pano de fundo físico está em computação quântica: o que é e o que ainda não consegue fazer.
O problema em três frases
A criptografia de chave pública usada hoje (RSA e curvas elípticas, como X25519 e ECDSA) se apoia na fatoração de números grandes e no logaritmo discreto. Em 1994, Peter Shor mostrou um algoritmo quântico que resolve esses dois problemas com eficiência, desde que exista um computador quântico grande e com correção de erros, algo que em outubro de 2026 ainda não existe. A criptografia simétrica (AES) e as funções de hash (SHA-2, SHA-3) são bem menos afetadas: AES-256 continua considerado adequado.
O risco que justifica agir antes do tempo tem nome: coletar agora, decifrar depois (harvest now, decrypt later). Um adversário pode gravar hoje uma conexão cifrada e guardá-la até ter a máquina capaz de abri-la. Se um dado precisa ficar sigiloso por 15 anos, ele já está exposto a esse risco.
Assinaturas digitais têm um calendário diferente. Uma assinatura falsificada só é possível depois que a máquina existir, então a urgência é menor. A exceção são sistemas de vida longa, como raízes de certificação, firmware gravado em hardware e documentos que precisam ter validade por décadas.
O que o NIST padronizou
Em 13 de agosto de 2024, o NIST, instituto de padrões dos Estados Unidos, publicou os três primeiros padrões, resultado de um concurso público iniciado em 2016. Todos rodam em computadores comuns: PQC é matemática e software, não exige hardware quântico.
| Padrão | Algoritmo | Baseado em | Serve para | Tamanho típico |
|---|---|---|---|---|
| FIPS 203 | ML-KEM (ex-Kyber) | Reticulados | Troca de chaves (encapsulamento) | ML-KEM-768: chave pública de 1.184 bytes |
| FIPS 204 | ML-DSA (ex-Dilithium) | Reticulados | Assinatura digital (padrão principal) | ML-DSA-65: assinatura de 3.309 bytes |
| FIPS 205 | SLH-DSA (ex-SPHINCS+) | Funções de hash | Assinatura digital (reserva, outra matemática) | Assinaturas de cerca de 8 KB a 50 KB |
| FIPS 206 (em elaboração) | FN-DSA (ex-Falcon) | Reticulados | Assinaturas menores | Ainda sem versão final em outubro de 2026 |
| Seleção de março de 2025 | HQC | Códigos corretores de erro | Troca de chaves (reserva ao ML-KEM) | Rascunho previsto para 2026, padrão final para 2027 |
Para comparar: uma chave pública X25519 tem 32 bytes e uma assinatura Ed25519 tem 64. O salto de tamanho é o principal custo prático da migração, e é ele que quebra equipamentos com buffers pequenos e protocolos com limite de pacote.
O HQC foi escolhido em 11 de março de 2025 justamente para não depender de uma única família matemática. Se alguém encontrar uma fraqueza nos reticulados, existe uma troca de chaves baseada em outro problema.
O prazo de referência: 2030 e 2035
No rascunho do documento NIST IR 8547, publicado em novembro de 2024, o NIST propõe que algoritmos vulneráveis a computadores quânticos sejam considerados obsoletos (deprecated) a partir de 2030 e proibidos (disallowed) em 2035 nos sistemas do governo americano. Em outubro de 2026 o documento ainda aparece como rascunho na página do NIST, mas o calendário virou referência para fornecedores no mundo todo.
Quem já usa, com versão e data
A maior parte da adoção usa o modo híbrido: a chave da sessão é derivada de um algoritmo clássico (X25519) e de um pós-quântico (ML-KEM-768) ao mesmo tempo. Para quebrar a conexão, o atacante precisaria derrotar os dois. O nome técnico que você verá em configurações é X25519MLKEM768 no TLS e mlkem768x25519-sha256 no SSH.
| Produto | Desde | O que mudou |
|---|---|---|
| Chrome, Edge | Versão 131 (novembro de 2024) | Troca de chaves híbrida com ML-KEM ativada por padrão |
| Firefox | 132 no desktop, 145 no Android | Idem, segundo a lista de compatibilidade da Cloudflare |
| OpenSSH | 9.0 (abril de 2022) e 10.0 (abril de 2025) | 9.0 trouxe o sntrup761 por padrão; 10.0 trocou o padrão para ML-KEM; 10.1 avisa quando a conexão não é pós-quântica |
| iOS, iPadOS e macOS 26 | Setembro de 2025 | TLS pós-quântico ativado por padrão em URLSession e Network framework; CryptoKit ganhou ML-KEM e ML-DSA |
| OpenSSL | 3.5.0 | Suporte nativo; um NGINX compilado com ele passa a aceitar o grupo híbrido |
| Go / Node.js | Go 1.24; Node 24.5.0 e 22.20.0 | Cliente TLS com ML-KEM habilitado |
| Signal | PQXDH (2023) e SPQR (outubro de 2025) | Primeiro na abertura da conversa, depois em toda a troca contínua de chaves, com ML-KEM-768 |
A consequência prática: se o seu site está atrás de um CDN ou de um servidor atualizado e o visitante usa um navegador recente, a troca de chaves daquela conexão provavelmente já é híbrida. O que costuma faltar são as assinaturas (certificados continuam RSA ou ECDSA) e os sistemas internos.
E no Brasil
O movimento mais concreto vem da ICP-Brasil, a infraestrutura que emite os certificados digitais usados em e-CPF, e-CNPJ e notas fiscais. No início de fevereiro de 2026, o ITI publicou a Instrução Normativa nº 35, que incorpora algoritmos pós-quânticos à cadeia da ICP-Brasil e alcança também a assinatura avançada do GOV.BR, definindo algoritmos, tamanhos de chave e suítes de assinatura.
Em 26 de junho de 2026, a Portaria ITI nº 38 criou um grupo de trabalho técnico (GTT-PQC-ICP-Brasil) para inventariar as aplicações que precisam migrar, com foco nos motores de assinatura, e entregar um diagnóstico de risco quântico e um plano de migração em 90 dias, prorrogáveis. Para empresas que assinam contratos, notas e documentos fiscais com certificado ICP-Brasil, é esse cronograma que vai ditar quando os certificados mudam.
Roteiro de migração em 6 etapas
O roteiro abaixo segue a lógica das orientações do NIST e da CISA, a agência de cibersegurança dos EUA: primeiro saber onde a criptografia está, depois priorizar pelo tempo de vida dos dados.
Etapa 1: inventário criptográfico
Liste onde a criptografia de chave pública aparece: certificados TLS (internos e públicos), VPNs, SSH, assinatura de código, HSMs, tokens, bibliotecas embarcadas em aplicativos, integrações com bancos e órgãos públicos, dispositivos IoT e equipamentos industriais. Ferramentas de varredura de rede ajudam a achar endpoints TLS, mas não encontram criptografia escondida dentro de software de terceiros: para isso é preciso perguntar ao fornecedor.
Um atalho útil é começar pelo que já tem dono: o time de infraestrutura conhece os certificados, o time de desenvolvimento conhece as bibliotecas e compras conhece os contratos.
Etapa 2: classificar pelo tempo de sigilo
Para cada sistema, responda: por quantos anos esse dado precisa continuar confidencial? Prontuário médico, dados pessoais sensíveis tratados sob a LGPD, segredos industriais e contratos de longo prazo ficam no topo. Uma sessão de comércio eletrônico que perde valor em minutos fica no fim da fila.
Cruze isso com o tempo de vida do equipamento. Um medidor ou sensor instalado hoje e que vai operar até 2040 precisa sair de fábrica com capacidade de atualização criptográfica.
Etapa 3: atualizar o que já tem suporte
Aqui está o ganho rápido, porque é só atualização:
- Servidores web e balanceadores com OpenSSL 3.5 ou superior, com o grupo
X25519MLKEM768habilitado no TLS 1.3. - Servidores e clientes SSH no OpenSSH 10.x, que já usam ML-KEM por padrão.
- Aplicativos em Go, Node.js, Java e Swift nas versões listadas acima.
- CDNs e proxies reversos que já oferecem o modo híbrido do lado do visitante.
Teste antes em homologação: o aumento do tamanho da mensagem inicial do TLS já expôs equipamentos de rede antigos que descartavam pacotes maiores do que esperavam.
Etapa 4: cobrar os fornecedores
Inclua perguntas objetivas em contratos e renovações:
- O produto suporta ML-KEM e ML-DSA, e em que versão?
- O HSM recebe atualização de firmware para os novos algoritmos?
- Existe roteiro público com datas?
Fornecedor que responde com "estamos acompanhando" sem versão nem data é um risco a registrar.
Etapa 5: planejar as assinaturas e a PKI
Trocar assinaturas é mais lento do que trocar a troca de chaves, porque envolve autoridades certificadoras, navegadores, sistemas operacionais e validadores de terceiros. Em outubro de 2026, os certificados públicos de sites continuam em RSA ou ECDSA. O trabalho agora é preparar a PKI interna: testar ML-DSA em laboratório, medir o impacto de certificados maiores e acompanhar o cronograma da ICP-Brasil.
Etapa 6: agilidade criptográfica
Projete sistemas em que o algoritmo seja configuração, e não código fixo. Isso inclui não amarrar tamanhos de chave em campos de banco de dados, não presumir que uma assinatura cabe em 256 bytes e centralizar a criptografia em bibliotecas mantidas, em vez de implementações próprias. A lição do concurso do NIST reforça o ponto: o SIKE, um dos candidatos avançados, foi quebrado em 2022 por pesquisadores usando um computador comum.
Erros comuns na migração
- Confundir PQC com distribuição quântica de chaves (QKD). QKD usa física quântica, fibras e equipamentos dedicados; PQC é algoritmo e roda em qualquer servidor. São soluções diferentes para o mesmo problema.
- Implementar o algoritmo por conta própria. Ataques de canal lateral (tempo, consumo de energia) quebram implementações corretas no papel. Use bibliotecas validadas.
- Abandonar o clássico cedo demais. O modo híbrido existe porque os algoritmos novos têm menos anos de escrutínio do que RSA e curvas elípticas.
- Esquecer os dispositivos limitados. Cartões, sensores e microcontroladores podem não ter memória para chaves e assinaturas maiores, e muitas vezes exigem troca de hardware.
- Tratar como problema só da TI. Prazo de fornecedor, orçamento de troca de equipamento e risco jurídico de vazamento futuro passam por compras, jurídico e diretoria.
O que muda para o usuário comum
Quase nada exige ação manual. Navegador, sistema do celular e aplicativos de mensagem atualizados já fazem a parte deles; o importante é não adiar atualizações. As ameaças que de fato atingem pessoas em 2026 continuam sendo golpes, senhas vazadas e falta de segundo fator, temas de segurança digital e autenticação em dois fatores.
Quem guarda criptomoedas ouve com frequência que "o quântico vai quebrar o Bitcoin". A assinatura usada pelas principais blockchains é de curva elíptica, portanto vulnerável em tese a uma máquina futura, e as comunidades discutem migrações. Não há, em outubro de 2026, computador quântico capaz de fazer isso; o contexto técnico está em carteiras de criptomoedas.
Fontes
- NIST. NIST Releases First 3 Finalized Post-Quantum Encryption Standards (13/08/2024).
- NIST. NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption (11/03/2025).
- NIST CSRC. Post-Quantum Cryptography Standardization.
- NIST CSRC. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
- NIST CSRC. NIST IR 8547 (rascunho): Transition to Post-Quantum Cryptography Standards.
- OpenSSH. Post-Quantum Cryptography.
- Cloudflare. PQC support: navegadores, bibliotecas e servidores.
- Apple. Quantum-secure cryptography in Apple devices.
- Signal. Signal Protocol and Post-Quantum Ratchets (02/10/2025).
- ITI. ITI publica Instrução Normativa que incorpora algoritmos pós-quânticos à ICP-Brasil.
- ITI. ICP-Brasil se prepara para a era pós-quântica com novo grupo de trabalho do ITI.
- CISA. Post-Quantum Cryptography Initiative.




