Cronograma da CNSA 2.0: algoritmos e prazos explicados

A CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) é o conjunto de algoritmos pós-quânticos que a NSA exige para os National Security Systems (NSS) dos EUA e para os produtos comerciais usados neles. A suíte é composta por ML-KEM-1024 para estabelecimento de chaves, ML-DSA-87 para assinaturas de uso geral, LMS e XMSS para assinatura de software e firmware, AES-256 para criptografia simétrica e SHA-384 ou SHA-512 para hashing. O uso exclusivo é exigido até o fim de 2030 para assinatura de software e firmware e para equipamentos de rede tradicionais, e até o fim de 2033 para navegadores e servidores web, serviços em nuvem, sistemas operacionais e equipamentos de nicho.

A quem a CNSA 2.0 se aplica

A CNSA 2.0 não é uma regra geral de criptografia dos Estados Unidos nem um padrão internacional. Ela rege os National Security Systems: os sistemas que tratam informações classificadas ou que são críticos para funções militares e de inteligência. Ela alcança três grupos. Primeiro, as organizações que possuem e operam esses sistemas. Segundo, os integradores que os constroem. Terceiro, e este é o grupo que mais costuma ser pego de surpresa, os fornecedores comerciais cujos produtos são adquiridos para esses sistemas.

As agências federais civis seguem outro caminho. Suas obrigações vêm da Executive Order 14412 (22/06/2026) e do memorando M-26-15 do OMB (24/06/2026), resumidos em nossa página sobre o pós-quântico no governo federal dos EUA: inventário criptográfico automatizado, planos de migração das agências com entrega em 22/10/2026, TLS 1.3 exigido até 02/01/2030, sistemas de alto valor com estabelecimento de chaves pós-quântico até o fim de 2030 e com assinaturas pós-quânticas até o fim de 2031, e migração completa até 2035 nos termos do NSM-10. Os dois caminhos apontam na mesma direção, mas as datas e o escopo diferem. Consulte aquele que se aplica ao contrato que você tem em mãos. Os marcos datados da própria CNSA 2.0 estão reunidos em nossa página de referência sobre a CNSA 2.0.

Este artigo tem caráter informativo e não constitui aconselhamento jurídico. A redação de aquisição de um contrato específico sempre prevalece sobre um resumo geral.

A suíte de algoritmos

A CNSA 2.0 não se limita a dizer pós-quântico. Ela nomeia conjuntos de parâmetros, e nomeia os mais altos.

Três pontos merecem atenção. O ML-KEM é a forma padronizada do CRYSTALS-Kyber, publicada pelo NIST como FIPS 203 em 13/08/2024, junto com o FIPS 204 (ML-DSA) e o FIPS 205 (SLH-DSA). Grupos Kyber anteriores ao padrão, como X25519Kyber768Draft00, estão obsoletos e não atendem a requisito algum. Em seguida, a CNSA 2.0 exige os conjuntos de parâmetros mais altos, ML-KEM-1024 e ML-DSA-87, e não o ML-KEM-768 que os navegadores negociam por padrão hoje. Um produto que suporta apenas X25519MLKEM768 é pós-quântico, mas não é CNSA 2.0. Por fim, a suíte aponta para LMS e XMSS, definidos no SP 800-208, para a assinatura de software e firmware. Esses esquemas têm estado: a chave de assinatura nunca pode reutilizar um índice de chave de uso único, de modo que a infraestrutura de assinatura precisa garantir a persistência do estado. O SLH-DSA (FIPS 205) não tem estado e não aparece na suíte descrita acima.

O AES-256 e a família SHA-2 fazem parte da suíte porque não são quebrados pelo algoritmo de Shor. O algoritmo de Grover é a razão pela qual o AES-256 é preferido ao AES-128 para proteção de longo prazo, e a razão pela qual os tamanhos de hash são de 384 bits ou mais.

Os prazos, categoria por categoria

A CNSA 2.0 fixa datas para o uso exclusivo, o que é mais rigoroso do que o suporte. Uso exclusivo significa que os algoritmos da CNSA 2.0 são os únicos em operação para aquela função: RSA, ECDSA e ECDH deixam de existir, e não apenas perdem prioridade. O suporte, portanto, precisa chegar bem antes do prazo, porque todo o parque precisa estar convertido até essa data.

Essas datas vêm do FAQ da CNSA 2.0, versão 2.1 (dezembro de 2024), e do aviso CNSA 2.0 Algorithms de 30/05/2025. A ordem é deliberada. A assinatura vem primeiro porque uma raiz de assinatura tem vida longa: um firmware assinado hoje com uma chave ECDSA ainda pode ser verificado por dispositivos em campo daqui a uma década, e reemitir uma âncora de confiança em um parque implantado é um processo lento. Os equipamentos de rede vêm primeiro porque terminam os túneis criptografados de longa duração, que são o alvo mais atraente para ataques do tipo colher agora, decifrar depois: o tráfego gravado é protegido apenas pela troca de chaves que gerou suas chaves de sessão, de modo que uma captura feita hoje pode virar texto claro no futuro. Navegadores, servidores, plataformas de nuvem e sistemas operacionais têm até 2033 porque a cadeia de dependências abaixo deles (bibliotecas, módulos de segurança de hardware, autoridades certificadoras, pilhas de protocolos) é mais profunda.

