I semi misteriosi dietro le curve del NIST non sono mai stati degli hash, e Claude lo ha scoperto in meno di mezz'ora

TL;DR. I semi pubblicati con le curve P-192, P-224, P-256, P-384 e P-521 del NIST non sono mai stati output di funzioni hash. Provenivano dal generatore lrand48 della libreria C, inizializzato tramite...

Punti chiave

Un coefficiente che sembrava derivato e un seme di cui nessuno sapeva rendere conto. ECDSA è stato adottato dal NIST nel 2000 come parte del Digital Signature Standard FIPS 186-2.
Trenta minuti, nessun suggerimento e un risultato che non era un hash. Nell'ottobre 2026, un curioso dipendente di Anthropic ha chiesto a un modello di ricerca interno se fosse in grado di capire come fossero stati generati quei semi, senza indicare l'indizio.
Come uno scanner ha trovato l'impronta digitale di un generatore degli anni Novanta. Il metodo merita attenzione, perché è la parte che altri possono riutilizzare.
Far girare il generatore all'indietro per leggere l'orologio. Recuperare uno stato ti dice come è stato prodotto il seme.

Una domanda rimasta aperta dopo la morte nel 2023 dell'unica persona che avrebbe potuto rispondere aveva una risposta banale: un generatore di numeri casuali degli anni Novanta inizializzato dall'orologio di sistema. Gli autori affermano che questa risposta li rende più fiduciosi sul fatto che le curve siano state scelte onestamente, non meno.

Sintesi esecutiva

ECDSA è stato adottato dal NIST nel 2000 come parte del Digital Signature Standard FIPS 186-2. Le specifiche pubblicavano parametri "seed" il cui valore di hash doveva definire il coefficiente b della curva. La NSA fornì i semi senza alcuna spiegazione o giustificazione.

Nell'ottobre 2026, un dipendente di Anthropic ha chiesto a un modello di ricerca interno di capire come fossero stati generati i semi, senza indicare l'indizio. In meno di mezz'ora, Claude ha scoperto che nessuno dei semi era l'output di un hash. Erano l'output di lrand48, un comune generatore di numeri pseudocasuali inizializzato dall'orologio di sistema.

La scoperta non rappresenta una violazione crittografica, un nuovo attacco o una debolezza nelle curve ECDSA. Gli autori affermano che ciò li rende più fiduciosi sul fatto che le curve siano state scelte senza backdoor o debolezze intenzionali.

Claude ha inoltre spiegato che i punti base di sei curve del maggio 1997 provenivano dal generatore di numeri casuali di FreeLIP, il pacchetto di aritmetica per interi lunghi di Arjen Lenstra. Per quanto risulta agli autori, nessun punto base del NIST era mai stato spiegato prima.

Restano questioni aperte: come siano stati selezionati i punti base di P-224, P-256, P-384 e P-521, e quali criteri, se ve ne sono stati, abbiano guidato l'esclusione delle curve candidate saltate.

Un coefficiente che sembrava derivato e un seme di cui nessuno sapeva rendere conto #

ECDSA è stato adottato dal NIST nel 2000 come parte del Digital Signature Standard FIPS 186-2. Le specifiche per le sue curve riportavano un parametro "seed" il cui valore di hash viene utilizzato per definire il coefficiente b della curva. Sulla carta, è un'architettura rassicurante. Se il coefficiente esce dall'hash di un seme pubblicato, sostiene l'argomento, nessuno avrebbe potuto calibrare la curva a mano.

Tale argomento vale solo quanto vale il seme. I semi furono forniti dalla NSA senza alcuna spiegazione o giustificazione, e quel vuoto costituisce l'intero problema. Un hash è una porta a senso unico: dimostra che il coefficiente è derivato dal seme, ma non dice nulla su da dove provenga il seme. Per anni i semi sono rimasti nello standard come costanti inspiegate.

C'era una storia per riempire quel vuoto. La versione più nota attribuiva a Jerry Solinas, storico dipendente della NSA, la generazione dei semi a partire dall'hash di una passphrase umoristica. La fonte afferma più avanti che ciò si è rivelato falso. Storie del genere tendono a essere credute perché sono specifiche e un po' affascinanti, e perché nessuno può smentirle. Come prove, però, non reggono. La conseguenza pratica è stata che nessuno poteva verificare l'affermazione, e le ricerche della frase, costruite a partire dalle voci di corridoio, si erano concluse con un nulla di fatto.

