As sementes misteriosas por trás das curvas do NIST nunca foram hashes, e o Claude descobriu isso em menos de meia hora

TL;DR. As sementes publicadas com as curvas P-192, P-224, P-256, P-384 e P-521 do NIST nunca foram saídas de hash. Elas vieram do gerador lrand48 da biblioteca C, semeado por timestamp Unix.

Principais conclusões

Um coeficiente que parecia derivado e uma semente que ninguém conseguia explicar. O ECDSA foi adotado pelo NIST em 2000 como parte do Padrão de Assinatura Digital FIPS 186-2.
Trinta minutos, nenhuma dica e um resultado que não era um hash. Em outubro de 2026, um funcionário curioso da Anthropic perguntou a um modelo interno de pesquisa se ele conseguiria descobrir como essas sementes foram geradas, sem apontar para a pista.
Como um scanner encontrou a impressão digital de um gerador dos anos 1990. O método merece atenção, porque é a parte que outras pessoas podem reutilizar.
Executando o gerador para trás para ler o relógio. Recuperar um estado diz como a semente foi produzida.

Uma questão que permaneceu aberta depois que a única pessoa que poderia tê-la respondido morreu em 2023 tinha uma resposta mundana: um gerador de números aleatórios dos anos 1990 inicializado a partir do relógio. Os autores dizem que essa resposta os deixa mais confiantes de que as curvas foram escolhidas honestamente, e não menos.

Resumo Executivo

O ECDSA foi adotado pelo NIST em 2000 como parte do Padrão de Assinatura Digital FIPS 186-2. As especificações publicaram parâmetros de "semente" cujo valor de hash deveria definir o coeficiente b da curva. A NSA forneceu as sementes sem explicação ou justificativa.

Em outubro de 2026, um funcionário da Anthropic pediu a um modelo interno de pesquisa para descobrir como as sementes foram geradas, sem apontar para a pista. Em menos de meia hora, o Claude descobriu que nenhuma das sementes era saída de hash. Elas eram a saída do lrand48, um gerador comum de números pseudoaleatórios inicializado a partir do relógio.

A descoberta não é uma quebra criptográfica, novo ataque ou fraqueza nas curvas ECDSA. Os autores dizem que isso os deixa mais confiantes de que as curvas foram escolhidas sem backdoors ou fraquezas intencionais.

O Claude também explicou os pontos base de seis curvas de maio de 1997 como provenientes do gerador de números aleatórios no FreeLIP, o pacote de aritmética de inteiros longos de Arjen Lenstra. Até onde os autores sabem, nenhum ponto base do NIST havia sido explicado antes.

Questões em aberto permanecem: como os pontos base de P-224, P-256, P-384 e P-521 foram selecionados, e quais critérios, se houver, estavam por trás das curvas candidatas puladas.

Um coeficiente que parecia derivado e uma semente que ninguém conseguia explicar #

O ECDSA foi adotado pelo NIST em 2000 como parte do Padrão de Assinatura Digital FIPS 186-2. As especificações para suas curvas traziam um parâmetro de "semente" cujo valor de hash é usado para definir o coeficiente b da curva. No papel, esse é um desenho tranquilizador. Se o coeficiente sai de um hash de uma semente publicada, diz o argumento, ninguém poderia ter ajustado a curva manualmente.

Esse argumento é tão bom quanto a semente. As sementes foram fornecidas pela NSA sem explicação ou justificativa, e essa lacuna é todo o problema. Um hash é uma porta de mão única: prova que o coeficiente decorreu da semente, e não diz nada sobre de onde a semente veio. Durante anos, as sementes permaneceram no padrão como constantes inexplicadas.

Havia uma história para preencher a lacuna. A versão mais conhecida tinha Jerry Solinas, um funcionário de longa data da NSA, gerando as sementes a partir de um hash de uma frase-senha bem-humorada. A fonte diz mais tarde que isso se revelou errado. Histórias assim tendem a ser acreditadas porque são específicas e um pouco charmosas, e porque ninguém pode contradizê-las. Elas deixam a desejar como evidência. A consequência prática foi que ninguém pôde verificar a afirmação, e buscas pela frase, construídas a partir dos rumores, não deram em nada.

