Criptografia pós-quântica: o que já dá para usar hoje

Criptografia pós-quântica: o que já dá para usar hoje

·5 min de leituraSegurança e Privacidade

A previsão do Google para o chamado Q-Day, o momento em que um computador quântico útil começa a comprometer a criptografia clássica, deixou de parecer assunto de laboratório e passou a soar como prazo de migração. A empresa encurtou sua estimativa de 2035 para 2029, segundo reportagem da CyberScoop sobre o cronograma adotado pelo Google. Para quem ainda protege credenciais bancárias, prontuários e mensagens privadas com RSA ou ECC, isso muda o tom da conversa: não é mais debate conceitual, é contagem regressiva.

O problema também não está restrito ao futuro. A lógica do “colher agora, decifrar depois” já entrou no vocabulário da segurança digital. Dados roubados hoje podem ficar armazenados até que a capacidade de quebrar a criptografia amadureça. Em um cenário em que 67% das violações já começam com um login roubado, a vida útil do sigilo importa tanto quanto o ataque inicial.

O risco quântico já virou problema de planejamento

Em agosto de 2024, o NIST concluiu três padrões centrais de criptografia pós-quântica e manteve outros em desenvolvimento, como mostra a página oficial do programa de padronização pós-quântica do NIST. A tendência é imaginar que todos eles competem no mesmo nível. Não competem. Alguns servem para implantação imediata, outros funcionam mais como seguro matemático e há um que, na prática, já saiu de cena.

Essa diferença importa porque segurança não é só escolher o algoritmo “mais forte” no papel. É equilibrar velocidade, custo computacional, consumo de energia, tamanho de chave, facilidade de implementação e risco de erro operacional. Em outras palavras: a melhor opção não é a mais elegante para artigo acadêmico, mas a que você consegue colocar em produção sem abrir uma vulnerabilidade nova.

O algoritmo que perdeu antes de começar

Na parte de baixo da lista está o BIKE. Ele não venceu a disputa do NIST e ficou atrás do HQC na vaga de reserva da quarta rodada. O atrativo era o uso relativamente baixo de memória em alguns cenários. Só que, quando o nível de segurança sobe, latência e custo energético se tornam mais difíceis de justificar.

Na prática, isso significa o seguinte: não há um padrão FIPS vindo para o BIKE. Se um fornecedor apresentar esse suporte como diferencial, o mais prudente é interpretar como sinal de desalinhamento com a trajetória principal do mercado. Em segurança, insistir em um candidato derrotado raramente é ousadia. Quase sempre é atraso.

O seguro de contingência que ainda não virou escolha prática

O HQC ocupa um lugar curioso. Ele foi mantido como alternativa baseada em códigos, fora da família de algoritmos em reticulados. A ideia é simples: se um dia a matemática dos esquemas de reticulado sofrer um abalo, o ecossistema não ficará sem plano B. Sob esse ponto de vista, o HQC faz sentido estratégico.

O problema é a prática. O custo de memória e a sobrecarga térmica ainda pesam, sobretudo em dispositivos móveis e sensores conectados. Em servidores, isso pode ser administrável. Em hardware restrito, continua sendo uma interrogação. Por isso, o HQC parece menos uma primeira escolha e mais uma apólice que você prefere nunca precisar acionar.

Assinaturas: entre segurança máxima e implementação delicada

No campo das assinaturas digitais, duas opções chamam mais atenção por motivos quase opostos. A SLH-DSA, derivada do SPHINCS+, é a escolha mais conservadora do ponto de vista criptográfico. Como depende de funções hash, ela tende a parecer o cofre mais robusto para documentos que precisam continuar verificáveis por décadas, como arquivos públicos, registros jurídicos e logs de infraestrutura crítica.

Só que esse conforto cobra um preço. As assinaturas passam de 7.800 bytes, contra cerca de 3.300 bytes na ML-DSA, e o processo de assinar é mais lento. Isso praticamente exclui a SLH-DSA de tarefas como handshake de TLS, nas quais atraso e tamanho importam muito.

Já a FN-DSA, derivada do FALCON, vai na direção oposta. Ela produz chaves e assinaturas compactas, o que a torna atraente para cadeias de certificados menores, IoT e ambientes com banda limitada. Isso dialoga com a pressão por autenticação mais enxuta, visível em movimentos como a troca de senhas por passkeys. O ponto fraco está na implementação: a geração de chaves exige aritmética de ponto flutuante em tempo constante, algo difícil de executar sem abrir espaço para ataques laterais. É promissora, mas ainda pede cautela.

O que de fato já está pronto para produção

Se a pergunta for objetiva, a resposta também precisa ser. Hoje, a dupla mais madura é ML-KEM para troca de chaves e ML-DSA para assinaturas. A ML-DSA, construída a partir do CRYSTALS-Dilithium, tornou-se o cavalo de batalha para assinatura de código, autenticação e verificação de documentos. Segundo a análise de desempenho publicada no arXiv sobre PQC em TLS, ela assina muito mais rápido do que o RSA-2048, com impacto pequeno no uso real.

No topo está a ML-KEM, derivada do CRYSTALS-Kyber. O motivo não é só teórico, é operacional. O Google já a ativou no Chrome, e a Cloudflare informou que 65% do tráfego humano em sua rede já usa encapsulamento de chave pós-quântico. Quando o NIST diz, em sua comunicação oficial, para integrar a tecnologia “imediatamente”, o recado é raro em clareza.

O prazo confortável já acabou

Para a maior parte das empresas, o desenho mais sensato está ficando claro. ML-KEM cobre a troca de chaves. ML-DSA resolve boa parte das assinaturas. SLH-DSA entra como proteção de longo prazo para casos em que velocidade importa menos que durabilidade. FN-DSA merece monitoramento. BIKE, neste momento, pertence mais ao histórico da competição do que ao futuro da implantação.

O próprio NIST afirma que algoritmos vulneráveis ao quantum serão descontinuados até 2035, com sistemas mais sensíveis migrando antes. Some a isso o avanço de ataques cibernéticos impulsionados por IA, que aceleram o aproveitamento de dados roubados, e a margem para adiar a transição fica menor. O computador quântico capaz de quebrar sua criptografia ainda pode não existir. Para o seu risco, isso já não basta.

Fontes e Referências

  1. NIST Computer Security Resource Center
  2. CyberScoop / Google
  3. Cloudflare
  4. arXiv (Performance Analysis of PQC in TLS)

Conheça nossos padrões editoriais

Talvez você goste de: