Claude decifra mistério da NSA em 30 minutos

Um bug de 25 anos resolvido em meia hora

Claude resolveu em menos de 30 minutos o mistério das seeds do ECDSA que assombrou a criptografia por 25 anos. Não foi quebra de curva, não foi computador quântico, foi pior para o nosso ego: ele olhou para números que milhares de criptógrafos já tinham olhado e percebeu um padrão bobo nos bits mais significativos. Onde a gente viu aleatoriedade suspeita e conspiração, ele viu preguiça de engenharia dos anos 90. E isso muda a conversa sobre o que IA pode fazer em segurança.

O fato

Em 2000, o NIST padronizou várias curvas para ECDSA, o framework de assinaturas de curva elíptica que hoje protege praticamente tudo, de TLS a carteiras cripto e firmware. Os parâmetros dessas curvas dependem de seeds, valores iniciais que deveriam provar que nada foi cozinhado para criar um backdoor. Só que a NSA entregou essas seeds sem nenhuma explicação sobre como foram geradas. Nenhum script, nenhum método, nenhum memorando. Só os números.

Durante 25 anos isso alimentou uma das maiores paranoias da criptografia moderna. Se você controla a seed, em teoria pode ter escolhido uma curva com uma fraqueza secreta que só você conhece. Teve bounty aberto, teve caçada amadora, teve teoria de que o funcionário da NSA Jerry Solinas teria usado o hash de uma frase engraçada como origem. Essa pista se mostrou errada e o caso esfriou, mas nunca morreu. Toda auditoria séria de ECDSA esbarrava na mesma pergunta sem resposta: por que esses números específicos?

Agora o Claude, da Anthropic, fechou o caso. As seeds vieram de 'lrand48', um gerador pseudoaleatório simples da libc em C, inicializado com um Unix timestamp entre maio de 1997 e abril de 1998. Ou seja, alguém rodou um programinha em C, provavelmente em uma workstation Sun ou SGI da época, gerou alguns inteiros e mandou para padronização. A Anthropic vai doar o bounty de 36.864 dólares para o Internet Security Research Group. O valor é simbólico perto do que isso representa.

Como funciona: visão de operador

O pulo do gato foi observar os bits altos. A função 'lrand48' tem estado interno de 48 bits, mas retorna apenas 31 bits por chamada. É um detalhe clássico de implementação que quem programou em C nos anos 90 conhece bem. Quando você concatena várias saídas para montar um número grande de 160 ou 224 bits para uma seed, o padrão de truncamento deixa marcas. Alguns bits do topo ficam sistematicamente zerados de um jeito que um gerador realmente uniforme não faria. Humanos olharam para aquilo por anos e pensaram em conspiração matemática. O modelo olhou e pensou em bug de libc.

Pelo que foi divulgado, o processo foi basicamente análise exploratória acelerada. Testar hipóteses de PRNGs históricos contra as seeds públicas, simular 'srand48' com timestamps no intervalo plausível e comparar saídas. Isso não exige cluster gigante. Exige iteração rápida e conhecimento amplo de implementações antigas, duas coisas onde um modelo de fronteira se sai bem. Dá para inferir que o custo computacional foi baixo, coisa de dezenas de consultas com raciocínio e execução de código, e latência total abaixo de meia hora. Nada de ataque de força bruta massivo, foi mais como um engenheiro sênior com memória infinita de man pages antigas.

Do ponto de vista de arquitetura, o interessante é a combinação de reconhecimento de padrão com teste executável. O Claude não apenas sugeriu que parecia 'lrand48'. Ele provavelmente gerou scripts para reproduzir a sequência, varreu o espaço de timestamps de cerca de um ano, que dá algo em torno de 31 milhões de segundos, um espaço totalmente trivial para busca moderna, e bateu com as seeds publicadas. Esse loop de hipótese, código, execução e correção é o que separa um chatbot que alucina teorias de um operador que prova.

O que isso muda na prática

Para quem opera sistemas hoje, a boa notícia é que isso reduz, mas não elimina, a suspeita de backdoor deliberado nas curvas NIST P-192, P-224, P-256 e companhia. Se a origem foi um PRNG fraco com timestamp previsível, é mais sinal de descuido processual do que de conspiração sofisticada. Ninguém projeta um backdoor de nível estatal usando 'lrand48' com hora do sistema. É desleixado demais até para os anos 90. Isso deve acalmar um pouco quem ainda mantém ECDSA NIST em produção, que é quase todo mundo.

• Quem ganha: times de segurança e auditoria que vivem de revisar parâmetros criptográficos, agora têm prova de que IA acelera arqueologia de código.
• Quem perde: quem vendeu medo de curva NIST como argumento absoluto para migração emergencial. O problema real continua, mas o enredo muda.
• O que ajustar agora: inventariar onde você ainda usa curvas NIST antigas sem validação rígida e planejar migração para curvas modernas com geração transparente, como Curve25519.

A ação prática aqui é direta. Se você mantém bibliotecas cripto, firmware ou HSMs que validam ECDSA, rode um pente-fino nos seus testes de conformidade. Verifique se seu código aceita apenas curvas nomeadas e rejeita parâmetros arbitrários. Muita implementação ainda aceita curva customizada via API, e esse é o vetor real de backdoor, não a seed de 1997. Aproveite o barulho para justificar aquele backlog de trocar P-256 por Ed25519 onde faz sentido e ativar verificação estrita de assinaturas. Custa pouco e reduz superfície.

A parte incômoda

Aqui vem a tensão que importa. Se um modelo resolve em 30 minutos um enigma que parou humanos por 25 anos, o que mais está ao alcance agora? Não estou falando de quebrar AES ou ECDLP amanhã, isso continua inviável com os métodos atuais. Estou falando de caçar atalhos, descobrir seeds fracas, reverter geradores antigos, achar chaves geradas com entropia ruim em dispositivos IoT, roteadores velhos, carteiras antigas. O gargalo da criptoanálise prática nunca foi só matemática, foi paciência para fuçar detalhe de implementação. E paciência infinita é exatamente o que esses modelos têm.

Isso escala? Para arqueologia criptográfica, sim, e o custo compensa. Uma análise dessas custa centavos em inferência comparada a meses de consultoria especializada. Mas resolve ou só move o gargalo? Resolve um mistério e cria outro maior. Agora precisamos explicar por que confiamos em análises feitas por sistemas que não conseguimos auditar totalmente. O Claude acertou aqui porque a resposta era verificável por reprodução. Em casos onde não há como reproduzir tão fácil, como vamos distinguir intuição correta de alucinação confiante? Operar com IA em segurança vai exigir pipeline de prova, não só resposta.

Conclusão

No fim, a NSA provavelmente não colocou backdoor nas seeds. Colocou algo quase tão ruim para a época: falta de transparência reprodutível. O Claude só expôs isso mais rápido. A pergunta que fica para quem constrói sistemas hoje é simples, quantos 'lrand48' você ainda tem escondidos no seu stack esperando alguém notar?