A pessoa óbvia para perguntar era Solinas. Jerry morreu em 2023, e outros colegas da época não responderam. Isso deixou em aberto a questão de como essas sementes foram originalmente derivadas.

Eu diria que esta é a maneira certa de ver a situação: uma questão de proveniência que depende da memória de poucas pessoas é um arranjo frágil para um padrão que sustenta assinaturas. O interessante sobre o que aconteceu a seguir é que não precisou dessas memórias. A resposta estava sentada nas sementes publicadas, esperando que alguém testasse a hipótese certa.

Trinta minutos, nenhuma dica e um resultado que não era um hash #

Em outubro de 2026, um funcionário curioso da Anthropic perguntou a um modelo interno de pesquisa se ele conseguiria descobrir como essas sementes foram geradas, sem apontar para a pista. A formulação importa. O modelo não foi informado sobre o que procurar, e não recebeu a resposta para confirmar.

Em menos de meia hora, o Claude descobriu as origens das sementes P-192, P-224, P-256, P-384 e P-521 do NIST. O resultado é direto: nenhuma das sementes era resultado de qualquer algoritmo de hash. Elas eram a saída do gerador de números aleatórios lrand48 da biblioteca C.

Portanto, a história da frase-senha nunca iria ser encontrada, porque não havia frase-senha para encontrar. As sementes foram geradas por um gerador comum de números pseudoaleatórios inicializado a partir do relógio. É uma explicação sem glamour, e esse é precisamente o seu apelo: não precisa de segredo, nem de conhecimento especial, nem de constante inexplicada.

O mecanismo é simples de descrever. Cada iteração do algoritmo extrai 20 bytes do gerador como uma semente candidata. A contagem de iterações é o detalhe interessante, porque mostra que o processo foi uma busca e não um único sorteio. A P-256, por exemplo, exigiu 1842 iterações para produzir a semente padronizada. Quem executou esse programa deixou-o processar candidatos até que um produzisse uma curva que atendesse aos seus requisitos.

Os autores são cuidadosos sobre o que isso significa e o que não significa, e seu enquadramento merece ser repetido. Isto não é uma quebra criptográfica, novo ataque ou fraqueza nas curvas ECDSA. Não há nenhuma ação a ser tomada. Eles vão um passo além e dizem que isso os deixa mais confiantes de que as curvas foram escolhidas sem quaisquer backdoors ou fraquezas intencionais. Essa é uma conclusão cautelosa, e deve permanecer assim. A fonte a enquadra como a confiança dos autores, o que é diferente de uma prova da inocência das curvas. O que a descoberta oferece é um relato mundano e verificável no lugar de uma história inverificável.

Como um scanner encontrou a impressão digital de um gerador dos anos 1990 #

O método merece atenção, porque é a parte que outras pessoas podem reutilizar.

O Claude adivinhou que o software que gerou as curvas usava um PRNG que vinha com as bibliotecas C dos anos 1990. A fonte trata isso como um palpite, e foi um bom palpite. Ele estreitou uma busca ilimitada a uma lista curta de candidatos de uma época.

O Claude então escreveu um scanner. Ele deslizou ao longo de cada semente publicada um bit de cada vez e testou se pedaços adjacentes eram saídas consecutivas de um gerador da safra dos anos 1990. A varredura cobriu 34 combinações de gerador e fatias de saída. O acerto veio como um padrão nos bits superiores, um que aconteceria por acaso com probabilidade de 1/5810.

Esse padrão era uma assinatura do gerador congruencial linear lrand48, que retorna apenas os 31 bits superiores de um estado de 48 bits. Aqui o projeto do gerador vaza informação. Como o lrand48 esconde 17 bits de seu estado de 48 bits em cada chamada, a saída tem uma regularidade que uma sequência aleatória não mostraria, e um scanner construído para procurar essa regularidade pode encontrá-la.

Para recuperar o estado, o Claude pegou a primeira palavra e tentou todos os 2^17 valores dos 17 bits ocultos. Essa é uma busca pequena, e é barata porque o gerador é muito simples. Cada estado candidato podia ser verificado contra o próximo pedaço da semente, e o estado correto fez toda a sequência se alinhar.