La persona ovvia a cui chiedere era Solinas. Jerry è morto nel 2023 e altri colleghi dell'epoca non hanno risposto. Ciò ha lasciato aperta la questione di come questi semi fossero stati originariamente ricavati.

Sosterrei che questo sia il modo giusto di leggere la situazione: una questione di provenienza che dipende dai ricordi di poche persone è un assetto fragile per uno standard che regge le firme digitali. L'aspetto interessante di ciò che è accaduto dopo è che non c'è stato bisogno di quei ricordi. La risposta si trovava già nei semi pubblicati, in attesa che qualcuno mettesse alla prova l'ipotesi giusta.

Trenta minuti, nessun suggerimento e un risultato che non era un hash #

Nell'ottobre 2026, un curioso dipendente di Anthropic ha chiesto a un modello di ricerca interno se fosse in grado di capire come fossero stati generati quei semi, senza indicare l'indizio. La formulazione conta. Al modello non è stato detto cosa cercare, né gli è stata consegnata la risposta da confermare.

In meno di mezz'ora, Claude ha scoperto le origini dei semi P-192, P-224, P-256, P-384 e P-521 del NIST. Il risultato è netto: nessuno dei semi era il risultato di un algoritmo di hash. Erano l'output del generatore di numeri casuali lrand48 della libreria C.

Pertanto, la storia della passphrase non sarebbe mai stata confermata, perché non c'era alcuna passphrase da trovare. I semi sono stati generati da un comune generatore di numeri pseudocasuali inizializzato dall'orologio. È una spiegazione poco affascinante, ed è proprio questo il suo pregio: non richiede alcun segreto, alcuna conoscenza speciale e alcuna costante inspiegata.

Il meccanismo è semplice da descrivere. Ogni iterazione dell'algoritmo estrae 20 byte dal generatore come seme candidato. Il conteggio delle iterazioni è il dettaglio interessante, perché mostra che il processo è stato una ricerca e non una singola estrazione. P-256, ad esempio, ha richiesto 1842 iterazioni per produrre il seme standardizzato. Chiunque abbia eseguito questo programma lo ha lasciato macinare candidati finché uno non ha prodotto una curva che soddisfaceva i requisiti richiesti.

Gli autori sono cauti su ciò che questo significa e non significa, e vale la pena ripetere la loro impostazione. Non si tratta di una violazione crittografica, di un nuovo attacco o di una debolezza nelle curve ECDSA. Non c'è alcuna azione da intraprendere. Essi fanno un passo in più e affermano che ciò li rende più fiduciosi sul fatto che le curve siano state scelte senza backdoor o debolezze intenzionali. Questa è una conclusione formulata con cautela, e tale deve rimanere. La fonte la inquadra come la fiducia degli autori, che è cosa diversa da una dimostrazione dell'innocenza delle curve. Ciò che la scoperta fornisce è un resoconto banale e verificabile al posto di una storia inverificabile.

Come uno scanner ha trovato l'impronta digitale di un generatore degli anni Novanta #

Il metodo merita attenzione, perché è la parte che altri possono riutilizzare.

Claude ha ipotizzato che il software che aveva generato le curve utilizzasse un PRNG distribuito con le librerie C degli anni Novanta. La fonte tratta questa mossa come un'ipotesi, ed è stata una buona ipotesi. Ha ristretto una ricerca illimitata a una breve lista di candidati appartenenti a un'epoca precisa.

Claude ha poi scritto uno scanner. Ha fatto scorrere ciascun seme pubblicato un bit alla volta e ha verificato se blocchi adiacenti fossero output consecutivi di un generatore risalente agli anni Novanta. La scansione ha coperto 34 combinazioni di generatori e porzioni di output. Il riscontro positivo è arrivato sotto forma di un pattern nei bit superiori, un evento che si verificherebbe per caso con probabilità 1/5810.

Quel pattern era una firma del generatore congruenziale lineare lrand48, che restituisce solo i 31 bit superiori di uno stato a 48 bit. Qui il design del generatore tradisce la sua presenza. Poiché lrand48 nasconde 17 bit del suo stato a 48 bit a ogni chiamata, l'output presenta una regolarità che una stringa casuale non mostrerebbe, e uno scanner costruito per cercare tale regolarità è in grado di trovarla.

