Más allá del almacenamiento seguro, parte 2: implementación segura de la criptografía de las billeteras

La parte 1 de Beyond Secure Storage examinó el uso indebido de la capacidad de firma de un sistema de pagos. Esta segunda parte examina otra vía para obtener firmas no autorizadas: fallos en la implementación criptográfica que permiten a un atacante recuperar una clave privada y firmar de forma independiente. La pregunta es: ¿puede un atacante reconstruir una clave sin leer su copia protegida?

La sección 1 establece los requisitos de seguridad para la generación, el almacenamiento y el uso de claves para firmar. Las secciones 2 y 3 examinan cuatro incidentes de generación de claves y dos incidentes de firma, y explican los errores de implementación y sus consecuencias. La sección 4 extrae de esos casos principios de diseño e implementación y, después, explica cómo verificar las propiedades requeridas.

1. Propiedades de seguridad a lo largo del ciclo de vida de una clave

Una clave debe generarse, almacenarse y utilizarse para firmar. Cada etapa tiene un requisito de seguridad distinto, como muestra el diagrama.

En una billetera determinista jerárquica que utiliza frases mnemónicas BIP-39 y derivación de claves BIP-32, los datos aleatorios criptográficamente seguros se codifican en una frase mnemónica y se convierten en una semilla. Esa semilla se utiliza para derivar claves privadas, claves públicas y direcciones de billetera [1, 2].

Una vez generadas, las semillas y las claves privadas necesitan protección mediante cifrado o aislamiento por hardware. Para firmar, se utiliza la clave privada con el fin de producir una firma verificable públicamente. Según el esquema, también puede ser necesario un nonce aleatorio generado de forma segura o derivado de manera determinista a partir de material secreto.

Los requisitos de seguridad difieren entre estas etapas:

1. Impredecibilidad al generar la clave. Un atacante no debe poder predecir ni enumerar de forma viable el secreto que controla la billetera.
2. Confidencialidad durante el almacenamiento. Las partes no autorizadas no deben poder leer material secreto a través del software, las interfaces físicas, las copias de seguridad, los registros o los servicios remotos.
3. Ausencia de filtraciones durante el uso. La firma no debe revelar información suficiente para reconstruir el secreto, ni siquiera después de muchas firmas observables públicamente.

Las billeteras de hardware, los elementos seguros y los entornos de ejecución de confianza (TEE) pueden reforzar la confidencialidad. Su mera presencia no garantiza las otras dos propiedades. Una clave predecible sigue siéndolo después de almacenarse de forma segura; la información matemática revelada por las firmas sigue estando disponible aunque los bytes de la clave privada estén aislados del sistema anfitrión. Por tanto, un atacante puede recuperar una clave afectada y acceder a los activos que esta controla sin leer la copia almacenada.

Las dos secciones siguientes examinan cómo las implementaciones incumplen estos requisitos: los fallos de generación pueden hacer que las claves sean predecibles, mientras que los fallos de firma pueden permitir recuperarlas a partir de firmas públicas. Estos casos sirven de base para los principios de implementación y los objetivos de verificación de la sección 4.

2. Generación defectuosa de claves: claves privadas predecibles

La generación de claves debe preservar la impredecibilidad en cada paso. La fuente de entropía debe ser apta para uso criptográfico, no debe ser viable enumerar sus estados y las conversiones de bytes aleatorios a una semilla o clave privada deben preservar la incertidumbre prevista. Un objetivo de seguridad de 128 bits requiere un espacio de secretos que no pueda reducirse, mediante fallos de implementación, a una búsqueda viable.

La tabla resume cuatro formas en que la generación puede perder esta propiedad: un generador débil en una biblioteca, una vinculación incorrecta del generador de números aleatorios (RNG), una conversión de entrada que pierde información y un generador con un estado inicial limitado. Las cifras de impacto proceden de informes que abarcan distintos períodos; no son totales medidos en una misma fecha.

2,1 Ill Bloom: aleatoriedad débil en una dependencia de billeteras

En el incidente de Ill Bloom, algunas billeteras de software generaron frases de recuperación BIP-39 utilizando versiones vulnerables de crypto-js. La función CryptoJS.lib.WordArray.random() de la biblioteca utilizaba un generador Multiply-With-Carry (MWC) personalizado, inicializado con Math.random(), en lugar de obtener entropía de una fuente criptográficamente segura. Las billeteras que utilizaban esta función como fuente de entropía para una operación crítica para la seguridad heredaron las debilidades del generador, aunque los pasos posteriores de generación de frases mnemónicas y derivación de claves siguieran correctamente sus estándares [3].

