PQC StatusEm uma VPN, a parte exposta a um futuro atacante quântico é a troca de chaves, não a criptografia do tráfego. Para IPsec, existem hoje dois mecanismos publicados pelo IETF que você pode usar: a RFC 9370, que permite ao IKEv2 negociar trocas de chaves adicionais para que um KEM (mecanismo de encapsulamento de chaves) pós-quântico funcione ao lado de um grupo clássico, e a RFC 8784, que mistura uma chave pré-compartilhada pós-quântica na derivação de chaves do IKEv2. O WireGuard não tem troca de chaves pós-quântica no próprio protocolo, portanto sua chave simétrica pré-compartilhada opcional de 32 bytes é a única alavanca dentro do protocolo.
Por que a troca de chaves vem primeiro
Um túnel IPsec tem duas camadas. O ESP (Encapsulating Security Payload) protege os dados com um algoritmo simétrico, tipicamente AES-256-GCM. Algoritmos simétricos e funções de hash não são quebrados pelo algoritmo de Shor, e o algoritmo de Grover é o motivo pelo qual o AES-256 é preferido para proteção de longo prazo. A camada IKE (Internet Key Exchange) é diferente: o IKEv2, conforme publicado na RFC 7296, deriva suas chaves de uma troca Diffie-Hellman, e tanto o Diffie-Hellman sobre curvas elípticas quanto o Diffie-Hellman sobre corpos finitos são quebrados pelo algoritmo de Shor em um computador quântico suficientemente grande, qualquer que seja o tamanho do grupo.
Isso importa agora por causa do coletar agora, decifrar depois (HNDL): um atacante que grava hoje o tráfego cifrado do túnel só precisa que a troca de chaves caia mais tarde para lê-lo. Túneis site a site que transportam dados com longa vida útil de confidencialidade (prontuários de saúde, documentos jurídicos, projetos industriais, dados de pagamento) são o caso mais claro. A autenticação é uma questão separada. A autenticação de pares no IKEv2 com certificados RSA ou ECDSA só precisa resistir a um atacante presente no momento do handshake, portanto as assinaturas podem migrar depois da troca de chaves, mas precisam migrar.
Os três mecanismos disponíveis hoje
| Mecanismo | Especificação | O que muda | O que exige |
|---|---|---|---|
| Trocas de chaves adicionais no IKEv2 | RFC 9370, usando a troca IKE_INTERMEDIATE da RFC 9242 | Um KEM pós-quântico é negociado na própria sessão, além do grupo clássico | Suporte nos dois pares, um método de troca de chaves registrado para o KEM, fragmentação IKEv2 |
| Mistura de chave pré-compartilhada pós-quântica (PPK) | RFC 8784 | Um segredo de alta entropia é misturado na derivação de chaves do IKEv2, de modo que uma troca gravada não basta | Distribuição fora de banda, armazenamento e rotação de uma PPK por par de pares |
| Chave pré-compartilhada do WireGuard | Documentação do protocolo WireGuard (opção PresharedKey) | Uma chave simétrica de 32 bytes é misturada à chaining key do handshake | Distribuição fora de banda por par de pares, sem negociação na sessão |
| Proteção do payload ESP | AES-256-GCM | Nada: já está fora do alcance de Shor | Preferir AES-256 para proteção de longo prazo |
RFC 9370: trocas de chaves adicionais no IKEv2
O IKEv2 básico negocia exatamente um método de troca de chaves, na troca IKE_SA_INIT. A RFC 9370 acrescenta até sete tipos adicionais de transform de troca de chaves (comumente escritos ADDKE1 a ADDKE7), negociados na mesma proposta e depois executados em uma ou mais trocas IKE_INTERMEDIATE, o tipo de troca definido na RFC 9242. Os segredos compartilhados resultantes são combinados no material de chaves da IKE SA, de modo que manter um grupo clássico como primeira troca de chaves e adicionar um KEM como ADDKE1 produz um esquema híbrido: o atacante precisa quebrar ambos. O híbrido é o que ANSSI e BSI recomendam, e é a escolha conservadora enquanto as implementações pós-quânticas ainda são jovens.
O KEM a solicitar é o ML-KEM, padronizado pelo NIST na FIPS 203 em 13 de agosto de 2024. ML-KEM-768 é o conjunto de parâmetros intermediário mais comum; o CNSA 2.0 exige ML-KEM-1024. A lista oficial de identificadores de métodos de troca de chaves do IKEv2 é o registro de parâmetros IKEv2 da IANA, e o trabalho de especificação do ML-KEM para IKEv2 está no grupo de trabalho IPSECME do IETF; portanto, consulte o registro e a documentação da sua implementação em vez de confiar em um número de transform citado em um artigo.
Há duas consequências operacionais. Primeiro, as chaves públicas e os ciphertexts do ML-KEM são muito maiores que um ponto de curva elíptica, então a fragmentação de mensagens IKEv2 (RFC 7383) deve ser habilitada. Um dos motivos pelos quais a RFC 9370 usa IKE_INTERMEDIATE é que essas trocas podem ser fragmentadas, ao contrário da IKE_SA_INIT. Segundo, a sintaxe das propostas varia entre implementações e versões, e a grafia da palavra-chave para uma troca de chaves adicional pós-quântica não é portável. Verifique-a na documentação da sua versão exata:
# Illustrative shape only, not a portable configuration line.
# Order: encryption - integrity/PRF - classical group - additional key exchange 1
# aes256gcm16 - prfsha384 - <classical group> - <ML-KEM as ADDKE1>
# The keyword for the additional key exchange depends on the implementation
# and its version. Take it from that version's documentation.Verificações somente leitura em um gateway Linux, antes e depois de uma mudança, mostram o que o kernel realmente instalou:
# List the IPsec security associations and the ESP algorithms in use
ip -s xfrm state
# Show the installed IPsec policies
ip xfrm policyTeste primeiro em homologação, com os pares que você realmente usa, e mantenha uma proposta somente clássica como fallback documentado até que todos os pares tenham migrado.
RFC 8784: mistura de uma chave pré-compartilhada pós-quântica
A RFC 8784 segue outro caminho. O iniciador sinaliza o suporte com uma notificação USE_PPK, e uma chave pré-compartilhada pós-quântica, identificada por um PPK_ID, é misturada na derivação de chaves da IKE SA. Um atacante que grava a troca e depois quebra a parte Diffie-Hellman ainda não consegue derivar as chaves de sessão sem a PPK. Ela é útil justamente porque não exige nenhum novo algoritmo assimétrico: muitas pilhas IKEv2 já implantadas conseguem fazê-lo.
Os limites são operacionais, não criptográficos. A PPK precisa ter entropia real e deve ser gerada por uma fonte aleatória adequada, não digitada por uma pessoa. Ela precisa ser distribuída, armazenada e rotacionada fora de banda, por par de pares, o que é a parte difícil em escala. Ela não torna a autenticação de pares pós-quântica. Além disso, a RFC 8784 permite que a PPK seja obrigatória ou opcional: se for opcional, um par que não envia USE_PPK simplesmente obtém uma SA clássica. Onde as duas pontas oferecem suporte, configure-a como obrigatória e registre em log quais pares negociaram uma PPK, para que você possa comprovar a cobertura em vez de presumi-la.
WireGuard hoje
O handshake do WireGuard é construído sobre Curve25519, portanto a troca de chaves é vulnerável a ataques quânticos da mesma forma que o IKEv2 com um grupo clássico. Por design, o protocolo não tem camada de negociação nem agilidade de algoritmos, então não há troca de chaves pós-quântica para ativar. O que existe é a chave simétrica pré-compartilhada opcional, misturada ao handshake, que a documentação do protocolo WireGuard apresenta como mitigação contra um atacante que grava o tráfego agora e ataca as chaves públicas mais tarde.
# Generate one 32 byte pre-shared key per peer pair
wg genpsk
# In a wg-quick configuration file, add it to the peer section
# [Peer]
# PublicKey = <peer public key>
# PresharedKey = <output of wg genpsk>
# AllowedIPs = 10.0.0.2/32Trate o resultado como um segredo com ciclo de vida: único por par, entregue por um canal confiável, rotacionado e registrado no seu inventário de chaves. Alguns projetos executam um daemon externo que realiza uma troca de chaves pós-quântica separadamente e atualiza periodicamente o valor de PresharedKey (o Rosenpass é um exemplo de código aberto desse padrão). Isso deixa o próprio WireGuard intocado, ao custo de mais um componente para implantar, monitorar e auditar. Se você precisa de negociação na sessão de um KEM padronizado, o IPsec com RFC 9370 é o caminho que existe hoje.
O que perguntar aos fornecedores de VPN
| Pergunta | Por que importa |
|---|---|
| Quais métodos de troca de chaves pós-quânticos a implementação IKE suporta, em qual versão de firmware e sob quais identificadores de método de troca de chaves da IANA? | Transforma uma alegação de marketing em algo que você pode testar e registrar |
| Vocês implementam a RFC 9370 com a RFC 9242, a RFC 8784 ou ambas? | KEM híbrido negociado na sessão e mistura manual de PPK resolvem o problema de formas diferentes |
| A troca de chaves é híbrida, e com qual conjunto de parâmetros do ML-KEM? | O híbrido é a postura recomendada; o CNSA 2.0 exige ML-KEM-1024 |
| A implementação é validada segundo a FIPS 203, ou usa um módulo validado? | Exigido por alguns regimes de compras e de auditoria |
| A fragmentação IKEv2 está habilitada, e qual é o efeito medido sobre a taxa de rekey, a CPU e o tempo de estabelecimento do túnel? | Payloads de KEM maiores alteram o tamanho dos pacotes IKE e a carga do gateway |
| O que acontece quando um par não suporta a troca pós-quântica, e isso pode ser registrado em log ou gerar alerta? | Você precisa de visibilidade sobre o fallback silencioso para uma SA somente clássica |
| Quais testes de interoperabilidade foram realizados com os pares específicos que usamos (gateways de nuvem, equipamentos de parceiros, clientes de acesso remoto)? | A interoperabilidade do IKEv2 híbrido é onde as implantações travam |
| Qual é o roadmap para autenticação pós-quântica de pares (certificados ML-DSA)? | Primeiro a troca de chaves, depois as assinaturas, mas ambas são necessárias |
| O hardware atual receberá o suporte, ou apenas a próxima geração? | Aceleradores criptográficos dimensionados para curvas elípticas podem não executar ML-KEM |
| Que evidências escritas vocês fornecerão: notas de versão, relatórios de teste, configuração suportada? | É isso que entra no seu inventário criptográfico |
As datas que se aplicam a equipamentos de rede
Os gateways VPN são mencionados explicitamente em um cronograma. O CNSA 2.0 da NSA, que se aplica aos National Security Systems dos EUA, estabelece o uso exclusivo do seu conjunto de algoritmos (entre eles o ML-KEM-1024) 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 de nuvem, sistemas operacionais e equipamentos de nicho. Os equipamentos de rede estão no grupo mais antecipado.
Em outros lugares, a BSI TR-02102-1 (versão 2026-01, publicada em 23 de janeiro de 2026) recomenda acordo de chaves pós-quântico híbrido e considera o acordo de chaves clássico usado isoladamente aceitável somente até o fim de 2031, ou até o fim de 2030 para necessidades de proteção muito elevadas; trata-se de uma diretriz técnica, não de um regulamento. A ANSSI torna a hibridação obrigatória dentro do seu escopo regulado (qualificação de produtos, Diffusion Restreinte, SAIV e SIIV) e afirma que suas recomendações pós-quânticas ainda não são obrigações regulatórias fora dele (FAQ PQC da ANSSI). O EU Coordinated Implementation Roadmap v1.1 (23 de junho de 2025) pede inventários criptográficos e roadmaps nacionais até o fim de 2026 e a migração dos casos de uso de alto risco até o fim de 2030; trata-se de orientação coordenada para os Estados-Membros, não de um regulamento vinculante para empresas. O NCSC do Reino Unido (20 de março de 2025) espera o levantamento e um plano inicial até 2028, as migrações de maior prioridade até 2031 e a conclusão até 2035. O NIST IR 8547 continua sendo um rascunho público inicial: ele propõe descontinuar algoritmos com segurança de 112 bits, como RSA-2048, após 2030 e proibir todos os algoritmos de chave pública vulneráveis a ataques quânticos após 2035.
Nossa leitura, apresentada como interpretação e não como aconselhamento jurídico: um túnel site a site de longa duração que transporta dados regulados é exatamente o tipo de caso de uso de alto risco que esses cronogramas apontam primeiro, o que coloca o parque de VPN no início da fila mesmo onde o texto é uma recomendação e não uma obrigação.
Próximo passo
Comece pelo inventário, porque é isso que todos esses textos pedem: liste cada túnel, a versão do IKE, o grupo de troca de chaves negociado, os algoritmos ESP, o método de autenticação e a vida útil de confidencialidade dos dados que ele transporta. Em seguida, escolha um túnel de baixo risco entre dois pares que você controla e teste uma proposta híbrida em homologação, mantendo um fallback clássico.
O PQC Status testa TLS, não IKEv2, portanto não dirá o que o seu gateway negocia nas portas UDP 500 e 4500. Ainda assim, é a verificação mais rápida de tudo o que um parque de VPN expõe via HTTPS: portais web de appliances, front-ends de SSL-VPN, interfaces de gerenciamento e de registro. Execute uma varredura gratuita desses hostnames com o PQC Status para ver se eles já oferecem uma troca de chaves ML-KEM híbrida e, depois, envie as perguntas acima ao fornecedor de cada gateway.