GPT-6 Astra quebra Enigma invicto há 20 anos

A mensagem que ninguém conseguia abrir

GPT-6 Astra quebrou a mensagem MVUEH, uma transmissão Enigma do Exército Alemão de 10 de julho de 1941 que resistia a todas as tentativas desde 2005. São só 82 letras, recebidas às 17h30 pela estação do Quartiermeister Ib da SS-Totenkopf como Nr. 172, com indicativo tático 2ny. Parece pouco, mas esse pacotinho ficou duas décadas parado no site Crypto Cellar Research enquanto máquinas mais fracas, clusters caseiros e especialistas em cripto clássica tentavam e falhavam. Quando um modelo resolve isso sozinho, a pergunta imediata não é sobre história. É sobre operação: o que ele fez de diferente e quanto custou para chegar lá.

O incômodo aqui é real para quem trabalha com busca, otimização e agentes autônomos. A mensagem tinha tudo para ser inquebrável na prática: erro de transcrição a partir do formulário original, chave totalmente fora do padrão do dia e um turnover da roda esquerda na letra 72, evento raro que bagunça qualquer ataque estatístico. Em Enigma, o turnover da esquerda muda o caminho elétrico no meio da mensagem e invalida presunções simples de alinhamento. Somado a erros de cópia, isso transforma um problema já caro em um problema traiçoeiro, onde você pode ter o crib certo e mesmo assim não fechar a chave. Foi exatamente esse cenário que segurou o MVUEH por 20 anos.

O fato

Em 15 de setembro de 2026, Carter Leffer pediu validação para a quebra do MVUEH. Na verificação, ficou claro que a chave e o texto decifrado estavam corretos. E o detalhe mais estranho: a chave do MVUEH não tem nada a ver com as outras chaves de 10 de julho de 1941. As demais usam ordem de rotores 512, enquanto o MVUEH usa 253. Conexões de plugues e posição de anéis também divergem. Não é variação pequena de operador cansado. É outra parametrização completa, o que sugere erro de procedimento, troca de rede ou uso de chave de emergência naquele posto.

O texto decifrado aumentou a surpresa. Ele é quase idêntico ao da mensagem Nr. 173, SIPVX, quebrada em 2017 por Alex Shovkoplyas. O SIPVX tem 94 letras, o MVUEH tem 82. A diferença de doze letras vem de dois deslizes humanos: a palavra Bitte virou Btte no MVUEH por erro de cifragem, e a assinatura Waschbusch aparece repetida no SIPVX. Ou seja, provavelmente são duas versões da mesma ordem logística, enviadas com chaves diferentes e com ruído de operador no meio. Quem já operou sistema distribuído reconhece o padrão: mesma intenção, duas tentativas, nenhuma reconciliação.

Vale registrar o contexto do SIPVX. A chave encontrada em 2017 já fugia da chave diária de 10 de julho, mantendo a ordem 512 mas mudando plugs e anéis. Mesmo assim, ela não abria o MVUEH. Isso explica parte da dificuldade. Quem tentava reaproveitar a chave do dia ou a chave vizinha batia na parede, porque o MVUEH estava em outro espaço de busca. Sem um crib forte e sem corrigir a transcrição, força bruta pura não fecha.

Como funciona na visão de operador

Pelo relato da análise, o fluxo foi agêntico de verdade, não um prompt único milagroso. Leffer apenas pediu para o GPT-6 Astra tentar as mensagens não quebradas publicadas no Crypto Cellar. O modelo varreu a página, ranqueou candidatos e elegeu o Nr. 172, MVUEH, como o mais promissor. Depois levantou sozinho a hipótese de que o claro do SIPVX poderia estar relacionado. Essa é a parte que importa. Em vez de atacar no escuro, ele reduziu o espaço com inteligência de contexto, incluindo uma nota de julho de 2026 sobre novas coleções de mensagens no Bundesarchiv, referências RS 3-3/20a e outras, ligadas ao comando logístico Nachschubführer da SS-Totenkopf. Cruzar metadado histórico com cripto é exatamente o que um bom analista humano faria.

A partir daí, a aposta foi no crib ROSENOW ROSENOW, um topônimo repetido típico de informe de suprimento e movimentação. Em termos de arquitetura Enigma, crib é texto claro suposto alinhado a uma posição do cifrado. Com M4 ou M3, cada alinhamento define restrições elétricas que uma Bombe testa contra milhares de posições de rotores e combinações de plugs. O relato diz que o modelo escreveu seu próprio simulador Enigma e sua própria Bombe em Python e C++. Isso faz sentido operacional: Python para iterar rápido na lógica e C++ para acelerar o loop interno de teste de chave, onde latência e throughput mandam. Provavelmente ele rodou primeiro uma fase larga em Python para filtrar alinhamentos plausíveis do crib, depois uma fase pesada em C++ para varrer ordens de rotores, posições iniciais e turnover.

Não há números públicos de custo, tempo ou tokens, então é preciso inferir com cuidado. Uma quebra Enigma com crib conhecido não exige datacenter, mas exige muitas avaliações. Se o modelo testou várias ordens, múltiplos alinhamentos e correções de transcrição, estamos falando de milhões a dezenas de milhões de simulações, algo trivial em C++ moderno em minutos ou poucas horas em uma máquina decente. O custo pesado não está na CPU. Está nos tokens de raciocínio para planejar, depurar código, interpretar saídas e persistir após falhas. Um agente que escreve, executa, lê traceback, corrige e repete por dezenas de ciclos pode consumir contexto enorme. Minha leitura: latência de engenharia, não de cripto. O gargalo foi manter coerência de hipótese ao longo de muitas tentativas, e foi aí que o modelo se destacou.

O ponto técnico que destravou tudo parece ser a combinação de três ajustes: aceitar que a transcrição do formulário tinha erros e testar variantes, modelar corretamente o turnover da roda esquerda na letra 72, e não presumir a chave do dia. Muita tentativa antiga provavelmente assumia texto cifrado limpo e chave vizinha. O agente fez o oposto. Tratou o cifrado como dado sujo, tratou a chave como desconhecida total e usou o parentesco com o SIPVX apenas como guia semântico, não como âncora rígida. Essa postura é mais cara computacionalmente, mas evita mínimo local.

O que isso muda na prática

Para quem constrói agentes, a mensagem é direta. Tarefas longas de descoberta, com ferramenta, código e verificação externa, já são viáveis sem microgerenciamento humano. O operador não precisou dizer para usar ROSENOW como crib nem mandar compilar Bombe. Ele deu objetivo e fonte. O resto foi decomposição, teste e seleção. Quem perde, no curto prazo, é o fluxo manual de análise forense e reversa que depende de especialista para cada hipótese. Quem ganha é quem monta harness bom: sandbox com execução de código, memória de tentativas, validador independente e acesso a corpus.

• Ação prática para replicar: monte um pipeline de quebra histórica com três camadas, um simulador determinístico versionado, um buscador com crib parametrizável e um verificador de alemão militar com dicionário de topônimos e abreviações. Rode o agente apenas na camada de hipótese e deixe a verificação em código puro, sem LLM no laço final.
• Para times de segurança, revise a ideia de que segredo antigo está seguro por obscuridade ou por erro de cópia. Se um agente atual corrige transcrição, infere contexto e escreve o solver, acervos cifrados históricos e até sistemas legados com cripto fraca viram alvo barato para varredura em massa.
• Para pesquisa, documente logs por etapa com sementes, hashes de código e amostras testadas. A análise dos logs do Astra ainda está em curso, e sem reprodutibilidade esse tipo de feito vira anedota em vez de método.

Tensão real: isso escala ou foi sorte bem operada?

Aqui fica meu desconforto. Quebrar um Enigma de 82 letras com um crib forte e um texto irmão quase idêntico é impressionante, mas é um cenário favorável. O modelo tinha pista semântica, corpus público e validador claro: alemão legível com nomes e estrutura militar. Isso reduz alucinação e permite hill climbing. Em problemas sem oráculo, sem crib e sem texto irmão, o mesmo agente pode queimar muito token e não convergir. A pergunta que importa para produto é taxa de sucesso por dólar em tarefas sem guia, não o caso isolado que deu certo.

Tem também o custo invisível. Escrever Bombe em C++ é ótimo, mas quantas tentativas erradas foram descartadas antes? Quantos alinhamentos de ROSENOW foram testados em posições falsas? Em operação real, esse retrabalho precisa de limite, cache e poda. Sem isso, você troca um especialista caro por uma conta de inferência cara. Resolve? Em parte. Move o gargalo de conhecimento raro para engenharia de controle: orçamento de tentativas, avaliação intermediária e critério de parada. Quem não instrumentar isso vai ver o agente passear pelo espaço de busca com confiança total.

Por outro lado, não dá para minimizar. O turnover de esquerda na letra 72 mais erros de transcrição é o tipo de detalhe que mata automação frágil. O fato de o sistema ter persistido, corrigido dados sujos e encontrado uma chave com ordem 253 quando todos esperavam 512 mostra robustez de hipótese que scripts antigos não tinham. Não é só força bruta. É busca guiada com revisão de premissa, que é justamente onde agentes anteriores quebravam.

Conclusão

No fim, o MVUEH caiu porque um agente soube escolher a batalha certa, usar contexto histórico e sustentar um laço longo de código e teste até o encaixe. É menos sobre IA que decifra nazismo e mais sobre IA que opera como analista teimoso com compilador na mão.

Se seu time depende de busca combinatória com dados sujos, vale testar esse padrão hoje. Mas fica a pergunta que decide se vira produto: quantos MVUEHs sem crib evidente ele consegue fechar antes de estourar seu orçamento?