Per recuperare lo stato, Claude ha preso la prima parola e ha provato tutti i 2^17 valori dei 17 bit nascosti. È una ricerca piccola, ed è economica perché il generatore è molto semplice. Ogni stato candidato poteva essere verificato rispetto al blocco successivo del seme, e quello giusto ha fatto allineare l'intera sequenza.

I semi delle curve su campi primi erano più difficili, anche se solo leggermente. Provenivano dallo stesso generatore lrand48 ma conservavano meno bit di ciascun output. Meno bit visibili significano meno punti d'appoggio per ancorare un'ipotesi, per cui il trucco della forza bruta non si applica più in modo così pulito. La risposta della fonte è che recuperare lo stato di un generatore congruenziale lineare troncato è un problema sui reticoli da manuale, risolto con l'algoritmo di riduzione delle basi di Lenstra-Lenstra-Lovasz (LLL). Un modello poteva riconoscerlo e applicarvi uno strumento standard, senza nulla di esotico.

I cinque semi delle curve prime del NIST, più altri cinque dello standard ANSI X9.62, presentavano tutti lo stesso schema: lrand48() >> 23. Dieci semi che condividono un'unica regola di estrazione costituiscono una prova solida dell'esistenza di un singolo processo dietro di essi.

Poi arriva la verifica che separa una coincidenza fortunata da un riscontro reale. Ciascuno stato a 48 bit recuperato rigenera tutti i 160 bit del proprio seme, il che non avviene per caso. Una corrispondenza parziale potrebbe essere una coincidenza. Una rigenerazione completa di ogni singolo bit è molto più difficile da liquidare, ed è la ragione per cui il risultato può essere enunciato chiaramente.

Far girare il generatore all'indietro per leggere l'orologio #

Recuperare uno stato ti dice come è stato prodotto il seme. Non ti dice ancora quando. Per questo, Claude ha sfruttato una proprietà del generatore: gira all'indietro con la stessa facilità con cui gira in avanti. Per ciascun seme, Claude ha fatto retrocedere lo stato passo dopo passo fino a raggiungere la forma che produrrebbe l'inizializzazione con srand48, con i 16 bit inferiori uguali a 0x330E.

Quella forma è di per sé un'impronta digitale. Se uno stato recuperato può essere riavvolto fino a un valore avente i 16 bit inferiori pari a 0x330E, il generatore è stato avviato nel modo standard, a partire da un valore di seme passato a srand48. E il valore del seme, in questo caso, era un orario. I semi sono stati generati utilizzando il PRNG debole inizializzato tramite timestamp Unix.

Il ragionamento interno di Claude in quel momento ha registrato l'istante del riconoscimento: tutti i bit superiori erano azzerati, 20 bit, con probabilità 1e-6. È un piccolo dettaglio, ma mostra il ragionamento al lavoro sui numeri così come apparivano, non su una storia confezionata a posteriori.

Le date non erano tutte pulite. Le quattro inizializzazioni delle curve binarie risultavano come febbraio 1984, che non è una data che chiunque si aspetterebbe per un generatore in uso alla fine degli anni Novanta. Raddoppiando i timestamp, le inizializzazioni delle curve binarie corrispondono al 17 aprile 1998, due settimane dopo l'esecuzione di P-224. La fonte conclude che il programma potrebbe aver dimezzato il valore dell'orologio. Questa è un'ipotesi cauta, e tale deve essere: è una spiegazione proposta del perché i valori grezzi si leggano come 1984, e un raddoppio che cade due settimane dopo un'altra esecuzione è suggestivo senza però costituire una conferma del funzionamento interno del programma.

Trovo che questa sia la parte più persuasiva dell'intero resoconto, per una ragione indipendente dalla crittografia. Una storia inventata avrebbe prodotto date ordinate. Questa ne ha prodotta una anomala, seguita da una correzione che ha collocato le curve binarie in una sequenza coerente con l'esecuzione di P-224. Dati disordinati che si risolvono sotto un'ipotesi semplice sono esattamente ciò a cui somiglia la vera provenienza.

Anche i punti base hanno una ricetta #

I semi definiscono le curve. I punti base sono una questione distinta, e la fonte li tratta separatamente.

I punti base di sei curve generate nel maggio 1997 (P-192 e le cinque curve di esempio ANSI X9.62 prime192v2, prime192v3 e da prime239v1 a v3) provengono dal generatore di numeri casuali di FreeLIP, il pacchetto di aritmetica per interi lunghi di Arjen Lenstra. Le prime versioni della libreria NTL di Victor Shoup includevano lo stesso codice. Questo secondo fatto conta ai fini della verifica: il generatore esiste come codice pubblicato che altri possono leggere, non come uno strumento privato.

La ricetta è breve. Si inizializza il generatore con un intero piccolo. Si scartano sette output. Si generano coordinate x candidate a partire da output a 26 bit ridotti modulo p. Si ripete tale generazione di candidati finché x non giace sulla curva.

Claude ha trovato i semi del generatore: 20000 per P-192, 20420, 20507 e 20509 per prime239v1-v3, e 20512 e 20517 per prime192v2 e v3. Sono interi piccoli del tipo che una persona digita in un programma, il che corrisponde esattamente a quanto richiesto dal primo passo della ricetta.

Gli autori avanzano qui un'affermazione modesta che merita di essere citata nello spirito: per quanto ne sanno, nessun punto base del NIST è mai stato spiegato prima. La cautela è loro, ed è appropriata. Non stanno rivendicando una rassegna di ogni documento mai scritto, ma solo il limite della loro conoscenza.

Poi la ricetta smette di funzionare. I punti base di P-224, P-256, P-384 e P-521 non seguono questa ricetta, e gli autori non sono stati in grado di spiegare come siano stati selezionati. Un resoconto che avesse sorvolato su questo punto sarebbe apparso più ordinato, ma gli autori lo hanno lasciato. La spiegazione copre sei curve del maggio 1997 e lascia inspiegati i punti base di quattro delle curve prime del NIST.

Candidate che sono state scartate #

L'ultima scoperta è quella che ha più probabilità di innescare discussioni, per cui vale la pena leggerla con precisione.

Per P-256, il seme pubblicato è il candidato 1842. Ma anche il candidato 876 della stessa esecuzione fornisce una curva di ordine primo della dimensione giusta, con parametri scelti nello stesso modo della curva pubblicata. In altre parole, il processo ha scartato una curva che, a prima vista, sarebbe stata accettabile.

Non è un caso isolato. L'esecuzione di P-224 ha saltato tre curve di questo tipo, e le due esecuzioni dietro le curve di esempio ANSI X9.62 ne hanno saltate altre sette.

Gli autori sono espliciti su ciò che non sanno. Non sanno quali criteri possano essere stati usati per saltare le curve, o se si sia trattato di un artefatto non intenzionale. Questa è una limitazione, dichiarata come tale, e la cautela sull'"artefatto non intenzionale" rappresenta la posizione onesta: i dati mostrano che delle candidate sono state saltate, ma non mostrano il perché.

Offrono poi una valutazione. Poiché il numero di candidate saltate è esiguo, non ritengono plausibile che siano state selezionate curve indebolite. Si tratta di un ragionamento cauto sulla plausibilità, e poggia sul conteggio. Se un processo salta solo una manciata di candidate in totale, c'è ben poco margine in cui cercare una debolezza.

Rimane un'avvertenza, e la fonte la enuncia come una possibilità e non come un risultato accertato. È ancora concepibile che queste curve siano state selezionate in linea di principio per avere una proprietà specifica effettuando una ricerca sui timestamp passati al generatore di numeri casuali. Questa è una speculazione, segnalata come tale. Non va letta come prova di alcunché, ma non va nemmeno lasciata cadere sotto silenzio. Un resoconto equo la mantiene sul tavolo come una via non esclusa, pur notando che gli autori considerano implausibile l'ipotesi di curve indebolite.

Cosa cambia il risultato, e cosa lascia aperto #

Partiamo da ciò che non cambia. Le curve non sono compromesse. La fonte lo dice due volte, con parole diverse, e non c'è alcuna azione da intraprendere. Chiunque legga tutto questo come un motivo per dismettere P-256 ha frainteso il testo.

Ciò che cambia è lo stato di un vecchio dubbio. Finché i semi sono rimasti inspiegati, la dicitura "forniti dalla NSA senza spiegazione" ha rappresentato un punto interrogativo permanente su uno standard. Quel punto interrogativo ha ora una risposta concreta. I semi non erano hash imperscrutabili di una frase segreta. Erano l'output di lrand48 prodotto da un programma inizializzato con l'orologio, in grado di rigenerare ogni singolo bit di ciascun seme a partire da uno stato recuperato. Una spiegazione che chiunque disponga dei semi pubblicati può verificare batte una voce di corridoio che nessuno può controllare.