As sementes das curvas primas foram mais difíceis, embora apenas ligeiramente. Elas vieram do mesmo gerador lrand48, mas mantiveram menos bits de cada saída. Menos bits visíveis significam menos base para ancorar um palpite, de modo que o truque de força bruta não se aplica de forma tão limpa. A resposta da fonte é que recuperar o estado de um gerador congruencial linear truncado é um problema clássico de reticulado, resolvido com o algoritmo de redução de base de Lenstra-Lenstra-Lovasz (LLL). Um modelo pôde reconhecer isso e aplicar uma ferramenta padrão a ele, sem nada exótico.

As cinco sementes de curvas primas do NIST, mais cinco outras do padrão ANSI X9.62, tinham todas o mesmo padrão: lrand48() >> 23. Dez sementes compartilhando uma regra de extração é uma forte evidência de um único processo por trás delas.

Então vem a verificação que separa um ajuste de sorte de um real. Cada estado recuperado de 48 bits regenera todos os 160 bits de sua semente, o que não acontece por acaso. Uma correspondência parcial poderia ser coincidência. Uma regeneração completa de cada bit é algo muito mais difícil de descartar, e é a razão pela qual o resultado pode ser declarado abertamente.

Executando o gerador para trás para ler o relógio #

Recuperar um estado diz como a semente foi produzida. Ainda não diz quando. Para isso, o Claude usou uma propriedade do gerador: ele roda para trás tão facilmente quanto para frente. Para cada semente, o Claude retrocedeu o estado até atingir a forma que a inicialização srand48 produziria, com os 16 bits inferiores iguais a 0x330E.

Essa forma é uma impressão digital própria. Se um estado recuperado pode ser rebobinado para algo com os 16 bits inferiores em 0x330E, o gerador foi iniciado da maneira padrão, a partir de um valor de semente passado para srand48. E o valor da semente, neste caso, era um horário. As sementes foram geradas usando o PRNG fraco semeado por timestamp Unix.

O pensamento interno do Claude na ocasião registrou o momento do reconhecimento: todos os bits superiores estavam limpos, 20 bits, com chance de 1e-6. É um detalhe pequeno, mas mostra o raciocínio trabalhando sobre os números à medida que apareciam, não sobre uma história montada depois.

As datas não eram todas limpas. As quatro inicializações de curvas binárias eram lidas como fevereiro de 1984, que não é uma data que alguém esperaria para um gerador em uso no final dos anos 1990. Com os timestamps dobrados, as inicializações das curvas binárias mapeiam para 17 de abril de 1998, duas semanas após a execução da P-224. A fonte conclui que o programa pode ter dividido o relógio pela metade. Isso é cauteloso, e deve ser: é uma explicação proposta para o motivo pelo qual os valores brutos são lidos como 1984, e uma duplicação que cai duas semanas após outra execução é sugestiva sem ser uma confirmação dos detalhes internos do programa.

Considero esta a parte mais persuasiva de todo o relato, por uma razão independente da criptografia. Uma história fabricada teria produzido datas arrumadas. Esta produziu uma data estranha, e depois uma correção que colocou as curvas binárias em uma sequência coerente com a execução da P-224. Dados confusos que se resolvem sob uma hipótese simples são a aparência da proveniência real.

Os pontos base também têm uma receita #

As sementes definem as curvas. Os pontos base são uma questão separada, e a fonte os trata separadamente.

Os pontos base de seis curvas geradas em maio de 1997 (P-192 e as cinco curvas de exemplo ANSI X9.62 prime192v2, prime192v3 e prime239v1 a v3) vêm do gerador de números aleatórios no FreeLIP, o pacote de aritmética de inteiros longos de Arjen Lenstra. As primeiras versões da biblioteca NTL de Victor Shoup traziam o mesmo código. Esse segundo fato importa para a verificação: o gerador existe como código publicado que outros podem ler, não como uma ferramenta privada.

A receita é curta. Semeie o gerador com um inteiro pequeno. Descarte sete saídas. Gere coordenadas x candidatas a partir de saídas de 26 bits reduzidas mod p. Repita essa geração de candidatos até que x esteja na curva.

