Las semillas misteriosas detrás de las curvas del NIST nunca fueron hashes, y Claude lo descubrió en menos de media hora

TL;DR. Las semillas publicadas con las curvas P-192, P-224, P-256, P-384 y P-521 del NIST nunca fueron resultados de funciones hash. Procedían del generador lrand48 de la biblioteca de C, inicializado con...

Puntos clave

Un coeficiente que parecía derivado y una semilla que nadie sabía explicar. ECDSA fue adoptado por el NIST en el año 2000 como parte del Estándar de Firma Digital FIPS 186-2.
Treinta minutos, ninguna pista y un resultado que no era un hash. En octubre de 2026, un empleado curioso de Anthropic preguntó a un modelo de investigación interno si podía averiguar cómo se generaron esas semillas, sin señalarle la pista.
Cómo un escáner encontró la huella dactilar de un generador de los años noventa. El método merece atención, porque es la parte que otras personas pueden reutilizar.
Hacer retroceder el generador para leer el reloj. Recuperar un estado te dice cómo se produjo la semilla.

Una pregunta que seguía abierta tras la muerte en 2023 de la única persona que podría haberla respondido tenía una respuesta mundana: un generador de números aleatorios de los años noventa inicializado a partir del reloj. Los autores afirman que esa respuesta les da más confianza en que las curvas se eligieron honestamente, no menos.

Resumen ejecutivo

El estándar ECDSA fue adoptado por el NIST en el año 2000 como parte del Estándar de Firma Digital FIPS 186-2. Las especificaciones publicaban parámetros "semilla" (seed) cuyo valor hash debía definir el coeficiente b de la curva. La NSA proporcionó las semillas sin explicación ni justificación.

En octubre de 2026, un empleado de Anthropic preguntó a un modelo de investigación interno si podía averiguar cómo se generaron esas semillas, sin señalarle la pista. En menos de media hora, Claude descubrió que ninguna de las semillas era el resultado de un hash. Eran la salida de lrand48, un generador común de números pseudoaleatorios inicializado a partir del reloj.

El hallazgo no supone una rotura criptográfica, un nuevo ataque ni una debilidad en las curvas ECDSA. Los autores dicen que les hace confiar más en que las curvas se eligieron sin puertas traseras ni debilidades intencionadas.

Claude también explicó que los puntos base de seis curvas de mayo de 1997 procedían del generador de números aleatorios de FreeLIP, el paquete de aritmética de enteros largos de Arjen Lenstra. Hasta donde saben los autores, ningún punto base del NIST había sido explicado antes.

Quedan preguntas abiertas: cómo se seleccionaron los puntos base de P-224, P-256, P-384 y P-521, y qué criterios, si los hubo, motivaron el descarte de ciertas curvas candidatas.

Un coeficiente que parecía derivado y una semilla que nadie sabía explicar #

ECDSA fue adoptado por el NIST en el año 2000 como parte del Estándar de Firma Digital FIPS 186-2. Las especificaciones de sus curvas incluían un parámetro "semilla" cuyo valor hash se utiliza para definir el coeficiente b de la curva. Sobre el papel, ese es un diseño tranquilizador. Si el coeficiente sale del hash de una semilla publicada, reza el argumento, nadie podría haber ajustado la curva a mano.

Ese argumento es tan bueno como lo sea la semilla. Las semillas fueron proporcionadas por la NSA sin explicación ni justificación, y ese vacío es todo el problema. Un hash es una puerta de un solo sentido: demuestra que el coeficiente se obtuvo a partir de la semilla, pero no dice nada sobre de dónde salió la semilla. Durante años, las semillas permanecieron en el estándar como constantes inexplicadas.

Había una historia para llenar ese vacío. La versión más conocida situaba a Jerry Solinas, un veterano empleado de la NSA, generando las semillas a partir del hash de una frase de paso humorística. La fuente señala más adelante que esto resultó ser falso. Historias así suelen creerse porque son concretas y tienen cierto encanto, y porque nadie puede contradecirlas. Como prueba, se quedan cortas. La consecuencia práctica fue que nadie pudo verificar la afirmación, y las búsquedas de la frase, construidas a partir de los rumores, habían resultado infructuosas.