C'è uno spunto qui per fondatori e ingegneri che costruiscono su standard crittografici. Le affermazioni sulla provenienza sono economiche da fare e costose da verificare, ma la verifica descritta qui ha richiesto meno di mezz'ora una volta posta la domanda giusta. Lo scanner, la ricerca 2^17 e la riduzione dei reticoli sono tutte mosse standard. Ciò che è mancato per anni è stato qualcuno che facesse il lavoro poco appariscente di provarle sui numeri pubblicati.

Resisterei anche alla tentazione di sopravvalutare il metodo. La fonte riporta il risultato di un team su uno specifico insieme di semi. Non pretende che lo stesso approccio possa decifrare ogni costante inspiegata in ogni standard, e non lo pretenderò io per loro. Ciò che dimostra è più circoscritto e, a mio avviso, più utile: quando l'origine di un parametro è un mistero, un modello accurato dotato di un'ipotesi plausibile sugli strumenti dell'epoca può testare rapidamente l'ipotesi e mostrare i propri passaggi.

Le questioni rimaste in sospeso sono abbastanza chiare da costituire un'agenda di ricerca. Quattro punti base, quelli di P-224, P-256, P-384 e P-521, sono ancora privi di spiegazione. Le candidate saltate, come la 876 rispetto alla 1842 pubblicata per P-256, mancano di un criterio dichiarato, e nessuno sa ancora se il salto sia stato deliberato o frutto di un artefatto. Se tali risposte sopravvivano in vecchi codici sorgente, nei ricordi dei colleghi superstiti o nello stesso tipo di caccia ai pattern che ha svelato i semi resta una domanda aperta. I semi hanno richiesto mezz'ora; i punti base hanno già resistito una volta a questo approccio.

Domande frequenti #

Questa scoperta compromette le curve ECDSA del NIST come P-256 o P-384?

No. Scoprire che i semi delle curve sono stati generati da lrand48 anziché dall'hash di una passphrase non introduce alcuna violazione crittografica, nuovo attacco o debolezza matematica nelle curve ECDSA, e non è richiesta alcuna azione di mitigazione o migrazione a seguito di questo risultato.

Come sono stati effettivamente generati i semi delle curve prime del NIST?

Ciascun seme a 160 bit è stato prodotto invocando il generatore congruenziale lineare lrand48 della libreria standard C (nello specifico lrand48() >> 23 per le cinque curve prime del NIST e cinque curve ANSI X9.62), inizializzato tramite srand48 con un timestamp Unix. Il recupero dello stato interno a 48 bit tramite riduzione dei reticoli di Lenstra-Lenstra-Lovasz (LLL) rigenera tutti i 160 bit di ciascun seme pubblicato.

Cosa rimane inspiegato riguardo ai parametri delle curve ellittiche del NIST?

Mentre i punti base di P-192 e di cinque curve ANSI X9.62 sono stati ricondotti al generatore di numeri casuali del pacchetto FreeLIP di Arjen Lenstra inizializzato con interi piccoli, i punti base di P-224, P-256, P-384 e P-521 non corrispondono a tale ricetta, e i criteri per cui sono state saltate precedenti curve candidate di ordine primo (come la candidata 876 prima della candidata 1842 in P-256) restano sconosciuti.

References #

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.

Ultima revisione 2026-11-01.

Ripubblica questo articolo

I semi misteriosi dietro le curve del NIST non sono mai stati degli hash, e Claude lo ha scoperto in meno di mezz'ora — Sebastien Rousseau

I semi pubblicati con le curve P-192, P-224, P-256, P-384 e P-521 del NIST non sono mai stati output di funzioni hash. Provenivano dal generatore lrand48 della libreria C, inizializzato tramite...

Questo articolo è pubblicato con licenza Creative Commons Attribution 4.0 International. La ripubblicazione richiede l'attribuzione all'URL canonico.

I semi misteriosi dietro le curve del NIST non sono mai stati degli hash, e Claude lo ha scoperto in meno di mezz'ora — Sebastien Rousseau

I semi pubblicati con le curve P-192, P-224, P-256, P-384 e P-521 del NIST non sono mai stati output di funzioni hash. Provenivano dal generatore lrand48 della libreria C, inizializzato tramite...

Originally published at https://sebastienrousseau.com/it/2026-10-26-semi-misteriosi-dietro-curve-nist-non/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER