OpenSSH e criptografia pós-quântica
(openssh.com)- OpenSSH suporta algoritmos de criptografia pós-quântica para se proteger contra ataques de computadores quânticos
- A partir da versão 9.0, o algoritmo sntrup761x25519-sha512 é aplicado como padrão e, a partir da 10.0, mlkem768x25519-sha256 passa a ser o método de conexão padrão
- A partir da versão 10.1, há uma mudança que expõe uma mensagem de aviso ao usar troca de chaves sem ser pós-quântica
- A maioria dos algoritmos de assinatura existentes (RSA, ECDSA etc.) também terá suporte adicional no futuro
- Para proteger com segurança o tráfego existente, é necessário aplicar algoritmos pós-quânticos em ambos, servidor e cliente
Introdução da criptografia pós-quântica no OpenSSH
O OpenSSH suporta vários algoritmos de troca de chaves que permanecem seguros contra ataques de computadores quânticos
Recomenda o uso desses algoritmos em todas as conexões SSH
Desde o OpenSSH 9.0 (2022), passou a oferecer por padrão a troca de chaves pós-quântica sntrup761x25519-sha512 e, a partir da versão 9.9, adicionou mlkem768x25519-sha256
A mlkem768x25519-sha256 foi definida como o método de criptografia padrão a partir do OpenSSH 10.0
Para estimular a adoção de algoritmos pós-quânticos, o OpenSSH 10.1 começou a exibir o seguinte aviso quando não se usa troca de chaves resistente a ataques quânticos
** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html
Esse aviso é exibido por padrão, mas pode ser desativado pela opção WarnWeakCrypto do ssh_config(5)
Contexto
Um computador quântico é um dispositivo que calcula com informações codificadas em estados quânticos
Consegue resolver rapidamente certos problemas matemáticos que seriam inviáveis para computadores tradicionais
A base matemática de muitos algoritmos criptográficos está em problemas que podem ser facilmente resolvidos por computadores quânticos
Se surgir um computador quântico suficientemente poderoso (em um nível criptograficamente relevante), existe o risco de esses esquemas de criptografia serem quebrados
Especialmente os algoritmos usados em troca de chaves e assinatura digital são os mais afetados
Embora esses computadores quânticos ainda não tenham se concretizado, especialistas projetam que surgirão em 5 a 20 anos ou em meados da década de 2030
A garantia de privacidade de conexões SSH depende da criptografia de troca de chaves
Se um atacante quebrar o algoritmo de troca de chaves, todo o conteúdo da sessão pode ser descriptografado
Além disso, mesmo sem ser em tempo real, é possível um ataque chamado 'store now, decrypt later', no qual a sessão criptografada é armazenada e depois descriptografada quando, no futuro, houver computadores quânticos
O OpenSSH está fortalecendo o suporte à criptografia pós-quântica para enfrentar esse tipo de ataque
FAQ
Q: Recebi uma notificação de aviso no ssh, o que devo fazer?
- No OpenSSH 10.1 ou superior, um alerta é exibido ao usuário ao usar criptografia não resistente a quântica
- Nesse caso, significa que o servidor conectado não oferece algoritmos de troca de chaves pós-quântica (mlkem768x25519-sha256, sntrup761x25519-sha512)
- O ideal é atualizar o servidor para OpenSSH 9.0+ (ou 9.9+ para este último caso) e conferir se os algoritmos relacionados não estão desativados em KexAlgorithms
- Se a atualização do servidor não for possível ou se decidir assumir o risco, também é possível ocultar apenas o aviso com a opção WarnWeakCrypto no ssh_config(5)
- Se necessário, aplique a medida apenas para hosts específicos, como abaixo
Match host unsafe.example.com WarnWeakCrypto no
Q: Se ainda não existem computadores quânticos, por que se preparar com antecedência?
- Por causa do ataque mencionado de 'store now, decrypt later'
- Como o tráfego enviado hoje pode ser descriptografado depois, recomenda-se uma conexão segura para o pós-quântico antecipadamente
Q: Você disse que algoritmos de assinatura também são arriscados. Por que isso não é um problema agora?
- Atualmente, a maioria dos algoritmos de assinatura (como RSA, ECDSA) também pode ser neutralizada por computadores quânticos
- No entanto, nesse caso, não há situação de tráfego existente sendo armazenado para descriptografia futura
- A ação prioritária em relação a algoritmos de assinatura é descontinuar as chaves de assinatura antigas quando a chegada de computadores quânticos estiver se aproximando
- O OpenSSH também deve suportar algoritmos de assinatura pós-quântica futuramente
Q: Acredito que computadores quânticos são impossíveis; por que isso é importante?
- Alguns acham que computadores quânticos não vão se tornar realidade, porém as barreiras atuais não são de física fundamental e sim de engenharia
- Se computadores quânticos forem viáveis, as medidas de hoje resultarão em proteção de enormes volumes de dados dos usuários
- Mesmo que acabe se mostrando desnecessário, trata-se apenas de uma migração para criptografia matematicamente mais forte
Q: E se os algoritmos pós-quânticos também forem vulneráveis?
- O OpenSSH também está adotando uma abordagem cuidadosa
- Embora apenas algoritmos revisados intensivamente nos últimos anos tenham sido selecionados, ainda existe a chance de descoberta de novas técnicas de ataque
- Para cobrir esse cenário, foram adotados apenas algoritmos com ampla margem de segurança, com alta probabilidade de manter segurança operacional prática, mesmo se forem mais fracos do que o esperado
- Além disso, todos os algoritmos pós-quânticos do OpenSSH são do tipo híbrido
- Exemplo: mlkem768x25519-sha256 combina ML-KEM (pós-quântico) com o algoritmo clássico ECDH/x25519
- Isso garante que, mesmo que o algoritmo pós-quântico seja neutralizado no futuro, pelo menos o nível de segurança anterior será mantido
1 comentários
Comentário do Hacker News
Há uma informação importante escondida no rodapé. Todos os algoritmos pós-quânticos aplicados no OpenSSH são "híbridos", combinando simultaneamente um mecanismo de troca de chaves pós-quântico (por exemplo, ML-KEM) com um mecanismo tradicional (x25519). Como os dois algoritmos são usados juntos, mesmo que no futuro o algoritmo pós-quântico seja totalmente quebrado, ainda é possível manter pelo menos o mesmo nível de segurança de antes. O ponto central é que, graças ao modo híbrido, não há perda de segurança em comparação ao cenário atual
O modo híbrido tem a vantagem de oferecer resiliência pelo outro algoritmo se um for quebrado. Por outro lado, a contrapartida é que bugs de implementação e vulnerabilidades de canal lateral ficam mais que dobrados. Na prática, a ameaça quântica ainda não é real, mas esses bugs e essas vulnerabilidades já são problemas concretos hoje. Ainda assim, com a enorme pesquisa e validação de segurança realizadas nos últimos 10 anos, esse trade-off parece plenamente aceitável
A indústria como um todo está migrando majoritariamente para uma arquitetura híbrida PQC-clássica. Até que apareça um computador quântico verdadeiramente capaz de quebrar RSA, ECC e DH, essa abordagem conservadora de usar dois "cadeados" em paralelo parece hoje a opção mais segura. Ao mesmo tempo, os algoritmos da CNSA 2.0 da NSA (link) adotam apenas a família pós-quântica e dizem oficialmente no FAQ que o modo híbrido não é necessário
Considerando o paper recente, satírico e divertido (link), fico me perguntando se realmente precisamos dessa adoção rápida de criptografia pós-quântica. Pelo que sei, os materiais de chave pós-quântica são enormemente maiores do que os atuais, aumentando bastante o tráfego de rede e o consumo de CPU
Este texto fala da aplicação de PQC apenas na troca de chaves de conexões SSH, portanto a sobrecarga é bem baixa. E como também aparece no FAQ, para a pergunta “por que se preparar antes se ainda não existe computador quântico?” a resposta é o risco de “store now, decrypt later”. Há pessoas que defendem que isso é impossível, mas o maior obstáculo é engenharia, não física. Se os computadores quânticos realmente se tornarem possíveis, será uma oportunidade enorme de proteger grandes volumes de dados de usuário. O paper é bom para uma leitura de curiosidade, mas não deve ser levado de forma excessivamente cética
Apesar de ser engraçado, não dá para reduzir esse paper a mera chacota. Na prática, também há avanços reais. Recomendo a apresentação de Sam Jacques no PQCrypto 2025 (link). Nos últimos 10 anos, o custo de fatoração por computador quântico caiu 1000x e a taxa de erro de hardware também caiu drasticamente (link1, link2, link3, link4). Para acompanhar o avanço dos computadores quânticos, basta acompanhar melhorias graduais em robustez. O ruído é o grande gargalo, e quando os problemas de qualidade forem resolvidos dos dois lados, o avanço esperado será bem mais claro
Esse paper é tão absurdo que até parece piada. Se fosse uma crítica séria, seria como reclamar em 1951 de que transistores não conseguem calcular π. A necessidade de PQC depende de duas questões: 1) acreditar que um computador quântico não vai surgir na sua vida; 2) o quanto você valoriza a sensibilidade dos dados que administra. Se você não dá importância para nenhuma dessas, PQC pode ser perda de tempo. Mas, se eu estiver no papel de manter um sistema de criptografia, acho que não tenho autonomia para desconsiderar o valor dos dados dos usuários
A discussão atual é, em grande parte, sobre troca de chaves. Ela ocorre raramente, e a sobrecarga geralmente é baixa. Pontos principais: 1) algoritmos PQ (assinatura, troca de chaves) têm chaves significativamente maiores, mas desempenho de operação é até mais rápido ou similar. 2) em protocolos como TLS e SSH, a troca de chaves acontece apenas na conexão inicial, então o tamanho de chave grande normalmente não é problema. Pode haver questões de compatibilidade, como extrapolar MTU de TCP. Em protocolos que fazem troca de chaves com muita frequência, como Signal e MLS, em alguns momentos só é feito rekey com PQ (link). 3) no caso do TLS, o grande problema é o tamanho da mensagem de assinatura, porque há muitas assinaturas na cadeia de certificados. Por isso, a viabilidade de assinaturas PQ no TLS gera mais preocupação (link)
Além de fontes públicas, o fato de agências de inteligência recomendarem PQ para sistemas que exigem sigilo por mais de 20 anos também aumenta a confiança. Para referência: em 2014, a agência de inteligência holandesa mencionou 2030-2040; em 2021, em 2030 o risco foi considerado baixo, mas não desprezível. Em 2025, 18 países publicaram uma declaração conjunta pedindo preparação contra ataques “store now, decrypt later” até 2030 (documento1, documento2, declaração conjunta)
O Secretive, um app de macOS, armazena chaves SSH no Secure Enclave. Pelos algoritmos suportados, ele usa ecdsa-sha2-nistp256 e, aparentemente, o Secure Enclave não suporta algoritmos pós-quânticos. Fiquei curioso se seria possível criar um híbrido como mlkem768×ecdsa-sha2-nistp256, com o ECDSA tratado no SE apenas (Secretive GitHub)
Penso que a ferramenta ssh-audit (link) deveria incluir uma seção para validar algoritmos teóricos (PQC híbrido). Parece que mesmo fixando apenas um algoritmo ainda dá para sair nota "A". No momento, estou usando apenas chacha
Fico curioso se existe OpenSSH com algoritmo híbrido PQC compatível com FIPS 140-3
Antecipar-se é uma abordagem razoável, principalmente quando a troca de chaves é uma tarefa relativamente leve. Entre as duas opções, qual é mais forte? Talvez a 512 seja mais forte, né?
Os dois algoritmos são totalmente diferentes. mlkem768x25519-sha256 mistura ML-KEM (troca de chaves pós-quântica) com ECDH/x25519 clássico. Dessa forma, se um deles quebrar, o outro ainda mantém o nível de segurança atual. Além disso, a versão 256 (mlkem768) foi lançada depois da versão 512 (sntrup761). OpenSSH suporta sntrup761x25519-sha512 desde a 9.0 e mlkem768x25519-sha256 desde a 9.9
A discussão sobre 256 versus 512 não precisa de preocupação agora. Não há energia suficiente para varrer totalmente um espaço de 128 bits, e nem existe computador para isso. Não é o momento
O ML-KEM é o padrão mais razoável no momento. O setor está convergindo para ele
Estou avaliando migrar meu app de microblog/chat em terminal para essa linha de segurança pós-quântica. Depois de assistir a entrevista com Paul Durov várias vezes e ouvir o que ele passou, a dúvida aumentou
Entre sntrup761x25519-sha512 e mlkem768x25519-sha256, qual é melhor?
MLKEM768 oferece melhor desempenho e chaves menores. O SNTRUP761 parte de suposições de segurança mais fortes e resiste melhor a possíveis ataques de criptoanálise
O NTRU Prime (sntrup) entrou por razões históricas (na época não existia mlkem). Qualquer um dos dois funciona, mas sntrup foi um padrão por um período, como o CAST foi no GPG antigamente
Quando estarão disponíveis certificados PQ também para autenticação de host/usuário?
Antecipar essa iniciativa é positivo. Mesmo que apareça uma alternativa melhor no futuro, acho que esse esforço não deixa de fazer sentido se não ficar pior do que a situação atual