A ANSSI, a agência nacional francesa de cibersegurança (Agence nationale de la sécurité des systèmes d'information), não pede às organizações que substituam a criptografia clássica pela criptografia pós-quântica. Ela pede as duas ao mesmo tempo. A hibridização, ou seja, um estabelecimento de chaves cuja chave de sessão depende de um algoritmo clássico e de um mecanismo de encapsulamento de chaves (KEM) pós-quântico, é obrigatória dentro do escopo regulado pela ANSSI. Fora desse escopo, a ANSSI publica recomendações e afirma que essas recomendações ainda não são obrigações regulatórias.
O que a ANSSI entende por hibridização
Um handshake híbrido realiza dois estabelecimentos de chaves e combina os dois segredos compartilhados na chave de sessão. Um atacante precisa quebrar ambos para recuperar o tráfego. Esse design responde a duas preocupações distintas ao mesmo tempo. A metade clássica preserva as garantias de duas décadas de análise e de implementações bem auditadas, como X25519 ou ECDH sobre curvas do NIST. A metade pós-quântica, na prática ML-KEM, padronizado pelo NIST no FIPS 203 em 13/08/2024 (csrc.nist.gov), elimina a exposição ao cenário “colete agora, decifre depois” (harvest now, decrypt later, HNDL), em que um atacante grava hoje o tráfego cifrado e o decifra anos depois. O tráfego gravado é protegido apenas pela troca de chaves, e é por isso que a troca de chaves migra primeiro, enquanto assinaturas e certificados podem vir depois.
Na rede, a hibridização é simplesmente um grupo nomeado. A IANA registrou X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED) para TLS 1.3 (parâmetros TLS da IANA), e a RFC 10024 (agosto de 2026) especifica mecanismos híbridos de acordo de chaves pós-quântico e tradicional para TLS 1.3 (rfc-editor.org). As versões atuais do Chrome, Edge e Firefox oferecem X25519MLKEM768 por padrão, portanto ativá-lo no lado do servidor normalmente é invisível para os usuários. Para SSH, o OpenSSH adicionou mlkem768x25519-sha256 na versão 9.9 (19/09/2024) e o tornou o acordo de chaves padrão na 10.0 (09/04/2025), e a 10.1 (06/10/2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico (notas de versão do OpenSSH).
Onde a hibridização é obrigatória e onde é uma recomendação
A exigência da ANSSI é vinculante no perímetro que ela administra, conforme descrito em seu FAQ sobre pós-quântica (cyber.gouv.fr):
- Qualificação de produtos: produtos de segurança que possuem ou buscam uma qualificação da ANSSI.
- Diffusion Restreinte (DR): sistemas de informação franceses de nível restrito e os produtos que os protegem.
- SAIV e SIIV: os setores de importância vital e seus sistemas de informação de importância vital.
Em todos os outros casos, a posição é uma recomendação. Uma empresa francesa que não vende produtos qualificados, não trata informações Diffusion Restreinte e não é operadora de importância vital não está vinculada hoje à doutrina pós-quântica da ANSSI, e a própria ANSSI o diz. Essa ressalva importa na elaboração de um roadmap: não apresente as orientações da ANSSI ao seu conselho como um prazo legal quando elas não o são. Você ainda pode estar sujeito a outros textos que nada dizem sobre computação quântica, mas tudo sobre a troca de algoritmos: o DORA, no Artigo 6 do Regulamento Delegado (UE) 2024/1774 da Comissão, exige uma política de cifragem e de controles criptográficos que inclua disposições para atualizar ou trocar a tecnologia criptográfica com base na evolução da criptoanálise (EUR-Lex), e o NIS2 Art. 21(2)(h) exige políticas e procedimentos sobre o uso de criptografia (EUR-Lex). Nossa leitura, identificada como interpretação e não como exigência de nenhum dos dois textos, é que um plano de troca de chaves híbrida é uma forma crível de demonstrar que essa política é viva, e não decorativa. Este artigo traz informações sobre orientações publicadas e não constitui aconselhamento jurídico.
As datas indicadas pela ANSSI
Dois sinais orientam as compras na França. A ANSSI pretende exigir criptografia pós-quântica para os produtos que entrarem em qualificação a partir de 2027 e considera que, após 2030, não será mais razoável comprar produtos sem criptografia pós-quântica. O segundo sinal é uma recomendação, não uma proibição, mas é um forte indicativo para qualquer contrato plurianual assinado agora. O registro completo e datado está em nossa página sobre a doutrina da ANSSI.
| Item | Posição da ANSSI | Natureza jurídica |
|---|---|---|
| Troca de chaves híbrida no escopo regulado | Exigida hoje (qualificação, DR, SAIV e SIIV) | Obrigação dentro desse escopo |
| Criptografia pós-quântica para produtos que entram em qualificação | Meta a partir de 2027 | Objetivo declarado da agência |
| Compra de produtos sem suporte pós-quântico após 2030 | Considerada não razoável | Recomendação |
| Escolha dos conjuntos de parâmetros | Preferir os níveis de segurança mais altos quando as restrições permitirem | Recomendação |
Essas datas estão próximas do cronograma europeu: o EU Coordinated Implementation Roadmap v1.1, publicado em 23/06/2025, prevê um inventário criptográfico e roadmaps nacionais até o fim de 2026, a migração dos casos de uso de alto risco até o fim de 2030 e dos de risco médio até o fim de 2035 (Comissão Europeia). Esse roadmap é uma orientação coordenada para os Estados-Membros, não um regulamento que vincula empresas, e nossa página sobre o roadmap mantém os marcos com seu respectivo status. A TR-02102-1 do BSI alemão, uma diretriz técnica, aponta na mesma direção: a versão 2026-01 recomenda o acordo de chaves pós-quântico híbrido e recomenda o acordo de chaves clássico isolado somente até o fim de 2031, ou até o fim de 2030 para necessidades de proteção muito elevadas.
Níveis de segurança mais altos quando possível
O ML-KEM tem três conjuntos de parâmetros: ML-KEM-512, ML-KEM-768 e ML-KEM-1024. A ANSSI expressa preferência pelos níveis de segurança mais altos quando o desempenho e a interoperabilidade permitem. Na prática, para serviços web públicos, isso significa X25519MLKEM768 como base interoperável, porque os navegadores o oferecem hoje, com SecP384r1MLKEM1024 reservado para links em que as duas pontas estão sob seu controle e os bytes adicionais no handshake são aceitáveis. A NSA segue uma direção comparável em outro regime: o CNSA 2.0, que se aplica apenas aos National Security Systems dos EUA, especifica ML-KEM-1024, ML-DSA-87 e AES-256.
Dois cuidados. Elevar o conjunto de parâmetros nunca é motivo para abandonar a metade clássica: um grupo ML-KEM puro, como MLKEM768, não atende a nenhuma exigência de hibridização. E os grupos Kyber pré-padrão, em particular X25519Kyber768Draft00 (codepoint 0x6399), estão obsoletos e devem ser substituídos pelos grupos ML-KEM, em vez de mantidos como fallback.
O que implantar e como verificar
Verifique o que você negocia hoje
Comece em modo somente leitura. Os grupos ML-KEM no OpenSSL exigem OpenSSL 3.5 ou posterior; portanto, verifique primeiro a versão e depois solicite a um servidor um grupo específico.
openssl version
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>/dev/null \
| grep -i 'Negotiated TLS1.3 group'
ssh -Q kex | grep mlkem
Se a linha do grupo voltar vazia ou recair para X25519, o servidor não tem nenhum grupo híbrido habilitado. No lado do servidor, mantenha o grupo híbrido em primeiro lugar e um grupo clássico depois dele, para que um cliente antigo ainda consiga se conectar, e teste em homologação antes da produção. No nginx compilado com OpenSSL 3.5 ou posterior, a diretiva é:
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
A sintaxe varia entre servidores web e entre versões; por isso, siga os detalhes por servidor em nosso guia para habilitar ML-KEM no nginx, Apache, HAProxy e Caddy, em vez de copiar uma única diretiva para todos.
Evidências a manter
Quer as regras da ANSSI se apliquem a você ou não, os artefatos que um auditor ou um cliente do setor público pedirá são os mesmos:
| Pergunta que será feita | Evidência a apresentar |
|---|---|
| Onde está a criptografia vulnerável à computação quântica nos seus sistemas | Inventário criptográfico, por serviço e por protocolo, com responsáveis |
| O que seus endpoints públicos negociam | Resultado de varredura datado por domínio, com o grupo negociado registrado |
| Como você trocará de algoritmo quando as orientações mudarem | Política de cifragem com um gatilho nomeado, um responsável e um plano de rollback |
| O que você exigiu dos fornecedores | Cláusula de compra exigindo troca de chaves híbrida, com a data de entrega |
Para a segunda linha, registre o nome do grupo, e não um aprovado ou reprovado: um X25519MLKEM768 negociado é um fato que um auditor pode verificar novamente.
Próximo passo: medir antes de planejar
A doutrina da ANSSI pode ser lida em uma tarde. Saber quais dos seus próprios serviços já oferecem um grupo híbrido exige uma medição. Você pode verificar seu domínio com o PQC Status gratuitamente para ver as versões de TLS, as cipher suites, a cadeia de certificados e se um grupo ML-KEM híbrido é negociado. Uma varredura descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade. Use-a como a primeira linha do inventário, depois habilite X25519MLKEM768 nos seus endpoints públicos com um fallback clássico e inclua uma exigência de troca de chaves híbrida no próximo contrato que você renovar, antecipando o sinal de compras para após 2030.