PQC StatusHarvest now, decrypt later (HNDL, ou seja, coletar agora e decifrar depois) é um ataque paciente: capturar hoje o tráfego cifrado, armazená-lo e decifrá-lo anos depois, quando o acordo de chaves que o protegia deixar de resistir. Hoje ele não exige nenhum computador quântico, apenas capacidade de captura e espaço em disco. Para uma equipe de segurança, a pergunta útil não é, portanto, quando existirá um computador quântico criptograficamente relevante, mas por quanto tempo cada fluxo de dados precisa permanecer confidencial e quais sistemas transportam os fluxos de vida útil mais longa.
O modelo de ameaça, formulado com precisão
Divida o adversário em duas capacidades separadas no tempo.
- Hoje: coleta. Captura passiva em um tap de rede, em um provedor de trânsito upstream, em um ponto de peering, em um balanceador de carga ou middlebox comprometido, ou o roubo de um arquivo de sessões já gravadas. O texto cifrado é armazenado, não lido.
- Depois: computação. Recuperação de uma chave privada a partir de uma chave pública. O algoritmo de Shor, em um computador quântico suficientemente grande, quebra RSA, ECDH, Diffie-Hellman sobre corpos finitos, ECDSA, EdDSA e DSA, qualquer que seja o tamanho da chave. Passar de RSA-2048 para RSA-4096, ou de uma curva elíptica para outra maior, não muda isso.
A criptografia simétrica se comporta de outra forma. AES, SHA-2 e SHA-3 não são quebrados pelo algoritmo de Shor. O algoritmo de Grover oferece uma vantagem menor, quadrática, contra chaves simétricas, e é por isso que AES-256 é preferido quando os dados precisam permanecer confidenciais por muito tempo. Uma sessão gravada não está em risco porque AES-GCM protegeu o payload. Ela está em risco por causa da forma como a chave AES foi acordada.
O forward secrecy não resolve isso
O TLS 1.3 sempre usa um acordo de chaves efêmero, na prática ECDH sobre X25519 ou uma curva do NIST. Forward secrecy significa que roubar amanhã a chave privada de longo prazo do servidor não revela as sessões de ontem, pois o segredo da sessão veio de compartilhamentos efêmeros. Mas esses compartilhamentos públicos efêmeros trafegam em claro dentro do handshake. Um handshake gravado contém, portanto, tudo o que é necessário para reconstruir o segredo da sessão, para qualquer pessoa capaz de resolver aquela única instância de acordo de chaves. O forward secrecy protege contra o roubo de chaves. Ele não protege contra uma criptoanálise posterior do próprio acordo de chaves. Essa lacuna é todo o problema do HNDL.
Por que a troca de chaves migra primeiro e as assinaturas depois
Uma assinatura é verificada no momento da conexão. Se um algoritmo de assinatura se tornar falsificável daqui a dez anos, isso não permite a ninguém ler uma sessão gravada hoje: as chaves de sessão nunca foram derivadas do certificado. O que uma assinatura quebrada proporciona é a personificação no futuro e artefatos forjados que continuam confiáveis por muito tempo.
Daí a ordem seguida por todos os roteiros oficiais. Primeiro vem o acordo de chaves híbrido pós-quântico, baseado em ML-KEM, o mecanismo de encapsulamento de chaves (KEM) padronizado como NIST FIPS 203 em 13 de agosto de 2024 (FIPS 203). As assinaturas pós-quânticas, como ML-DSA (FIPS 204), vêm em seguida, para as cadeias de certificados. Os grupos TLS híbridos X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024 constam do registro de parâmetros TLS da IANA, e o RFC 10024 (agosto de 2026) especifica o acordo de chaves híbrido pós-quântico/tradicional (PQ/T) para TLS 1.3. As versões atuais do Chrome, Edge e Firefox oferecem X25519MLKEM768 por padrão, de modo que, para muitos endpoints públicos, trata-se de uma mudança de configuração e não de um projeto.
Depois não significa nunca, e duas classes de assinatura merecem atenção antecipada mesmo assim:
- Assinaturas cuja verificação ainda precisa ser confiável após um longo intervalo: assinatura de atualizações de firmware e software, raízes de confiança de secure boot, assinaturas de arquivos e documentos, carimbo de tempo.
- Certificados e credenciais de longa validade, cuja reemissão é cara ou fisicamente complicada: produtos embarcados, equipamentos industriais, smart cards.
O CNSA 2.0 da NSA, aplicável aos National Security Systems dos EUA, reflete essa divisão. Ele prevê o uso exclusivo de ML-KEM-1024 e ML-DSA-87 até o final de 2030 para a assinatura de software e firmware e para equipamentos de rede tradicionais, e até o final de 2033 para navegadores e servidores web, serviços em nuvem e sistemas operacionais.
Quais dados têm uma vida útil de confidencialidade longa o bastante para importar
A vida útil de confidencialidade é o período durante o qual a divulgação ainda causaria dano. É uma propriedade de negócio e jurídica dos dados, não uma propriedade do protocolo, e é o único dado de entrada da priorização HNDL que você controla totalmente. Ordens de grandeza bastam para começar.
| Categoria de dados | Por que a vida útil é longa ou curta | Ordem de grandeza |
|---|---|---|
| Dados de saúde, genômicos e biométricos | Identificam uma pessoa por toda a vida e não podem ser reemitidos | Décadas |
| Material governamental, de defesa e diplomático | Os prazos de classificação são definidos por políticas, não pela tecnologia | Décadas |
| Segredos comerciais, fórmulas, projetos, código-fonte | O valor acompanha a vida útil da linha de produtos | Anos a décadas |
| Sigilo profissional jurídico, processos judiciais, material do conselho e de transações | Continua sensível muito depois do fechamento do negócio ou do caso | Anos a décadas |
| Credenciais e material de chaves em trânsito | Herdam a vida útil daquilo que desbloqueiam | Anos |
| Dados pessoais mantidos sob obrigações de retenção | O dano persiste enquanto os registros existirem | Anos |
| Preços em tempo real, tokens de sessão curtos, telemetria operacional | O valor se degrada rapidamente após a captura | Dias a meses |
Duas correções de que a maioria dos inventários precisa. Primeiro, dados de vida curta dentro de um túnel de vida longa herdam a vida do túnel: um link site a site que também transporta replicação de banco de dados tem a vida útil do banco de dados. Segundo, segredos em trânsito têm a vida útil dos sistemas que abrem, não a vida útil da requisição que os transportou.
Como priorizar sistemas pela vida útil dos dados
Para cada sistema, anote dois números. X é a vida útil de confidencialidade dos dados que ele transporta. Y é quanto tempo a migração desse sistema levaria realisticamente, incluindo compatibilidade de clientes, firmware de appliances e janelas de mudança. Há uma terceira grandeza, o momento em que a computação relevante se torna viável, e ninguém consegue atribuir-lhe uma data crível, então trate-a como desconhecida. A regra praticável é o que resta: reduza Y e invista primeiro onde X é maior, porque o tráfego já gravado não pode ser recuperado.
| Nível | Critérios | Ação |
|---|---|---|
| Agir agora | Vida útil de confidencialidade superior a cerca de dez anos, ou o fluxo transporta chaves e credenciais, ou atravessa redes que você não controla | Habilitar o acordo de chaves híbrido ML-KEM no transporte, preferir apenas TLS 1.3, preferir AES-256 onde a stack permitir |
| Planejar em seguida | Vida útil de alguns anos, tráfego interno que ainda transita por redes de provedores ou parceiros | Vincular a mudança à próxima atualização de plataforma ou de appliance, habilitar os grupos híbridos à medida que os clientes os suportarem |
| Acompanhar a plataforma | Vida útil inferior a um ano, sem segredos nem identificadores de longa duração | Herdar os padrões do sistema operacional, da biblioteca e do navegador |
Essa priorização precisa de um inventário como base. O requisito 12.3.3 do PCI DSS v4.0.1, obrigatório desde 31 de março de 2025, já exige um inventário documentado dos cipher suites e protocolos em uso, revisado pelo menos a cada 12 meses, com monitoramento de sua viabilidade contínua. As normas técnicas regulatórias do DORA, Commission Delegated Regulation (EU) 2024/1774, exigem no Artigo 6 uma política de criptografia que inclua disposições para atualizar ou alterar a tecnologia criptográfica com base na evolução da criptoanálise e, no Artigo 7, a gestão de chaves ao longo de todo o ciclo de vida, além de um registro de certificados para os ativos que suportam funções críticas ou importantes. O Artigo 21(2)(h) da NIS2 exige políticas sobre o uso de criptografia. Nenhum desses textos menciona uma coluna de vida útil dos dados: acrescentá-la ao inventário que você já mantém é a nossa interpretação de uma forma prática de evidenciar a priorização, não um requisito literal. Este artigo tem caráter informativo e não constitui aconselhamento jurídico.
O que os cronogramas oficiais têm em comum
Os cronogramas publicados diferem em status e em redação, e as ressalvas importam. O EU Coordinated Implementation Roadmap v1.1 (publicado em 23 de junho de 2025) é uma orientação coordenada para os Estados-Membros, não um regulamento que vincule empresas: primeiros passos, incluindo um inventário criptográfico e roteiros nacionais, até o final de 2026; casos de uso de alto risco migrados até o final de 2030; de risco médio até o final de 2035. As orientações do NCSC do Reino Unido fixam a descoberta e um plano inicial até 2028, as migrações de maior prioridade até 2031 e a conclusão até 2035. A BSI TR-02102-1 (versão 2026-01) é uma diretriz técnica: ela recomenda o acordo de chaves híbrido e considera o acordo de chaves clássico usado isoladamente aceitável apenas até o final de 2031, ou até o final de 2030 para necessidades de proteção muito elevadas. O NIST IR 8547 continua sendo um rascunho público inicial; ele propõe descontinuar os algoritmos vulneráveis à computação quântica com segurança de 112 bits após 2030 e proibir os algoritmos de chave pública vulneráveis à computação quântica após 2035. A ANSSI torna a hibridização obrigatória dentro de seu escopo regulado e declara que suas recomendações pós-quânticas ainda não são obrigações regulatórias fora dele. Nossa página sobre os prazos de migração pós-quântica reúne os detalhes datados em um só lugar.
A estrutura compartilhada é mais informativa do que qualquer data isolada: um grupo de maior prioridade por volta de 2030 a 2031, o restante até 2035, e um critério de seleção para o primeiro grupo que é, essencialmente, a longa vida útil dos dados. É o argumento do HNDL, inscrito nas políticas públicas.
Verifique o que seus handshakes realmente negociam
Meça antes de planejar. Com o OpenSSL 3.5 ou posterior, a versão mínima que oferece os grupos TLS ML-KEM, solicite explicitamente um grupo híbrido e leia o que foi negociado:
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>&1 | grep -i groupPara o acesso administrativo, verifique o acordo de chaves de uma sessão SSH. O OpenSSH 9.9 (19 de setembro de 2024) adicionou mlkem768x25519-sha256, o OpenSSH 10.0 (9 de abril de 2025) o tornou o acordo de chaves padrão, e o OpenSSH 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico, por meio de WarnWeakCrypto, habilitado por padrão. As notas de versão são publicadas em openssh.com.
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | grep -i kexColoque o grupo híbrido em primeiro lugar e mantenha um fallback clássico logo atrás, por exemplo X25519MLKEM768 e depois X25519, para que clientes mais antigos continuem se conectando. Teste em homologação antes da produção e acompanhe o tamanho dos handshakes em links restritos e em appliances que inspecionam o ClientHello.
Seu próximo passo
Comece pelos dois artefatos que tornam o restante mecânico: uma coluna de vida útil dos dados acrescentada ao seu inventário criptográfico e uma medição do que seus endpoints externos negociam hoje. Para o segundo, você pode escanear seu domínio com o PQC Status gratuitamente: ele informa os grupos híbridos ML-KEM oferecidos, as versões de TLS e os cipher suites, além da cadeia de certificados. Um scan descreve apenas a configuração TLS visível externamente, portanto trate-o como evidência para o seu inventário, não como uma certificação ou um atestado de conformidade. Em seguida, pegue os sistemas do seu nível de ação imediata e aplique neles o acordo de chaves híbrido, nessa ordem.