La implementación vulnerable de crypto-js v3.1.9-1 [4] contiene esta lógica característica:

  random: function (nBytes) {
      var words = [];

      var r = (function (m_w) {
          var m_w = m_w;
          var m_z = 0x3ade68b1;
          var mask = 0xffffffff;

          return function () {
              m_z = (0x9069 * (m_z & 0xFFFF) + (m_z >> 0x10)) & mask;
              m_w = (0x4650 * (m_w & 0xFFFF) + (m_w >> 0x10)) & mask;
              var result = ((m_z << 0x10) + m_w) & mask;
              result /= 0x100000000;
              result += 0.5;
              return result * (Math.random() > .5 ? 1 : -1);
          }
      });

      for (var i = 0, rcache; i < nBytes; i += 4) {
          var _r = r((rcache || Math.random()) * 0x100000000);

          rcache = _r() * 0x3ade67b7;
          words.push((_r() * 0x100000000) | 0);
      }

      return new WordArray.init(words, nBytes);
  }

Aquí, r() es el generador personalizado basado en MWC, mientras que Math.random() ayuda a inicializar su estado o influye en él. Este generador de números seudoaleatorios (PRNG) produce bytes que parecen entropía ordinaria, pero la implementación no ofrecía impredecibilidad criptográfica. Los espacios efectivos de candidatos eran aproximadamente de 2 USD^{39}$ para una salida nominal de 128 bits y de 2 USD^{47}$ para una salida nominal de 256 bits [3].

Esos espacios más pequeños hicieron viable reconstruir posibles frases de recuperación, derivar las direcciones de billetera correspondientes y cotejarlas con la actividad pública de la cadena de bloques. Así, podía recuperarse un secreto sin extraer nada del dispositivo de la víctima. Seguir el estándar de frases mnemónicas no podía corregir la aleatoriedad débil heredada de la dependencia anterior.

2,2 Coldcard: un generador de números aleatorios por hardware que el código no utilizó

Coldcard muestra por qué no basta con disponer de una fuente segura de aleatoriedad si la aplicación llama a otro generador. Aunque el dispositivo tenía un generador de números aleatorios por hardware, un error de integración durante la compilación hizo que rng_get(), en la ruta de generación de la semilla, se resolviera como Yasmarang, el generador de números pseudoaleatorios por software de MicroPython. Este generador, que no era criptográficamente seguro, se inicializaba con el ID único y fijo del dispositivo y con información temporal limitada. Esto hacía que su estado inicial fuera lo bastante predecible como para reducir drásticamente la entropía efectiva de las semillas de billetera generadas [5].

La rutina de generación de semillas también incorporaba la salida de un segundo generador Yasmarang. En los dispositivos Mk2/Mk3 más antiguos, ese segundo generador partía de constantes públicas y no aportaba entropía adicional. En los modelos más nuevos, aunque se introdujo aleatoriedad procedente de elementos seguros, durante la reinicialización solo se conservaron 32 bits. Por consiguiente, pese a producir semillas de billetera de 256 bits, el espacio efectivo de búsqueda se redujo drásticamente. Coinkite estimó de forma preliminar unos 2 USD^{40}$ candidatos en Mk2/Mk3 y 2 USD^{72}$ en Mk4/Q/Mk5, bajo los supuestos de ataque que indicó [6, 7].

La debilidad convirtió la recuperación de semillas en una búsqueda sin conexión: un atacante podía derivar direcciones a partir de semillas candidatas y compararlas con datos públicos de la cadena de bloques. El costo práctico depende del modelo y de los supuestos de ataque; la estimación de 2 USD^{72}$ no implica la misma viabilidad que el caso de 2 USD^{40}$. Una coincidencia permite conocer las claves privadas correspondientes.

2.3 XRPH Wallet: un error en el formato de entrada que redujo el espacio de claves

La ruta de generación también incluye la conversión de la salida aleatoria al formato de entrada que espera una API de billetera. En XRPH Wallet, esa conversión descartaba la mayor parte de los datos generados. La aplicación de Android generaba bloques decimales con Math.random() de JavaScript, los concatenaba en una cadena de texto y pasaba esa cadena a Wallet.fromEntropy(). El código receptor interpretaba los caracteres como valores enteros pequeños de bytes y conservaba solo las primeras 16 posiciones. Como dos posiciones contenían espacios separadores fijos, solo 14 dígitos decimales variables aportaban entropía a la billetera resultante [8].