La persona obvia a quien preguntar era Solinas. Jerry falleció en 2023, y otros colegas de aquella época no respondieron. Eso dejó abierta la cuestión de cómo se obtuvieron originalmente estas semillas.

Yo diría que esta es la forma correcta de ver la situación: una cuestión de procedencia que depende de los recuerdos de unas pocas personas es un arreglo frágil para un estándar que sustenta firmas digitales. Lo interesante de lo que ocurrió a continuación es que no necesitó esos recuerdos. La respuesta estaba ahí mismo, en las semillas publicadas, esperando a que alguien pusiera a prueba la hipótesis adecuada.

Treinta minutos, ninguna pista y un resultado que no era un hash #

En octubre de 2026, un empleado curioso de Anthropic preguntó a un modelo de investigación interno si podía averiguar cómo se generaron esas semillas, sin señalarle la pista. La formulación importa. Al modelo no se le dijo qué debía buscar, ni se le entregó la respuesta para que la confirmara.

En menos de media hora, Claude descubrió el origen de las semillas P-192, P-224, P-256, P-384 y P-521 del NIST. El resultado es contundente: ninguna de las semillas era el resultado de ningún algoritmo hash. Eran la salida del generador de números aleatorios lrand48 de la biblioteca de C.

Así que la historia de la frase de paso nunca iba a encontrarse, porque no había ninguna frase de paso que encontrar. Las semillas fueron generadas por un generador común de números pseudoaleatorios inicializado a partir del reloj. Es una explicación poco glamurosa, y ese es precisamente su atractivo: no necesita ningún secreto, ningún conocimiento especial ni ninguna constante inexplicada.

El mecanismo es sencillo de describir. Cada iteración del algoritmo extrae 20 bytes del generador como semilla candidata. El recuento de iteraciones es el detalle interesante, porque muestra que el proceso fue una búsqueda y no una única extracción. P-256, por ejemplo, requirió 1842 iteraciones para producir la semilla estandarizada. Quienquiera que ejecutara este programa lo dejó procesar candidatos hasta que uno produjo una curva que cumplía sus requisitos.

Los autores son cuidadosos respecto a lo que esto significa y lo que no, y vale la pena repetir su planteamiento. Esto no es una rotura criptográfica, un nuevo ataque ni una debilidad en las curvas ECDSA. No hay ninguna medida que tomar. Van un paso más allá y dicen que esto les da más confianza en que las curvas fueron elegidas sin puertas traseras ni debilidades intencionadas. Esa es una conclusión matizada, y debe seguir siéndolo. La fuente la plantea como la confianza de los autores, lo cual es distinto de una demostración de la inocencia de las curvas. Lo que aporta el hallazgo es una explicación mundana y verificable en lugar de una historia inverificable.

Cómo un escáner encontró la huella dactilar de un generador de los años noventa #

El método merece atención, porque es la parte que otras personas pueden reutilizar.

Claude conjeturó que el software que generó las curvas utilizaba un PRNG incluido en las bibliotecas de C de los años noventa. La fuente trata esto como una conjetura, y fue una buena conjetura. Redujo una búsqueda ilimitada a una lista corta de candidatos de una época concreta.

A continuación, Claude escribió un escáner. Se deslizó a lo largo de cada semilla publicada bit a bit y comprobó si los fragmentos adyacentes eran salidas consecutivas de un generador de la época de los noventa. El barrido cubrió 34 combinaciones de generadores y recortes de salida.El acierto llegó como un patrón en los bits superiores, uno que ocurriría por azar con una probabilidad de 1/5810.

Ese patrón era una firma del generador congruencial lineal lrand48, que solo devuelve los 31 bits superiores de un estado de 48 bits. Aquí el diseño del generador deja escapar información. Como lrand48 oculta 17 bits de su estado de 48 bits en cada llamada, la salida presenta una regularidad que una cadena aleatoria no mostraría, y un escáner construido para buscar esa regularidad puede encontrarla.

Para recuperar el estado, Claude tomó la primera palabra y probó los 2^17 valores posibles de los 17 bits ocultos. Esa es una búsqueda pequeña, y resulta barata porque el generador es muy simple. Cada estado candidato podía comprobarse frente al siguiente fragmento de la semilla, y el estado correcto hizo que toda la secuencia se alineara.