Por que fornecedores fora dos Estados Unidos devem se importar

Três razões, nenhuma delas teórica.

• A redação de aquisição se propaga. Os requisitos da CNSA 2.0 são inseridos em contratos e em solicitações de propostas. Um fornecedor de componentes situado dois ou três níveis abaixo em uma cadeia de suprimentos de defesa os herda por meio do seu cliente, e não do seu próprio regulador.
• Os conjuntos de parâmetros altos são uma decisão de produto, não uma opção de configuração. ML-KEM-1024 e ML-DSA-87 alteram os tamanhos de chaves e assinaturas, os tamanhos de handshake, os tamanhos de imagens de firmware e os requisitos de módulos de segurança de hardware. Um roadmap que para no ML-KEM-768 precisará de uma segunda rodada.
• Os requisitos europeus não são idênticos. A ANSSI torna a hibridação obrigatória dentro do seu escopo regulado (qualificação de produtos, procedimentos relacionados à defesa, operadores de importância vital) e afirma que suas demais recomendações pós-quânticas ainda não são obrigações regulatórias. A BSI TR-02102-1 (versão 2026-01) é uma diretriz técnica que recomenda o acordo de chaves pós-quântico híbrido e considera o acordo de chaves clássico usado isoladamente aceitável apenas até o fim de 2031, ou até o fim de 2030 para necessidades de proteção muito elevadas. Um produto vendido nos dois mercados precisa ser capaz de negociar um grupo híbrido e um conjunto de parâmetros da CNSA 2.0, o que é um argumento a favor da cripto-agilidade no código, em vez de uma única escolha fixada.

Se você precisa ver todos os prazos oficiais lado a lado, nosso panorama dos prazos de migração pós-quântica compara a CNSA 2.0 com o roteiro da UE, as datas do NCSC do Reino Unido e o caminho federal dos EUA.

O que verificar neste trimestre

Comece em modo somente leitura, em homologação, e mantenha um fallback clássico até que o prazo aplicável a você esteja próximo.

Confirme quais grupos a sua pilha TLS consegue de fato oferecer. Os grupos ML-KEM exigem OpenSSL 3.5 ou posterior:

openssl version
openssl list -tls-groups

Procure MLKEM1024 e SecP384r1MLKEM1024, além do amplamente implantado X25519MLKEM768. Os codepoints da IANA estão publicados no registro de parâmetros TLS, e o próprio mecanismo híbrido é especificado na RFC 10024 (agosto de 2026).

Em seguida, teste o que um servidor vai negociar, um grupo por vez, contra um host de homologação:

openssl s_client -connect staging.example.com:443 -groups MLKEM1024 </dev/null 2>&1 | grep -i -E "negotiated|group"
openssl s_client -connect staging.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i -E "negotiated|group"

No lado da assinatura, gere um par de chaves ML-DSA-87 de teste e meça o efeito das assinaturas maiores sobre o tamanho dos seus artefatos, o seu canal de atualização e os seus caminhos de código de verificação:

openssl genpkey -algorithm ML-DSA-87 -out mldsa87-test.key

Mantenha a chave de teste fora de qualquer repositório de confiança de produção. O trabalho mais difícil é organizacional: inventariar cada raiz de assinatura e sua data de expiração, identificar os módulos de segurança de hardware que precisam suportar ML-DSA-87 ou assinatura baseada em hash com estado, e planejar a gestão de estado que LMS e XMSS exigem. Nosso guia sobre como migrar a assinatura de código para ML-DSA aborda o sequenciamento, incluindo a assinatura dupla durante a transição.

Próximo passo: meça o que você apresenta hoje

Os prazos da CNSA 2.0 dizem respeito ao que seus produtos e serviços efetivamente negociam, e não ao que o seu roadmap promete. Comece pela camada visível externamente: analise o seu domínio com o PQC Status para ver quais grupos de troca de chaves, versões de TLS e algoritmos de certificado os seus endpoints oferecem neste momento. Use o resultado como a primeira linha de uma lista de lacunas: endpoints sem nenhum grupo ML-KEM, endpoints que oferecem apenas ML-KEM-768 quando um contrato CNSA 2.0 exigirá ML-KEM-1024, e cadeias de certificados ainda assinadas com RSA ou ECDSA. Uma análise descreve uma configuração TLS visível externamente. Ela não é uma certificação nem um atestado de conformidade, portanto combine-a com o seu inventário interno de chaves de assinatura, imagens de firmware e bibliotecas embarcadas.