O Claude encontrou as sementes do gerador: 20000 para P-192, 20420, 20507 e 20509 para prime239v1 a v3, e 20512 e 20517 para prime192v2 e v3. Esses são inteiros pequenos do tipo que uma pessoa digita em um programa, que é exatamente o que o primeiro passo da receita pede.

Os autores fazem aqui uma afirmação modesta que vale a pena citar em espírito: até onde sabem, nenhum ponto base do NIST foi explicado antes. A ressalva é deles, e é apropriada. Eles não estão afirmando ter feito um levantamento de cada documento já escrito, apenas o limite de seu conhecimento.

Então a receita para de funcionar. Os pontos base de P-224, P-256, P-384 e P-521 não se encaixam nesta receita, e os autores não conseguiram explicar como foram selecionados. Um texto que passasse por cima disso pareceria mais arrumado, e os autores deixaram isso lá. A explicação cobre seis curvas de maio de 1997 e deixa quatro dos pontos base das curvas primas do NIST sem explicação.

Candidatas que foram ignoradas #

A última descoberta é a que tem maior probabilidade de iniciar discussões, por isso vale a pena lê-la com precisão.

Para a P-256, a semente publicada é a candidata 1842. Mas a candidata 876 da mesma execução também fornece uma curva de ordem prima do tamanho certo, com parâmetros escolhidos da mesma maneira que na curva publicada. Em outras palavras, o processo passou por cima de uma curva que, à primeira vista, teria sido aceitável.

Não é um caso isolado. A execução da P-224 passou por cima de três dessas curvas, e as duas execuções por trás das curvas de exemplo ANSI X9.62 passaram por cima de mais sete.

Os autores são diretos sobre o que não sabem. Eles não sabem quais critérios podem ter sido usados para pular curvas, ou se foi um artefato não intencional. Essa é uma limitação, declarada como tal, e a ressalva sobre "artefato não intencional" é a posição honesta: os dados mostram que candidatas foram puladas e não mostram o porquê.

Eles então oferecem um julgamento. Como o número de candidatas puladas é pequeno, eles não acreditam que seja plausível que curvas enfraquecidas tenham sido selecionadas. Esse é um raciocínio cauteloso sobre plausibilidade, e repousa na contagem. Se um processo pula apenas um punhado de candidatas no total, há pouco espaço para procurar uma fraqueza.

Uma ressalva permanece, e a fonte a declara como uma possibilidade e não uma descoberta. Ainda é concebível que essas curvas tenham sido selecionadas para ter uma propriedade específica, em princípio, buscando ao longo de timestamps para o gerador de números aleatórios. Isso é especulação, sinalizada como tal. Não deve ser lida como evidência de nada, e tampouco deve ser silenciosamente descartada. Um relato justo a mantém na mesa como uma rota não excluída, observando ao mesmo tempo que os autores consideram implausíveis curvas enfraquecidas.

O que o resultado muda, e o que deixa em aberto #

Comece pelo que ele não muda. As curvas não estão quebradas. A fonte diz isso duas vezes, em palavras diferentes, e não há nenhuma ação a ser tomada. Qualquer pessoa que leia isso como uma razão para arrancar a P-256 entendeu errado.

O que ele muda é o status de uma velha dúvida. Enquanto as sementes permaneceram inexplicadas, "fornecidas pela NSA sem explicação" era um ponto de interrogação permanente sobre um padrão. Esse ponto de interrogação agora tem uma resposta concreta. As sementes não eram hashes inescrutáveis de uma frase secreta. Eram saídas do lrand48 de um programa semeado pelo relógio, regenerando cada bit de cada semente a partir de um estado recuperado. Uma explicação que qualquer pessoa com as sementes publicadas pode testar supera um rumor que ninguém consegue testar.

Há um ponto aqui para fundadores e engenheiros que constroem sobre padrões criptográficos. Afirmações de proveniência são baratas de fazer e caras de verificar, e a verificação descrita aqui levou menos de meia hora uma vez que a pergunta certa foi feita. O scanner, a busca de 2^17 e a redução de reticulado são todos movimentos padrão. O que faltou durante anos foi alguém fazendo o trabalho sem glamour de testá-los contra os números publicados.