padlock = { A, B, C, D, E, F, G, H };     // each = 6 digits from the line above
r6 =  A.join('') + ' ' + B.join('') + ' ' + C.join('') + ' ' + D.join('')
    + ' ' + E.join('') + ' ' + F.join('') + ' ' + G.join('') + ' ' + H.join('');
r5 = Wallet.fromEntropy;
r3 = r5.bind(Wallet)(r6);                 // a 55-char STRING is passed; fromEntropy wants 16 bytes

// compute entropy be like
const input = "528875 921568 528239 ...";  // decimal blocks
const entropy = Uint8Array.from(input).slice(0, 16);
// Result: [5,2,8,8,7,5,0,9,2,1,5,6,8,0,5,2]

La transformación resultante dejaba aproximadamente 10 USD^{14}\approx 2^{46}$ entradas de billetera posibles, frente al espacio previsto de aproximadamente 2 USD^{128}$ para una entropía de 16 bytes muestreada de manera uniforme. Esa cifra describe los candidatos posibles bajo la transformación observada; no constituye una prueba criptográfica de la entropía estadística de Math.random().

Dos fallos se agravaron mutuamente: una fuente de aleatoriedad inadecuada y un error de representación o codificación en el límite de la API. Ambos pueden pasar inadvertidos en las pruebas funcionales porque la billetera sigue generando direcciones plausibles y firmando transacciones válidas. La investigación pública establece que el espacio de claves permite recuperar una clave; no demuestra por sí sola qué vía utilizó el atacante para obtenerla.

2,4 Qubic Wallet: aleatoriedad débil detrás de una semilla de 55 caracteres

El estado inicial del generador también puede limitar las semillas posibles, por muy larga que parezca la cadena de salida. Qubic ilustra este problema: el incidente de seguridad reportado que afectó a sus billeteras involucró semillas generadas con Math.random() de JavaScript, que no es criptográficamente seguro. Entre los entornos afectados había navegadores de Apple y ciertas versiones antiguas de la aplicación para iOS basadas en JavaScriptCore [9, 10].

La lógica de generación vulnerable y su corrección pueden resumirse así [11]:

// Vulnerable seed generation (abridged)
seed += letters[Math.floor(Math.random() * 26)];

// Corrected approach (schematic excerpt of the fix)
crypto.getRandomValues(bytes);
if (byte < 234) seed += letters[byte % 26];

Llamar a Math.random() 55 veces no proporciona 55 fuentes independientes de entropía. Entre las reinicializaciones, cada llamada al generador de números pseudoaleatorios hace avanzar su estado interno de forma determinista. Para una posición de llamada fija, si la semilla inicial es $SS$, la semilla completa de la billetera, de 55 caracteres, es una función determinista $W=F(S)W=F(S)$. Conocer $SS$ y esa posición de llamada basta para reproducir los 55 caracteres; llamar más veces al generador no crea entropía adicional.

El rango de estados iniciales posibles depende de la inicialización del entorno de ejecución. La instantánea del código fuente de JavaScriptCore consultada el 29/10/2026 inicializa su generador de números pseudoaleatorios a partir de una semilla de 32 bits, lo que da como máximo 2 USD^{32}$ secuencias para una posición de llamada fija. El código fuente de V8 examinado aquí utiliza una semilla de 64 bits, lo que da como máximo 2 USD^{64}$ secuencias de ese tipo. Estos límites se aplican a las rutas de inicialización examinadas para una posición de llamada fija. Las instantáneas no permiten determinar las versiones exactas de los navegadores utilizadas en el incidente ni el costo de explotarlas. La corrección, en cambio, utiliza crypto.getRandomValues() para obtener aleatoriedad criptográficamente segura, con muestreo por rechazo (byte < 234) para evitar sesgos al asignar bytes a 26 letras [12, 13, 14].

3. Firma defectuosa: recuperación de la clave privada a partir de firmas públicas

Una vez generada una clave de forma segura, también debe permanecer secreta cuando se utiliza para firmar. Cada firma pone datos a disposición de quienes la observan, y los defectos de implementación pueden hacer que esos datos públicos proporcionen suficiente información para recuperar la clave privada. ECDSA y Schnorr utilizan un escalar secreto por firma, denominado nonce, para ocultar la contribución de la clave privada a la firma pública.

El nonce debe permanecer secreto, no reutilizarse con mensajes distintos bajo la misma clave y cumplir los requisitos de distribución del esquema. La derivación determinista es compatible con estos requisitos: conocer la clave pública y el mensaje firmado no debe bastar para predecir el nonce.

Tomemos como ejemplo la relación simplificada de Schnorr:

$s=k-rd(\mathrm{m}\mathrm{o}\mathrm{d}n),s=k-rd\backslash pmod\; n,$

donde $dd$ es la clave privada; $kk$, el nonce; $rr$, un valor público calculado a partir de información pública (por ejemplo, la clave pública y el mensaje); $ss$, el escalar público de la firma; y $nn$, el orden del subgrupo. Si se conoce el nonce, se obtiene de inmediato $d=(k-s)r^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}n)d=(k-s)r^\{-1\}\backslash pmod\; n$, siempre que $rr$ sea invertible.

Además, no es necesario conocer por completo el nonce para que se filtre la clave. Las restricciones o los sesgos presentes en varios nonces pueden proporcionar información suficiente para recuperar la clave mediante métodos basados en retículas. La viabilidad depende de la información expuesta y de las firmas disponibles.

La tabla distingue los dos fallos de nonce examinados en esta sección: los nonces de Zilliqa estaban parcialmente restringidos, mientras que los de SecondFi podían calcularse a partir de datos públicos. Los impactos notificados corresponden a períodos históricos distintos.

3,1 Zilliqa Ledger Wallet: faltaban 64 bits en cada nonce Schnorr

El incidente de Zilliqa Ledger Wallet se debió a un fallo en la aplicación utilizada para las transacciones EC-Schnorr heredadas de Zilliqa [15]. La aplicación generaba los datos del nonce, pero copiaba la porción equivocada al búfer final de firma. Conservaba ocho bytes de relleno con ceros y descartaba ocho bytes de aleatoriedad real. Como resultado, cada nonce afectado cumplía 0 USD \le k < 2^{192},$ en lugar de distribuirse adecuadamente por el orden del grupo secp256k1, de aproximadamente 256 bits.

Las ecuaciones de firma muestran por qué importa restringir el nonce:

Aquí, $GG$ es el generador del grupo. Al reorganizar la ecuación se obtiene

$k=s+rd(\mathrm{m}\mathrm{o}\mathrm{d}n)\mathrm{.}k=s+rd\backslash pmod\; n.$

Por tanto, cada firma aporta una relación modular con la incógnita $dd$, en la que el nonce está acotado por 2 USD^{192}$. Al combinar varias relaciones independientes se obtiene una instancia del problema del número oculto (HNP), que puede abordarse mediante reducción de retículas. El informe oficial posterior al incidente señala que se recuperaron claves privadas a partir de cuatro o más firmas afectadas.

El elemento seguro nunca tuvo que revelar los bytes de la clave privada. Los nonces sesgados hicieron posible recuperar esa clave a partir de firmas ya publicadas en la cadena.

3,2 SecondFi: un nonce de firma calculable a partir de datos públicos

En SecondFi, la derivación incorrecta de los nonces Ed25519 expuso más que una restricción parcial: hizo que el nonce pudiera calcularse a partir de datos públicos. Esto permitió recuperar claves privadas de firma a partir de una sola firma de transacción disponible públicamente [16].

En una firma de tipo Ed25519, el procedimiento previsto deriva un escalar secreto $aa$ y un prefijo privado para el nonce a partir del material secreto de la clave. Aquí, $A=aBA=aB$ es la clave pública, $BB$ es el punto base de Ed25519, $MM$ es el mensaje firmado, $LL$ es el orden del subgrupo y $HH$ denota SHA-512. De forma esquemática:

La implementación defectuosa establece, en cambio, $r=H(M)Lr=H(M)\backslash bmod\; L$. Cualquiera que conozca el mensaje firmado puede derivar $rr$. Puesto que $RR$, $AA$ y $SS$ son públicos, un observador puede calcular entonces

$a=(S-r)h^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L),a=(S-r)h^\{-1\}\backslash pmod\; L,$

siempre que $hh$ no sea cero módulo $LL$.

A diferencia de la filtración parcial del nonce en Zilliqa, una sola firma afectada bastaba para recuperar el escalar de firma. Esto no demuestra automáticamente que se pudiera recuperar la frase mnemónica original ni todas las demás claves derivadas de la misma billetera jerárquica. El fallo se produjo en la interfaz entre la derivación de claves y la firma: el secreto requerido estaba disponible, pero nunca se pasó a la rutina de derivación del nonce.

4. Principios de implementación segura y verificación

En conjunto, los casos muestran por qué deben revisarse las fuentes de aleatoriedad y los algoritmos de firma junto con el código que los conecta. Una fuente impredecible debe producir claves impredecibles, y esas claves deben permanecer secretas durante la firma. Los errores en las rutinas de conversión o en las interfaces de las bibliotecas pueden incumplir cualquiera de estos requisitos.

Las secciones 4,1 y 4,2 exponen los principios de diseño e implementación para la generación y la firma. La sección 4,3 explica qué pruebas documentales deben aportar las revisiones y los tests para evaluar esos principios en el sistema desplegado.

4,1 Preservar la seguridad durante la generación de claves

Los casos de generación apuntan a tres requisitos de implementación:

1. Utilizar aleatoriedad criptográficamente segura y detenerse si falla. Las semillas y las claves privadas requieren una fuente criptográficamente segura adecuada, como un generador de números seudoaleatorios criptográficamente seguro (CSPRNG). Ill Bloom y Qubic muestran por qué un generador de propósito general no puede cumplir esa función. Si la fuente prevista no está disponible o falla, la generación debe detenerse en lugar de recurrir silenciosamente a un sustituto más débil.

2. Preservar la entropía durante la conversión de datos. La salida de una fuente segura debe conservar la incertidumbre requerida al codificarse, muestrearse o pasarse entre interfaces. El caso de XRPH Wallet muestra por qué no basta con que la salida parezca válida. Las restricciones de tipo, longitud y codificación deben impedir que un truncamiento involuntario o una correspondencia sesgada reduzcan el espacio efectivo de claves.

3. Asegurar que el código desplegado utilice la fuente prevista. Coldcard muestra que la presencia de una fuente de aleatoriedad segura no demuestra qué fuente invoca realmente la aplicación. La selección de la fuente debe mantenerse correcta durante la integración, la compilación y el despliegue, incluidas las rutas de error y de respaldo. Una premisa de diseño sobre el RNG debe cumplirse en el ejecutable que se utiliza en la plataforma de destino.

4,2 Preservar el secreto durante la firma

Los requisitos de generación protegen la forma en que se crea una clave. Mantenerla en secreto durante su uso también exige un manejo correcto de los nonces. Los requisitos dependen del esquema; la lista incluye ECDSA además de los esquemas Schnorr y Ed25519 examinados en los casos.

1. ECDSA: Preservar el secreto y la impredecibilidad del nonce, e impedir su reutilización con la misma clave en mensajes diferentes. La generación determinista conforme a RFC 6979 [17] evita depender de nueva aleatoriedad externa para cada firma, pero las implementaciones siguen necesitando protección contra las filtraciones por canales laterales y los ataques por fallos.

2. EdDSA: Preservar todas las entradas secretas necesarias para derivar el nonce. SecondFi demuestra las consecuencias de omitir el prefijo privado y utilizar únicamente datos públicos. Las capas de adaptación y los adaptadores de claves deben pasar todas las entradas secretas requeridas por RFC 8032 [18], en lugar de considerar que una firma válida demuestra que las entradas son correctas.

3. Schnorr: Preservar la distribución y la representación del nonce que exige el esquema. Como muestra Zilliqa, evitar la repetición y los nonces totalmente predecibles no basta si se pierde parte de la aleatoriedad. El tratamiento de datos y la conversión a escalares no deben introducir restricciones ni sesgos explotables.

Las bibliotecas sometidas a revisiones rigurosas reducen el riesgo de implementación, pero no eliminan los errores de integración. Una primitiva de firma correcta sigue siendo insegura si quien la invoca le proporciona entradas incompletas o alteradas.

4.3 Comprobar las propiedades de seguridad

Para evaluar si se cumplen estos requisitos, las revisiones deben seguir las entradas a través de la implementación que realmente se ejecuta. Una salida válida puede ocultar un error de integración, por lo que la verificación también debe abarcar rutas que los tests funcionales habituales no cubren. La tabla convierte los requisitos de generación y firma en objetivos concretos de revisión:

Evaluar estos objetivos exige combinar varios métodos. La revisión del código permite rastrear cómo llegan las entradas secretas y aleatorias a las rutinas de generación y firma desplegadas. Los tests de rutas de error y la inyección de fallos examinan el comportamiento cuando no se cumplen las condiciones normales; los tests de resultados conocidos y las comparaciones con implementaciones independientes pueden revelar desviaciones respecto del esquema. Los tests estadísticos pueden detectar sesgos evidentes, pero la generación correcta de direcciones, la verificación de firmas o los tests estadísticos, por sí solos, no pueden demostrar la seguridad criptográfica. Las pruebas obtenidas en conjunto deben evaluarse frente a los requisitos relativos a la fuente, el manejo de las entradas y el esquema.

Los equipos o expertos externos en seguridad pueden complementar la verificación interna mediante auditorías del código y de la integración, en particular en los puntos de conexión entre las fuentes de aleatoriedad, la derivación de claves y las bibliotecas de firma. El alcance debe abarcar las versiones de las dependencias, la configuración de compilación y la ruta de código ejecutada. Los hallazgos deben identificar la propiedad de seguridad afectada y aportar pruebas reproducibles y comprobaciones de regresión. Los cambios en la implementación o en sus dependencias siguen requiriendo verificación.

5. Conclusión

Los seis incidentes revelan dos formas en que los errores de implementación pueden comprometer claves protegidas: reducir el conjunto de claves posibles durante la generación o exponer información sobre una clave existente mediante las firmas. El análisis convierte esos fallos en requisitos para la generación y la firma, con objetivos de revisión y pruebas para el código desplegado en la infraestructura de pagos.

Para las entidades de pago, el almacenamiento seguro protege el secreto almacenado; no puede corregir una generación predecible ni la información filtrada al firmar. Las propiedades requeridas deben mantenerse a través de las dependencias, los adaptadores y el despliegue. Las revisiones y los tests deben examinar esa implementación completa, en lugar de deducir su seguridad a partir de direcciones y firmas válidas.

Estos requisitos de implementación complementan los controles del flujo de trabajo examinados en la parte 1 de Beyond Secure Storage. La parte 1 examina los riesgos del flujo de trabajo, las comprobaciones preventivas y la limitación de pérdidas cuando esas comprobaciones no logran detener operaciones no autorizadas. La parte 2 aborda los fallos de implementación que pueden dar a un atacante capacidad independiente para firmar. Una ejecución criptográfica correcta no demuestra que exista autorización para la operación; una aprobación válida de la operación no demuestra que la clave de firma sea impredecible o irrecuperable. Los sistemas seguros de pago y firma requieren que tanto el flujo de autorización como la implementación criptográfica subyacente se diseñen y verifiquen.

Referencias

• [1] BIP-39, Código mnemónico para generar claves deterministas.

• [2] BIP-32, Billeteras deterministas jerárquicas.

• [3] CryptoJS, Aviso de seguridad GHSA-rg76-677x-56q9.

• [4] CryptoJS, Código fuente de core.js, versión 3.1.9-1.

• [5] Coldcard, Aviso sobre el firmware y notas de la versión.

• [6] MicroPython, Análisis posterior al incidente de Coldcard desde la perspectiva de MicroPython.

• [7] Coinkite, Análisis técnico detallado del problema de entropía.

• [8] XRPL.to, El ataque a XRPH Wallet: se vaciaron 4011 billeteras y todas las claves podían adivinarse.

• [9] Qubic, Comunicado sobre el incidente y recomendaciones para las plataformas afectadas.

• [10] Qubicmap, Cronología del incidente de Qubic y resumen de las billeteras.

• [11] Qubic Wallet, Corrección de la generación segura de semillas 09dd288.

• [12] WebKit, JSGlobalObject.cpp, inicialización de m_weakRandom.

• [13] WebKit, WeakRandom.h, implementación de la semilla y del PRNG.

• [14] V8, math-random.cc, inicialización del estado del PRNG.

• [15] Zilliqa, Análisis posterior al incidente: sesgo de los nonces Schnorr heredados.

• [16] KarpelesLab, Análisis y reproducción de la implementación de SecondFi.

• [17] RFC 6979, Uso determinista de DSA y ECDSA.

• [18] RFC 8032, Algoritmo de firma digital de curva de Edwards (EdDSA).