Las semillas de las curvas sobre cuerpos primos eran más difíciles, aunque solo ligeramente. Procedían del mismo generador lrand48, pero conservaban menos bits de cada salida. Menos bits visibles significan menos apoyo para anclar una conjetura, por lo que el truco de fuerza bruta ya no se aplica tan limpiamente. La respuesta de la fuente es que recuperar el estado de un generador congruencial lineal truncado es un problema de retículos de manual, resuelto con el algoritmo de reducción de bases de Lenstra-Lenstra-Lovasz (LLL). Un modelo podía reconocer eso y aplicarle una herramienta estándar sin nada exótico.

Las cinco semillas de curvas primas del NIST, más otras cinco del estándar ANSI X9.62, presentaban todas el mismo patrón: lrand48() >> 23. Diez semillas que comparten una misma regla de extracción constituyen una prueba sólida de que hay un único proceso detrás de ellas.

Luego viene la comprobación que separa un ajuste afortunado de uno real. Cada estado recuperado de 48 bits regenera la totalidad de los 160 bits de su semilla, algo que no ocurre por casualidad. Una coincidencia parcial podría ser una casualidad. Una regeneración completa de cada bit es algo mucho más difícil de descartar, y es la razón por la que el resultado puede enunciarse sin rodeos.

Hacer retroceder el generador para leer el reloj #

Recuperar un estado te dice cómo se produjo la semilla. Todavía no te dice cuándo. Para ello, Claude utilizó una propiedad del generador: funciona hacia atrás con la misma facilidad que hacia delante. Para cada semilla, Claude hizo retroceder el estado paso a paso hasta alcanzar la forma que produciría la inicialización con srand48, con los 16 bits inferiores iguales a 0x330E.

Esa forma es una huella dactilar en sí misma. Si un estado recuperado puede rebobinarse hasta algo que tenga los 16 bits inferiores en 0x330E, el generador se inició de la manera estándar, a partir de un valor de semilla pasado a srand48. Y el valor de la semilla, en este caso, era una hora. Las semillas se generaron utilizando el PRNG débil inicializado mediante marca de tiempo Unix.

El pensamiento interno de Claude en ese momento registró el instante del reconocimiento: todos los bits superiores estaban a cero, 20 bits, con una probabilidad de 1e-6. Es un detalle pequeño, pero muestra el razonamiento operando sobre los números tal como aparecían, no sobre una historia armada a posteriori.

Las fechas no eran todas limpias. Las cuatro inicializaciones de las curvas binarias se leían como febrero de 1984, que no es una fecha que nadie esperaría para un generador en uso a finales de los años noventa. Al duplicar las marcas de tiempo, las inicializaciones de las curvas binarias corresponden al 17 de abril de 1998, dos semanas después de la ejecución de P-224. La fuente concluye que el programa pudo haber dividido el reloj por la mitad. Eso está formulado con cautela, y debe estarlo: es una explicación propuesta de por qué los valores brutos se leen como 1984, y una duplicación que aterriza dos semanas después de otra ejecución resulta sugerente sin llegar a ser una confirmación del funcionamiento interno del programa.

Encuentro que esta es la parte más persuasiva de todo el relato, por una razón independiente de la criptografía. Una historia inventada habría producido fechas ordenadas. Esta produjo una fecha extraña, seguida de una corrección que situó las curvas binarias en una secuencia coherente con la ejecución de P-224. Unos datos desordenados que se resuelven bajo una hipótesis sencilla es exactamente el aspecto que tiene la procedencia real.

Los puntos base también tienen una receta #

Las semillas definen las curvas. Los puntos base son un asunto aparte, y la fuente los trata por separado.

Los puntos base de seis curvas generadas en mayo de 1997 (P-192 y las cinco curvas de ejemplo de ANSI X9.62: prime192v2, prime192v3 y prime239v1 a v3) proceden del generador de números aleatorios de FreeLIP, el paquete de aritmética de enteros largos de Arjen Lenstra. Las primeras versiones de la biblioteca NTL de Victor Shoup incluían el mismo código. Ese segundo dato importa para la verificación: el generador existe como código publicado que otros pueden leer, no como una herramienta privada.

La receta es breve. Se inicializa el generador con un entero pequeño. Se descartan siete salidas. Se generan coordenadas x candidatas a partir de salidas de 26 bits reducidas módulo p. Se repite esa generación de candidatos hasta que x esté sobre la curva.

Claude encontró las semillas del generador: 20000 para P-192, 20420, 20507 y 20509 para prime239v1 a v3, y 20512 y 20517 para prime192v2 y v3. Son enteros pequeños del tipo que una persona teclea en un programa, que es exactamente lo que pide el primer paso de la receta.

Los autores hacen aquí una afirmación modesta cuyo espíritu vale la pena citar: hasta donde ellos saben, ningún punto base del NIST había sido explicado antes. El matiz es suyo, y es apropiado. No están afirmando haber revisado todos los documentos jamás escritos, sino únicamente el límite de su conocimiento.

Entonces la receta deja de funcionar. Los puntos base de P-224, P-256, P-384 y P-521 no encajan en esta receta, y los autores no pudieron explicar cómo fueron seleccionados. Un informe que pasara esto por alto parecería más pulcro, pero los autores lo dejaron. La explicación cubre seis curvas de mayo de 1997 y deja sin explicar los puntos base de cuatro de las curvas primas del NIST.

Candidatas que fueron descartadas #

El último hallazgo es el que tiene más probabilidades de suscitar discusiones, por lo que conviene leerlo con precisión.

Para P-256, la semilla publicada es la candidata 1842. Pero la candidata 876 de la misma ejecución también da una curva de orden primo del tamaño adecuado, con parámetros elegidos del mismo modo que en la curva publicada. En otras palabras, el proceso pasó de largo ante una curva que, a primera vista, habría sido aceptable.

No es un caso aislado. La ejecución de P-224 pasó por alto tres curvas de ese tipo, y las dos ejecuciones detrás de las curvas de ejemplo de ANSI X9.62 pasaron por alto otras siete.

Los autores son directos sobre lo que no saben. Desconocen qué criterios pudieron haberse utilizado para descartar curvas, o si se trató de un artefacto no intencionado. Esa es una limitación, declarada como tal, y la cautela sobre el "artefacto no intencionado" es la postura honesta: los datos muestran que se saltaron candidatas y no muestran por qué.

A continuación ofrecen una valoración. Dado que el número de candidatas omitidas es pequeño, no creen plausible que se seleccionaran curvas debilitadas. Ese es un razonamiento prudente sobre la plausibilidad, y se apoya en el conteo. Si un proceso se salta solo un puñado de candidatas en total, queda poco margen en el que buscar una debilidad.

Queda una salvedad, y la fuente la enuncia como una posibilidad y no como un hallazgo. Sigue siendo concebible que estas curvas se seleccionaran para tener una propiedad específica en principio mediante la búsqueda a través de marcas de tiempo pasadas al generador de números aleatorios. Esto es especulación, señalada como tal. No debe leerse como prueba de nada, y tampoco debe descartarse en silencio. Un relato justo la mantiene sobre la mesa como una vía no excluida, al tiempo que señala que los autores consideran implausibles las curvas debilitadas.

Qué cambia el resultado y qué deja abierto #

Empecemos por lo que no cambia. Las curvas no están rotas. La fuente lo dice dos veces, con distintas palabras, y no hay ninguna medida que tomar. Cualquiera que lea esto como una razón para retirar P-256 lo ha leído mal.

Lo que cambia es el estatus de una vieja duda. Mientras las semillas carecieron de explicación, "proporcionadas por la NSA sin explicación" fue un signo de interrogación permanente sobre un estándar. Ese signo de interrogación tiene ahora una respuesta concreta. Las semillas no eran hashes inescrutables de una frase secreta. Eran salidas de lrand48 procedentes de un programa inicializado con el reloj, regenerando cada bit de cada semilla a partir de un estado recuperado. Una explicación que cualquiera con las semillas publicadas puede comprobar supera a un rumor que nadie puede verificar.

Hay aquí una lección para los fundadores e ingenieros que construyen sobre estándares criptográficos. Las afirmaciones sobre la procedencia son baratas de hacer y caras de comprobar, y la comprobación descrita aquí llevó menos de media hora una vez que se formuló la pregunta adecuada. El escáner, la búsqueda de 2^17 y la reducción de retículos son todos movimientos estándar. Lo que faltó durante años fue alguien que hiciera el trabajo poco vistoso de probarlos contra los números publicados.

También me resistiría a la tentación de exagerar el método. La fuente informa del resultado de un equipo sobre un conjunto específico de semillas. No afirma que el mismo enfoque vaya a descifrar cada constante inexplicada de cada estándar, y yo no lo afirmaré por ellos. Lo que demuestra es más acotado y, a mi juicio, más útil: cuando el origen de un parámetro es un misterio, un modelo cuidadoso con una conjetura plausible sobre las herramientas de la época puede poner a prueba la conjetura rápidamente y mostrar su trabajo.

Los asuntos pendientes son lo bastante claros como para constituir una agenda de investigación. Cuatro puntos base, los de P-224, P-256, P-384 y P-521, siguen careciendo de explicación. Las candidatas descartadas, como la 876 frente a la 1842 publicada para P-256, carecen de un criterio declarado, y nadie sabe aún si el salto fue deliberado o un artefacto. Si esas respuestas sobreviven en código fuente antiguo, en la memoria de colegas vivos o en el mismo tipo de caza de patrones que descifró las semillas es la pregunta abierta. Las semillas llevaron media hora; los puntos base ya se han resistido una vez a este enfoque.

Preguntas frecuentes #

¿Rompe este descubrimiento las curvas ECDSA del NIST como P-256 o P-384?

No. Descubrir que las semillas de las curvas fueron generadas por lrand48 en lugar del hash de una frase de paso no introduce ninguna rotura criptográfica, ningún ataque nuevo ni ninguna debilidad matemática en las curvas ECDSA, y no se requiere ninguna acción de remediación o migración a raíz de este hallazgo.

¿Cómo se generaron realmente las semillas de las curvas primas del NIST?

Cada semilla de 160 bits se produjo llamando al generador congruencial lineal lrand48 de la biblioteca estándar de C (concretamente lrand48() >> 23 para las cinco curvas primas del NIST y cinco curvas de ANSI X9.62), inicializado mediante srand48 con una marca de tiempo Unix. Recuperar el estado interno de 48 bits mediante la reducción de retículos de Lenstra-Lenstra-Lovasz (LLL) regenera los 160 bits completos de cada semilla publicada.

¿Qué queda sin explicar sobre los parámetros de las curvas elípticas del NIST?

Mientras que los puntos base de P-192 y cinco curvas de ANSI X9.62 se rastrearon hasta el generador de números aleatorios del paquete FreeLIP de Arjen Lenstra inicializado con enteros pequeños, los puntos base de P-224, P-256, P-384 y P-521 no coinciden con esa receta, y siguen desconociéndose los criterios por los que se descartaron curvas candidatas anteriores de orden primo (como la candidata 876 antes de la candidata 1842 en P-256).

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.

Última revisión 2026-11-01.

Volver a publicar este artículo

Las semillas misteriosas detrás de las curvas del NIST nunca fueron hashes, y Claude lo descubrió en menos de media hora — Sebastien Rousseau

Las semillas publicadas con las curvas P-192, P-224, P-256, P-384 y P-521 del NIST nunca fueron resultados de funciones hash. Procedían del generador lrand48 de la biblioteca de C, inicializado con...

Este artículo se publica bajo Creative Commons Attribution 4.0 International. La republicación requiere atribución a la URL canónica.

Las semillas misteriosas detrás de las curvas del NIST nunca fueron hashes, y Claude lo descubrió en menos de media hora — Sebastien Rousseau

Las semillas publicadas con las curvas P-192, P-224, P-256, P-384 y P-521 del NIST nunca fueron resultados de funciones hash. Procedían del generador lrand48 de la biblioteca de C, inicializado con...

Originally published at https://sebastienrousseau.com/es/2026-10-26-semillas-misteriosas-detras-curvas-nist-nunca/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER