Claude achou falha na criptografia do HAWK em 60h: e o que isso significa pro seu legado

Sessenta horas de processamento. Cerca de cem mil dólares em API. Três mensagens humanas em três dias.

Foi o que a Anthropic gastou para o Claude Mythos encontrar uma simetria matemática que ninguém tinha visto na criptografia do HAWK, um esquema de assinatura pós-quântica candidato ao padrão do NIST.

Antes de você sair trocando as chaves do seu servidor: nada disso quebra criptografia em produção. A própria Anthropic é explícita nisso, e a gente vai detalhar exatamente onde estão os limites. Mas se você é dev e leu essa notícia só como "IA quebrou criptografia", você perdeu a parte que importa pro seu trabalho.

Porque o harness que fez isso é, essencialmente, um Claude Code com vários workers rodando em paralelo dentro de um sandbox. E ele pode ser apontado pra outro lugar. Tipo aquele monolito de 2011 que ninguém quer abrir.

TL;DR

• O que é: a Anthropic publicou em 28 de julho de 2026 os resultados do Claude Mythos Preview em criptoanálise — post oficial aqui.
• O que achou: uma automorfismo não trivial no HAWK-256 que derruba a força efetiva de chave de 2^64 para 2^38; uma técnica nova ("Möbius Bridge") que acelera de 200 a 800 vezes o ataque ao AES reduzido a 7 rounds; e um ataque prático ao LEA de 13 rounds.
• O que NÃO quebrou: nada em produção. HAWK é candidato, não está implantado. AES real tem 10 rounds. LEA real tem 24.
• Custo: ~60 horas e ~US$ 100 mil de API no HAWK. No AES, 3 dias e cerca de 1 bilhão de tokens.
• Por que importa pra você: a arquitetura que produziu isso é replicável, e o gargalo dela não é inteligência. É oráculo de verificação.

O que exatamente o Claude descobriu na criptografia do HAWK (e nas outras cifras)

Três resultados, com graus muito diferentes de gravidade.

HAWK-256. É um esquema de assinatura digital baseado em reticulados, candidato na avaliação pós-quântica do NIST. O Claude encontrou uma automorfismo não trivial na estrutura matemática do esquema que ninguém tinha explorado, e isso derruba a força efetiva da chave de 2^64 para 2^38 operações esperadas. Em termos práticos: metade dos bits de segurança evaporaram. O trabalho levou cerca de 60 horas, com um pesquisador da Anthropic acompanhando semi-autonomamente — dando direção ocasional, mas não orientação técnica. Custo aproximado de US$ 100 mil em API.

AES reduzido. Aqui está o resultado mais impressionante e o mais incompreendido. O Claude desenvolveu uma técnica de fingerprinting batizada de "Möbius Bridge" que acelera de 200 a 800 vezes um ataque meet-in-the-middle contra o AES-128 limitado a 7 dos seus 10 rounds. O truque foi eliminar a necessidade de enumerar 2^56 valores distintos, tornando o ataque invariante a esse palpite.

O processo é o detalhe que vale gravar: três dias de trabalho praticamente autônomo, cerca de um bilhão de tokens gerados, e apenas três mensagens humanas substantivas no período inteiro. Nas palavras do post oficial, "over the course of the next three days, Claude autonomously produced several hundred million tokens while working on the problem".

LEA. Cifra leve, padrão nacional coreano e padrão ISO, usada em dispositivos móveis. O ataque cobre 13 dos 24 rounds. O que era 2^98 pares de plaintext e 2^86 de trabalho virou 2^30 plaintexts cifrados, rodando em menos de uma hora num desktop moderno. Esse é o único dos três que é um ataque prático de recuperação total de chave — na versão reduzida.

Houve também resultados menores: recuperação de chave em 6 dos 32 rounds do Serpent-128, e melhorias limitadas em Salsa20, Poseidon e SHA-1.

A parte que o dev precisa ver: como isso foi feito

Esquece a criptografia por um minuto. Olha a arquitetura.

O setup era um harness descrito no próprio post como "Claude Code-like", com múltiplos worker agents colaborando, rodando num ambiente sandboxed com acesso a Python, ao Sage e à literatura criptográfica publicada. O pesquisador que operava tinha background em ciência da computação teórica — e não era especialista em criptografia de reticulados.

E tem um trecho do relatório que, se você já orquestrou agente em paralelo, vai reconhecer na hora:

"A ideia-chave para produzir esse ataque foi descoberta por um par de workers trabalhando juntos. Ambos começaram investigando a ideia; o primeiro worker rejeitou prematuramente a ideia como inviável, mas o segundo achou um jeito de explorá-la completamente."

Um agente desistiu cedo demais. O outro insistiu e achou o caminho.

Isso não é anedota fofa. É a descrição do mecanismo. O que produziu o resultado não foi um modelo mais inteligente ter uma ideia genial. Foi volume de exploração paralela sobre um espaço de busca, com verificação barata e um humano que só precisava dar direção três vezes em três dias.

Guarda esses três ingredientes. Eles são a receita:

1. Espaço de busca grande que ninguém quer explorar manualmente porque é tedioso.
2. Oráculo de verificação barato — no caso, Sage e Python confirmando se o ataque funciona.
3. Tempo e budget para explorar em paralelo, aceitando que a maioria dos caminhos morre.

Agora aponta isso pro seu legado

Pensa no sistema mais feio que você mantém. O monolito com 900 mil linhas. Aquele PHP que passou por quatro gerações de dev. O ERP que ninguém sabe direito como calcula o imposto.

Ele tem exatamente a mesma característica do problema de criptoanálise: espaço de busca enorme que nenhum humano quer explorar. Ninguém vai ler 900 mil linhas procurando a inconsistência entre o Service e o Job que duplica a regra de faturamento. Ninguém vai mapear todos os caminhos em que aquela query sem índice é chamada. É tedioso, é caro em hora de gente sênior, e o retorno é incerto.

É o tipo de trabalho que morre no backlog há seis anos.

Só que o custo dessa exploração acabou de mudar de natureza. Não é mais "duas semanas de um sênior que você não tem". É "rodar N workers em paralelo por três dias com um budget definido". Se a Anthropic gastou US$ 100 mil para achar uma simetria em matemática de reticulados, achar a duplicação de regra de negócio no seu billing custa ordens de grandeza menos — porque o espaço é menor, a verificação é mais barata e o problema é infinitamente mais mundano.

Coisas que se encaixam nesse molde e que você provavelmente tem no seu backlog:

• Auditoria de consistência. Onde a mesma regra de negócio está implementada duas vezes com comportamento divergente.
• Caça a caminho morto. Que endpoints, jobs e comandos ninguém chama há dois anos.
• Mapeamento de acoplamento real. Qual é a dependência de verdade entre módulos, não a que está no diagrama.
• Reconstrução de regra não documentada. Qual é a lógica de fato do cálculo, derivada do código e dos dados, não do que o time acha que é.
• Busca por classe de bug. Toda query que roda em request sem timeout. Todo lugar que confia em input sem validar.

Nenhuma dessas tarefas exige genialidade. Todas exigem paciência infinita e atenção que humano não sustenta por 900 mil linhas.

O gargalo não é o modelo. É o seu oráculo.

Aqui está o ponto que separa quem vai conseguir replicar isso de quem vai queimar budget.

No experimento da Anthropic, a verificação era objetiva e barata. O ataque funciona ou não funciona — roda no Sage e vê. Um worker podia gerar mil hipóteses ruins que não custava nada, porque descartar era instantâneo e inequívoco.

No seu legado, quem é o Sage?

Se a resposta é "a suíte de testes", ótimo — você tem oráculo. O agente propõe, o teste reprova, ele tenta de novo, e o ciclo se fecha sozinho.

Se a resposta é "eu leio o PR", você não tem um sistema de exploração paralela. Você tem uma fila de revisão em que o gargalo é você. Dez workers gerando hipóteses só produzem dez vezes mais coisa pra você ler. Isso não escala — piora.

Por isso a ordem de trabalho num legado é contraintuitiva. Não é "aponta o agente pro código e pede pra achar bug". É:

1. Construir o oráculo primeiro. Teste de caracterização em cima do comportamento atual, mesmo que o comportamento atual esteja errado. Você não está testando se está certo — está congelando o que existe para poder mexer.
2. Definir o critério de descarte. O que faz uma hipótese ser rejeitada sem precisar de gente. Sem isso, todo achado vira ticket pra alguém triar.
3. Só então paralelizar a exploração.

Vale lembrar que mesmo com oráculo objetivo, a Anthropic precisou de dois pesquisadores gastando várias centenas de horas estudando criptografia para validar os resultados, e cerca de um mês para dar o resultado do AES como bom. A geração foi barata e rápida. A validação foi cara e lenta.

Essa proporção vai se repetir no seu projeto. Planeje pra ela.

Limitações e pontos de atenção

Vamos ser precisos sobre o que não aconteceu, porque a manchete atropelou isso.

Nada em produção foi quebrado. A frase da Anthropic é literal: "nenhum desses resultados tem impacto prático nos sistemas de computador de hoje". O HAWK é apenas um candidato e não está implantado. O ataque ao AES funciona numa versão modificada com 7 dos 10 rounds — o AES-128 que protege seu TLS continua exatamente como estava ontem — e mesmo na versão reduzida ele exige 2^105 plaintexts escolhidos, o que é completamente impraticável. O ataque ao LEA não se aplica à cifra completa de 24 rounds.

O resultado do HAWK é específico. A Anthropic afirma que ele não afeta outros candidatos pós-quânticos do NIST nem criptografia baseada em reticulados de forma geral.

A divulgação foi responsável. Os resultados foram compartilhados com o NIST em junho de 2026, validados com acadêmicos e coordenados com parceiros de governo e indústria antes da publicação. Isso não é vazamento nem stunt de marketing. Vale o contraste com o que rolou em junho, quando viralizou a alegação de que o Mythos teria invadido sistemas da NSA em horas — aquilo era boato, isto aqui é resultado publicado, com metodologia e limites declarados. A diferença entre os dois é exatamente o que você deveria exigir de qualquer manchete sobre IA e segurança.

E do lado prático, para quem quer replicar a ideia no próprio código: os números do experimento não são o seu orçamento. Cem mil dólares em API para 60 horas de descoberta em matemática de fronteira não é a escala de uma auditoria de monolito. Mas a lição de arquitetura vale — e o erro caro é achar que dá pra pular a etapa do oráculo porque "o modelo é bom agora". Não é sobre o modelo ser bom. É sobre ter como descartar hipótese sem pagar hora de gente.

Por fim, cuidado com o efeito colateral óbvio: se você tem código proprietário sensível, exploração autônoma em sandbox com acesso a ferramentas exige as mesmas cautelas de qualquer agente com acesso a repositório. Isso não mudou. Se o tema te interessa, vale ler o que já escrevemos sobre prompt injection e superfície de ataque em agentes.

FAQ rápido

Meu AES está inseguro agora? Não. O ataque funciona em AES reduzido a 7 rounds, e mesmo assim exige 2^105 plaintexts escolhidos. O AES-128 completo de 10 rounds não foi afetado.

Devo parar de considerar HAWK como opção pós-quântica? O resultado derruba a força efetiva do HAWK-256 de 2^64 para 2^38 e foi comunicado ao NIST em junho. É informação relevante para o processo de padronização, mas o HAWK é candidato, não padrão implantado. Não há ação a tomar em produção.

Posso replicar esse tipo de exploração no meu código? A arquitetura sim: workers em paralelo, sandbox com ferramentas, verificação automática. O que decide o resultado é a qualidade do seu oráculo de verificação. Sem teste automatizado que reprove hipótese ruim, você só gera fila de revisão.

Quanto custaria fazer isso num projeto normal? Muito menos que os US$ 100 mil do HAWK — o espaço de busca é menor e a verificação é mais barata. Mas não comece pelo custo. Comece perguntando se você tem como validar um achado sem ler o diff inteiro.

Conclusão

O resultado técnico é sólido e os limites estão bem marcados: nada disso ameaça sistema em produção hoje, e a Anthropic diz isso com todas as letras.

O que mudou não é a segurança do seu TLS. É a economia da exploração exaustiva.

Um pesquisador que não era especialista no domínio, com um harness de agentes em paralelo, três mensagens em três dias e um bilhão de tokens, encontrou algo que criptógrafos humanos não tinham encontrado. Não porque o modelo é mais inteligente que eles. Porque explorou muito mais caminhos, e tinha como saber na hora quais caminhos eram becos.

Seu legado é um espaço de busca. Ele está cheio de becos e de achados. A pergunta que decide se você vai extrair alguma coisa dele não é qual modelo você vai usar.

É se você consegue provar que uma hipótese está errada sem precisar ler o código.