Investigación. Original

La vulnerabilidad del PRNG y el IV en la preventa

Parte de nuestra investigación sobre la aleatoriedad débil: consulta la descripción general sobre la aleatoriedad débil en los monederos criptográficos.

El generador de carteras de la preventa de 2014 utilizaba la función Math.random del navegador en casos en los que no debería haberlo hecho. Nuestra investigación analiza si esa previsibilidad abre una vía de recuperación para las carteras de la preventa que, de otro modo, estarían bloqueadas.

Actualizado en julio de 2026 · KeychainX — Recuperación de carteras desde 2017

Se trata de una investigación original de KeychainX, y la presentamos como una investigación abierta, más que como un exploit terminado. El generador de carteras de la preventa de Ethereum de 2014 utilizaba la función de aleatoriedad del navegador —Math.random() — como parte del proceso de generación de los parámetros de cifrado. Cuando la aleatoriedad es predecible, puede ser posible la recuperación. Esto es lo que hemos descubierto.

Antecedentes: cómo se creó la cartera de preventa

Una cartera de preventa es un almacén de claves JSON que cifra tu clave privada con tu contraseña utilizando PBKDF2 y AES. El cifrado requiere un vector de inicialización (IV) y otros valores específicos de cada cartera, que se generaron en el navegador en el momento de su creación. Un IV verdaderamente aleatorio no es en sí mismo un secreto, pero la forma en que el generador obtenía la aleatoriedad es donde reside la vulnerabilidad interesante, ya que parte de ella se basaba en Math.random() en lugar de en una fuente criptográfica.

¡Por qué Math.random es poco fiable!

Math.random() es un generador pseudoaleatorio cuya semilla se deriva de un estado limitado, a menudo basado en el tiempo; nunca se diseñó para la criptografía. Si un valor que debería ser impredecible fuera generado por Math.random() a partir de una semilla derivada de algo acotado, el conjunto de valores posibles sería lo suficientemente pequeño como para enumerarlo. Este es el mismo principio en el que se basan Randstorm y MilkSad: el algoritmo es correcto, pero la semilla es predecible.

El problema de colapso «undefinedundefined» de Firefox

Nuestro hallazgo clave se refiere a una peculiaridad específica del navegador. El generador incorporaba las coordenadas del movimiento del ratón como fuente de entropía, pero en Firefox, en determinadas condiciones, esas coordenadas se mostraban como la cadena literal «undefinedundefined», sin aportar entropía real alguna. Cuando eso ocurría, la aleatoriedad desconocida se reducía a la fuente restante: una marca de tiempo de un milisegundo. Y esa marca de tiempo está limitada, ya que se creó una cartera de preventa en un intervalo de tiempo cercano al momento en que su transacción de financiación llegó a la cadena de Bitcoin.

Qué significa esto para la recuperación

Esto implica una reducción drástica del espacio de búsqueda para las carteras afectadas. Si la entropía se reduce realmente a una marca de tiempo de un milisegundo limitada por los tiempos de financiación en cadena, el espacio de candidatos pasa a ser enumerable, y una búsqueda estructurada —una búsqueda por haces en la ventana de tiempo plausible, reconstruyendo el estado del generador— podría reproducir los valores necesarios para facilitar el descifrado. Hemos esbozado esta metodología; resulta prometedora para un subconjunto específico de carteras creadas con Firefox y no es una «llave maestra» universal para las preventas. La mayoría de las recuperaciones de preventas siguen reduciéndose a los problemas de codificación de contraseñas que documentamos por separado.

Por qué es importante en el caso de las criptomonedas perdidas

Las carteras de preventa de 2014 se encuentran entre los activos inactivos más valiosos de todo el mundo de las criptomonedas, y una parte significativa de ellas permanece bloqueada porque sus propietarios ya no pueden descifrarlas. Cualquier método fiable que reduzca el espacio de búsqueda, aunque sea solo para un subconjunto de ellas, merece la pena explorarse, ya que hay mucho en juego por cada monedero. Por eso nos tomamos muy en serio el enfoque del PRNG a pesar de su limitada aplicabilidad: para los monederos concretos en los que se produjo el colapso de entropía, la diferencia entre una búsqueda ilimitada y una limitada es la diferencia entre la pérdida total y la recuperación. Cualquier investigación que amplíe el conjunto de monederos recuperables, aunque sea modestamente, tiene aquí un valor desmesurado.

La metodología en profundidad

En concreto, el enfoque consiste en una reconstrucción acotada. En primer lugar, se establece la ventana de financiación a partir del historial en cadena del monedero, que delimita el momento de la creación. En segundo lugar, para cada milisegundo candidato dentro de esa ventana, se reconstruye el estado del generador que se habría obtenido dada la entropía colapsada, y se deducen los parámetros de cifrado que habría generado. En tercer lugar, se comprueban esos parámetros con el almacén de claves cifrado, descartando o aceptando candidatos en función de si la derivación es internamente coherente. Una búsqueda por haz mantiene vivos los estados candidatos más prometedores, en lugar de agotar todas las posibilidades a ciegas. Se trata de un trabajo minucioso y específico para cada monedero —no de un ataque por lotes—, lo cual es adecuado dado que solo se aplica cuando se dan las condiciones específicas.

Una situación sincera

Presentamos esto como una investigación en curso. Las condiciones deben darse al mismo tiempo —el navegador concreto, el colapso de entropía específico y un plazo de financiación bien delimitado— y cada monedero candidato debe evaluarse de forma individual. Lo publicamos porque se trata de un enfoque genuino y poco estudiado sobre algunos de los monederos inactivos más valiosos que existen, y porque ser transparentes sobre un método prometedor, aunque aún sin perfeccionar, resulta más útil para los propietarios que hacer afirmaciones exageradas o guardar silencio.

A qué carteras podría aplicarse esto

Para ser precisos en cuanto al alcance: los principales candidatos son las carteras de preventa creadas en Firefox durante el periodo en el que falló la fuente de entropía de las coordenadas del ratón, y en las que una transacción de financiación proporciona un límite preciso de la fecha de creación. Las carteras creadas en otros navegadores, o en las que la fuente de entropía funcionó según lo previsto, no presentan este colapso y no se abordan mediante esta vía. Por eso evaluamos cada cartera de forma individual en lugar de prometer una solución general: el mismo JSON de preventa podría recuperarse mediante la vía de la codificación, mediante esta vía del PRNG, o mediante ninguna de las dos, y solo una inspección de la cartera específica y su contexto en la cadena nos dirá cuál es la opción correcta.

Nuestra documentación

Este análisis es propio de KeychainX y se ha desarrollado en el marco de una investigación sobre carteras inactivas de preventa (véase nuestro estudio sobre ETH de preventa inactivas ) y de nuestro trabajo más amplio sobre aleatoriedad débil, en colaboración con Randstorm y MilkSad. Lo publicamos aquí para dejar constancia del hallazgo, y agradecemos la colaboración de los investigadores que estén analizando el mismo generador.

Preguntas frecuentes