Empresas e protocolos avançam rumo à segurança pós-quântica com adoção real de criptografia híbrida

O '768' em mlkem768x25519-sha256 não é um número arbitrário: é o parâmetro de segurança do ML-KEM que corresponde ao Nível 3 do NIST, ou seja, 128 bits de proteção contra ataques quânticos e clássicos, equivalente à segurança do AES-128. Isso significa que, mesmo se um atacante capturar hoje o tráfego SSH, ele precisaria de um computador quântico com milhares de qubits lógicos (não físicos) e correção de erros robusta para quebrar a chave, algo ainda inalcançável em 2026, mas já passível de planejamento estratégico por agências de inteligência.

A adoção real não é teórica: o OpenSSH já emite alertas concretos desde outubro de 2025 para servidores que não suportam o esquema híbrido. Isso transforma a migração em uma questão operacional de infraestrutura, não de pesquisa. E o TLS não está atrás: o X25519MLKEM768 está ativo por padrão no Chrome 131 e Firefox 132, mas o dado crítico é que, desde fevereiro de 2024, as versões 121 e 122 desses navegadores já tinham o suporte ativado, ou seja, a base técnica existe há mais de dois anos; o que mudou agora é a cobertura efetiva de 70,1% do tráfego global, sinalizando que provedores de conteúdo, CDNs e grandes plataformas já migraram em escala.

Em abril de 2022, o OpenSSH introduziu o mlkem768x25519-sha256 como opção experimental. Em outubro de 2025, passou a emitir alertas explícitos para conexões com servidores desatualizados, uma mudança de postura técnica para operacional. No TLS, o X25519MLKEM768 saiu do estágio de 'suporte experimental' (desde 2024) para 'habilitado por padrão em 70,1% do tráfego', conforme dados da Cloudflare em junho de 2026. Isso confirma que a migração deixou o laboratório e entrou na produção em larga escala, algo que não havia sido reportado nas coberturas anteriores da CEVIU sobre o tema, todas focadas em metas futuras (2029/2035) ou testes pontuais (IPsec, Meta).

Ataques 'harvest-now-decrypt-later' já são realidade operacional: agências governamentais e atores avançados têm coletado tráfego TLS e SSH há anos. O que muda agora é que, pela primeira vez, há uma camada de defesa prática disponível e implantada, não apenas anunciada. Se sua organização ainda usa WireGuard sem Rosenpass ou PresharedKey rotacionado, seu tráfego VPN está exposto a decifração futura com chaves arquivadas hoje. E se seu servidor SSH não aceita mlkem768x25519-sha256, você já está recebendo avisos de clientes modernos, sinal de que a obsolescência criptográfica virou um problema de compatibilidade imediata, não de futuro distante.