Claude resolve mistério de 25 anos das curvas ECDSA

O seed que ninguém conseguia explicar

ECDSA está em todo lugar e você provavelmente nunca parou para pensar nisso. Está no TLS que protege seu banco, nas assinaturas de firmware, no Bitcoin, no iMessage, em praticamente qualquer handshake moderno. E no centro disso está uma curva, a NIST P-256, com um parâmetro seed que por mais de 25 anos ninguém soube explicar. O valor SEED = C49D3608 86E70493 6A6678E1 139D26B7 819F7E90 apareceu no padrão FIPS 186-2 do ano 2000, entregue pela NSA sem código, sem paper, sem justificativa. Para quem opera sistemas reais, isso sempre foi um incômodo silencioso. Você confia porque precisa confiar, não porque entendeu a origem.

Eu sempre tratei esse caso como aquele tipo de dívida técnica que ninguém quer mexer. Neal Koblitz e Alfred Menezes resumiram bem em um texto famoso, chamado A Riddle Wrapped in an Enigma. A suspeita era simples e legítima. Se ninguém sabe como o seed foi gerado, como garantir que não houve uma escolha proposital de curva fraca, com backdoor matemático embutido. Teve até bounty aberto para quem achasse a origem, teve história de funcionário da NSA falando de frase engraçada hasheada, algo como dar aumento para o Bob e para o Jerry. Só que ninguém conseguiu reproduzir, ninguém achou o script, e um dos envolvidos principais, Jerry Solinas, morreu em 2023. O mistério ficou parado.

O fato

O que mudou agora é direto. Em outubro de 2026, um funcionário da Anthropic perguntou para um modelo interno de pesquisa se ele conseguia descobrir como aqueles seeds foram gerados, sem dar a dica da frase engraçada. Em menos de meia hora, o Claude resolveu para P-192, P-224, P-256, P-384 e P-521. A resposta não tinha nada a ver com hash de frase. Eram saídas do lrand48, aquele gerador pseudoaleatório antigo da biblioteca C, inicializado com um Unix timestamp. Ou seja, era só o relógio da máquina.

Para a P-256, por exemplo, o processo precisou de 1842 iterações para chegar ao seed padronizado. Cada iteração puxava 20 bytes candidatos do gerador. Candidato 1, candidato 2, e assim por diante, até bater no valor publicado. Não é quebra criptográfica, não é novo ataque, não é vulnerabilidade na curva. A própria equipe deixa claro que não há ação corretiva, nada para migrar, nada para rotacionar. Mas para quem vive de avaliar risco, a implicação é grande. Se a geração foi tão banal quanto um srand48 com time null, fica muito mais difícil sustentar a teoria de backdoor intencional.

Como funciona na visão de operador

Pensa em termos de sistema, não de mito. O lrand48 é um gerador linear congruencial de 48 bits, determinístico e totalmente reproduzível. Você chama srand48 com um inteiro de 32 bits, no caso um timestamp Unix, e depois chama lrand48 ou mrand48 em sequência para cuspir pseudorrandômicos. Não tem entropia de verdade, não tem coleta de ruído do kernel, não tem DRBG moderno. É rápido, barato e previsível se você souber o timestamp inicial. Em termos de latência e custo, é praticamente zero. Qualquer workstation dos anos 90 rodava isso em milissegundos.

A inferência técnica plausível, e aqui estou reconstruindo o cenário provável, é que alguém na época escreveu um programinha em C de umas 30 linhas. Inicializava com time, gerava blocos de 20 bytes, convertia para hexadecimal, testava se o bloco gerava uma curva com ordem prima e propriedades aceitáveis, e iterava até achar uma boa. Não havia pipeline, não havia API de transparência, não havia seed commit. Era o fluxo normal de laboratório da época. O fato de a P-256 precisar de 1842 tentativas sugere um loop simples de rejeição, não uma busca direcionada por fraqueza. Se fosse para plantar backdoor, você esperaria busca com critérios secretos, filtragem complexa, talvez rejeição estatística sutil. Nada disso aparece.

O ponto interessante para quem constrói hoje é a reprodutibilidade. Com o algoritmo conhecido, qualquer pessoa pode fixar o timestamp candidato e regenerar a sequência exata. Isso transforma um artefato de confiança cega em artefato verificável. Não prova segurança absoluta da curva, porque segurança de curva elíptica depende de matemática mais profunda, polo de ordem, resistência a MOV, a Anomalous, a twist attacks. Mas elimina uma classe inteira de suspeita operacional, a de geração maliciosa opaca.

O que isso muda na prática

Quem ganha com isso é quem opera infraestrutura crítica e precisava justificar P-256 em auditoria. Durante anos, a resposta padrão era dizer que a comunidade confia apesar da origem obscura, ou migrar para Curve25519 para evitar a discussão. Agora dá para documentar de forma diferente. A geração foi ingênua, baseada em relógio, reproduzível por terceiros. Isso não torna P-256 melhor que X25519 em performance ou em segurança contra implementação, continua valendo a discussão sobre constant time, sobre validação de ponto, sobre nonce k em ECDSA. Mas tira peso do argumento de conspiração.

• Times de segurança: podem atualizar o risk register e fechar o item de possível backdoor intencional no seed como improvável, com evidência reproduzível.
• Quem mantém bibliotecas cripto: não precisa trocar default, mas pode adicionar teste de regressão que regenera o seed a partir do timestamp para provar provenance.
• Quem avalia migração pós-quântica: continua com o mesmo plano, isso aqui não muda Kyber, Dilithium ou prazos do NIST, só limpa o passado.

A ação prática que eu recomendo é simples. Pegue o descritivo do algoritmo, implemente um script em Python ou C que emule srand48 e lrand48 com o timestamp divulgado na pesquisa e tente regenerar os primeiros bytes das curvas P-192 e P-256. Não é para usar em produção, é para entender o determinismo e para colocar no seu repositório interno de evidências. Se você é auditor, anexe isso ao relatório. Leva uma tarde, custa quase nada de computação, e resolve de uma vez aquela pergunta chata de diretoria sobre se a NSA colocou backdoor no TLS.

A tensão que fica

Aqui vem a parte que me incomoda de verdade, como operador. Humanos caçaram isso por 25 anos, seguiram pista errada de hash de frase engraçada, abriram bounty, falharam. O Claude resolveu em menos de 30 minutos quando perguntado do jeito certo. Isso escala para auditoria criptográfica ou foi sorte com busca brute force bem direcionada. Minha leitura é que foi as duas coisas. Modelo bom em reconhecer padrão de gerador antigo, mais capacidade de testar milhares de timestamps rápido, mais ausência de viés humano preso à história do Bob e Jerry. Mas isso resolve ou só move o gargalo. Porque agora a pergunta passa a ser outra. Quantos outros parâmetros mágicos em padrões antigos, DSA, Dual EC, IPsec, estão esperando o mesmo tratamento.

E tem o custo de confiança. É confortável dizer que era só timestamp e portanto é seguro. Só que timestamp como seed é, pelos padrões de hoje, uma prática terrível. Qualquer estudante de segurança sabe que relógio não é entropia. Na época passou batido porque o objetivo não era segredo, era só achar uma curva boa. Hoje, se alguém propusesse isso em review, seria barrado na hora. Então sim, afasta a teoria de backdoor sofisticado, mas expõe o quanto nossa base criptográfica nasceu de improviso. Vale a pena revirar tudo com IA agora. Provavelmente sim, mas com método, com reprodução aberta, sem transformar todo achado em manchete de que a IA quebrou a criptografia.

Conclusão

No fim, o mistério das curvas ECDSA do NIST era menos espionagem e mais preguiça de engenharia dos anos 90. Um lrand48 com hora Unix, um loop de tentativas, e 25 anos de especulação. A lição prática fica. Reproduza, documente, e siga usando P-256 sem paranoia extra. E a pergunta que fica no ar é incômoda. O que mais estamos tratando como complexo e malicioso, quando na verdade foi só alguém com pressa usando a função errada na hora errada.