Eu também resistiria à tentação de exagerar o método. A fonte relata o resultado de uma equipe em um conjunto específico de sementes. Ela não afirma que a mesma abordagem quebrará cada constante inexplicada em cada padrão, e não afirmarei isso por eles. O que ela demonstra é mais estreito e, a meu ver, mais útil: quando a origem de um parâmetro é um mistério, um modelo cuidadoso com um palpite plausível sobre o ferramental da época pode testar o palpite rapidamente e mostrar seu trabalho.

Os assuntos inacabados são claros o suficiente para constituir uma agenda de pesquisa. Quatro pontos base, os de P-224, P-256, P-384 e P-521, ainda carecem de explicação. As candidatas puladas, como a 876 contra a 1842 publicada para a P-256, carecem de um critério declarado, e ninguém sabe ainda se o pulo foi deliberado ou um artefato. Se essas respostas sobrevivem em códigos-fonte antigos, nas memórias de colegas sobreviventes ou no mesmo tipo de caça a padrões que decifrou as sementes é a questão em aberto. As sementes levaram meia hora; os pontos base já resistiram a essa abordagem uma vez.

Perguntas Frequentes #

Essa descoberta quebra curvas ECDSA do NIST como P-256 ou P-384?

Não. Descobrir que as sementes das curvas foram geradas pelo lrand48 em vez de um hash de frase-senha não introduz nenhuma quebra criptográfica, novo ataque ou fraqueza matemática nas curvas ECDSA, e nenhuma ação de remediação ou migração é necessária por causa dessa descoberta.

Como as sementes das curvas primas do NIST foram realmente geradas?

Cada semente de 160 bits foi produzida chamando o gerador congruencial linear lrand48 da biblioteca padrão C (especificamente lrand48() >> 23 para as cinco curvas primas do NIST e cinco curvas ANSI X9.62), inicializado via srand48 com um timestamp Unix. Recuperar o estado interno de 48 bits via redução de reticulado de Lenstra-Lenstra-Lovasz (LLL) regenera todos os 160 bits de cada semente publicada.

O que permanece inexplicado sobre os parâmetros das curvas elípticas do NIST?

Embora os pontos base da P-192 e de cinco curvas ANSI X9.62 tenham sido rastreados até o gerador de números aleatórios no pacote FreeLIP de Arjen Lenstra semeado com inteiros pequenos, os pontos base de P-224, P-256, P-384 e P-521 não correspondem a essa receita, e os critérios para pular curvas candidatas anteriores de ordem prima (como a candidata 876 antes da candidata 1842 na P-256) permanecem desconhecidos.

Referências #

Anthropic Frontier Red Team, (2026). Claude reveals ECDSA curve origins ⧉. Anthropic.
National Institute of Standards and Technology, (2000). FIPS PUB 186-2: Digital Signature Standard (DSS) ⧉. NIST.
Victor Shoup, (2024). NTL: A Library for doing Number Theory ⧉. libntl.org.

Última revisão 2026-11-01.

Republicar este artigo

As sementes misteriosas por trás das curvas do NIST nunca foram hashes, e o Claude descobriu isso em menos de meia hora — Sebastien Rousseau

As sementes publicadas com as curvas P-192, P-224, P-256, P-384 e P-521 do NIST nunca foram saídas de hash. Elas vieram do gerador lrand48 da biblioteca C, semeado por timestamp Unix.

Este artigo está licenciado sob Creative Commons Attribution 4.0 International. A republicação exige atribuição à URL canônica.

As sementes misteriosas por trás das curvas do NIST nunca foram hashes, e o Claude descobriu isso em menos de meia hora — Sebastien Rousseau

As sementes publicadas com as curvas P-192, P-224, P-256, P-384 e P-521 do NIST nunca foram saídas de hash. Elas vieram do gerador lrand48 da biblioteca C, semeado por timestamp Unix.

Originally published at https://sebastienrousseau.com/pt-br/2026-10-26-sementes-misteriosas-por-tras-curvas-nist/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER