Cada mensaje cifrado, cada sesión bancaria segura, cada firma digital que protege una actualización de software depende de la misma base invisible: números aleatorios impredecibles. La generación de claves criptográficas es el proceso que transforma el caos en seguridad, convirtiendo la aleatoriedad en bruto en las claves que protegen nuestra infraestructura digital. Cuando esa aleatoriedad falla, todo lo construido sobre ella también lo hace.
Las matemáticas detrás del cifrado son elegantes y bien estudiadas. Lo que se comprende menos es el papel igualmente crítico de la entropía, la impredecibilidad que hace que las claves sean imposibles de adivinar. Un estudio de 2012 en toda la Internet descubrió que los investigadores podían obtener claves privadas RSA para el 0,50 % de los hosts TLS y el 0,03 % de los hosts SSH porque las claves públicas compartían factores comunes no triviales, un fallo que los autores vincularon principalmente a entropía insuficiente en dispositivos sin cabeza y embebidos[s]. En ese escaneo, la cifra de TLS representaba alrededor de 64.000 hosts.
Los dos pilares de la seguridad criptográfica
La criptografía se sustenta en dos fundamentos. El primero es la complejidad matemática: los algoritmos se basan en problemas que son fáciles de plantear pero extraordinariamente difíciles de revertir. El segundo es la aleatoriedad. Los protocolos criptográficos utilizan números aleatorios para generar claves secretas, vectores de inicialización y nonces. Estos valores deben ser impredecibles. Si un atacante puede adivinarlos o reproducirlos, la complejidad matemática se vuelve irrelevante[s].
Piense en ello de esta manera: puede instalar el candado más resistente del mundo, pero si alguien puede predecir la clave, el candado no sirve de nada. Las matemáticas del cifrado que protegen sus comunicaciones pueden romperse no por una debilidad matemática, sino por una aleatoriedad predecible.
Cómo crean aleatoriedad los ordenadores
Los ordenadores son máquinas deterministas. Dados los mismos datos de entrada, producen los mismos resultados. Esto es lo opuesto a la aleatoriedad. Para generar números impredecibles, los sistemas operativos recopilan entropía de fuentes físicas: variaciones en el tiempo de las pulsaciones de teclas, operaciones de disco, llegadas de paquetes de red y ruido electrónico en componentes de hardware.
Los sistemas Linux modernos mantienen un único grupo de entropía respaldado por un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) basado en ChaCha20. Las interrupciones de eventos de hardware aportan fluctuaciones temporales que alimentan la entrada del grupo[s]. Una vez que este grupo acumula al menos 256 bits de entropía estimada, el sistema puede producir resultados criptográficamente robustos de forma indefinida.
Un CSPRNG debe cumplir dos propiedades críticas. La primera, la prueba del siguiente bit: dado cualquier secuencia de bits de salida, ningún algoritmo eficiente puede predecir el siguiente bit con una probabilidad significativamente mayor al 50 %[s]. La segunda, el secreto hacia atrás: incluso si un atacante compromete el estado actual del generador, no puede determinar qué números se generaron previamente[s].
Cuando falla la aleatoriedad: catástrofes en el mundo real
La historia ofrece ejemplos aleccionadores de lo que ocurre cuando la generación de claves criptográficas depende de una aleatoriedad débil.
Divulgada en 2008, la vulnerabilidad de Debian OpenSSL surgió de un cambio específico de Debian subido por primera vez en septiembre de 2006. El error dejó el ID del proceso como la única fuente efectiva de aleatoriedad para OpenSSL en los sistemas Debian afectados[s][s]. En lugar del espacio de búsqueda previsto de 340.282.366.920.938.463.463.374.607.431.768.211.456 valores, los atacantes podían enumerar 32.767 posibilidades derivadas del PID para muchas claves afectadas.
A finales de 2010, fail0verflow reveló un fallo en la firma de PlayStation 3: el software de firma de Sony utilizaba un número constante donde el cálculo de la firma requería un valor verdaderamente aleatorio e impredecible. Ese error permitió a los hackers calcular la clave privada de firma de Sony[s].
En 2012, los investigadores realizaron una operación matemática simple (calcular el máximo común divisor) en 11 millones de módulos públicos RSA distintos y obtuvieron claves privadas para el 0,50 % de los hosts TLS y el 0,03 % de los hosts SSH en su escaneo. Reprodujeron un agujero de entropía en el arranque del generador de números aleatorios de Linux en condiciones que probablemente ocurrían en dispositivos sin cabeza y embebidos[s].
Estos no son incidentes aislados. La aleatoriedad débil ha causado vulnerabilidades de seguridad recurrentes a lo largo de décadas de computación. En 2024, un error sutil en PuTTY (versiones 0.68 a 0.80) introdujo un sesgo estadístico en la generación de nonces ECDSA, lo que permitió a los atacantes recuperar claves privadas de firma a partir de aproximadamente 60 firmas[s].
El umbral de los 256 bits
¿Por qué 256 bits? No es un requisito universal para cada clave criptográfica, pero es un objetivo común de alta resistencia de seguridad y el umbral de siembra utilizado por el generador de números aleatorios de Linux. Una clave de 256 bits tiene alrededor de 1,16 × 1077 valores posibles—un espacio de claves astronómicamente grande. Incluso si un atacante pudiera verificar un billón de claves por segundo, agotar este espacio llevaría más tiempo que la edad del universo.
La Publicación Especial 800-133 Rev. 2 del NIST es la recomendación final actual del NIST para la generación de claves criptográficas, mientras que la Rev. 3 se publicó como un borrador público inicial en abril de 2026. El NIST describe la criptografía como algo que depende de un algoritmo y una clave criptográfica, y la recomendación cubre la generación de claves gestionadas y utilizadas por algoritmos criptográficos aprobados[s][s]. El requisito práctico es una resistencia de seguridad adecuada para el algoritmo, no que cada clave criptográfica contenga exactamente 256 bits de entropía.
Más allá de la computación clásica: preocupaciones poscuánticas
Las computadoras cuánticas amenazan los fundamentos matemáticos de la criptografía actual. El algoritmo de Shor puede factorizar números grandes exponencialmente más rápido que los métodos clásicos, lo que podría romper el RSA. También resuelve el problema del logaritmo discreto que sustenta la criptografía de curva elíptica[s].
La generación de claves criptográficas poscuánticas utiliza problemas matemáticos diferentes. El problema de Aprendizaje con Errores en Módulos (MLWE, por sus siglas en inglés) subyace al algoritmo ML-KEM estandarizado por el NIST en 2024[s]. En términos simplificados, los problemas de la familia LWE implican encontrar un vector secreto s dado (A, b) donde b = A·s + e mod q, siendo A una matriz aleatoria y e un pequeño vector de error[s]. La adición de ruido hace que este problema sea difícil incluso para computadoras cuánticas, ya que se mapea al Problema del Vector Más Cercano en retículos.
Pero incluso los algoritmos poscuánticos no son inmunes a la aleatoriedad débil. El FIPS 203 establece que las garantías de seguridad de ML-KEM dependen de que varios valores permanezcan en secreto, incluida la aleatoriedad utilizada por las dos partes[s]. La dureza matemática del algoritmo se vuelve irrelevante cuando la aleatoriedad que lo alimenta puede adivinarse.
Arquitectura del grupo de entropía
La generación de claves criptográficas moderna comienza con la recopilación de entropía. El kernel de Linux mantiene un único grupo de entropía respaldado por un CSPRNG basado en ChaCha20. Las interrupciones de eventos de hardware, incluidas las pulsaciones de teclas, las finalizaciones de disco, la temporización de llegada de paquetes de red y los eventos USB, aportan fluctuaciones temporales que alimentan la entrada del grupo[s]. El grupo utiliza BLAKE2s (desde el kernel 5.17) para el hash de entrada, incorporando nueva entropía al estado existente.
La distinción crítica: la estimación de entropía (bits de entrada impredecible mezclados) es independiente de la generación de salida (bytes pseudoaleatorios producidos). Una vez que el grupo alcanza el umbral de siembra de 256 bits, el CSPRNG ChaCha20 produce salida con garantías de seguridad criptográfica de forma indefinida.
Antes del kernel 5.6, /dev/random se bloqueaba cuando las estimaciones de entropía caían por debajo del umbral, mientras que /dev/urandom devolvía salida sin las mismas semánticas de bloqueo. Desde el kernel 5.6, /dev/random ya no se bloquea después del arranque inicial, pero las páginas del manual de Linux actuales aún advierten que /dev/urandom puede devolver datos antes de la inicialización durante el arranque temprano. La llamada al sistema getrandom(2), introducida en el kernel 3.17, es la interfaz preferida para aplicaciones sensibles al arranque temprano porque se bloquea hasta que el grupo de entropía se inicializa, a menos que se establezca GRND_NONBLOCK[s][s].
Propiedades de seguridad de los CSPRNG
Un generador de números pseudoaleatorios criptográficamente seguro debe cumplir requisitos formales de seguridad. La prueba del siguiente bit exige que, dada cualquier secuencia de salida, ningún algoritmo de tiempo polinomial pueda predecir el siguiente bit con una probabilidad significativamente mayor al 50 %[s]. La resistencia a la extensión de compromiso de estado garantiza que, si un atacante compromete el estado interno, no pueda determinar los números generados antes del compromiso[s].
El CSPRNG utiliza una función criptográfica unidireccional segura (una función hash como SHA-256 o un cifrado por bloques como AES) para mezclar el estado interno y producir salida. La salida se retroalimenta al estado interno[s]. La Publicación Especial 800-90A Rev. 1 del NIST especifica mecanismos DRBG (Generador Determinista de Bits Aleatorios) aprobados basados en funciones hash y cifrados por bloques[s].
Modos de fallo en la generación de claves criptográficas
La vulnerabilidad de Debian OpenSSL, divulgada en 2008 e introducida por un cambio específico de Debian subido por primera vez el 17 de septiembre de 2006, demuestra un fallo catastrófico de entropía[s]. El error dejó solo el ID del proceso (PID) como entrada efectiva de aleatoriedad[s]. Dado que los PID de Linux suelen oscilar entre 0 y 32.767, muchas claves afectadas se redujeron a un conjunto enumerable que podía precalcularse.
La investigación de 2012 «Mining Your Ps and Qs» explotó un fallo más sutil. La generación de claves RSA requiere seleccionar dos primos grandes aleatorios p y q; el módulo público N = p × q. Cuando dos claves comparten un factor primo (es decir, N₁ = p × q₁ y N₂ = p × q₂), calcular gcd(N₁, N₂) revela p, factorizando inmediatamente ambas claves. Los investigadores calcularon MCD en 11 millones de módulos RSA distintos y obtuvieron claves privadas para el 0,50 % de los hosts TLS y el 0,03 % de los hosts SSH en su escaneo, con claves débiles concentradas en dispositivos sin cabeza y embebidos que generaban claves con entropía insuficiente[s].
La vulnerabilidad de PuTTY de 2024 (CVE-2024-31497) implicó un sesgo en el nonce ECDSA. ECDSA requiere un nonce k único e impredecible para cada firma. El generador de firmas P-521 de PuTTY producía valores de nonce cuyos nueve bits superiores siempre eran cero, introduciendo un sesgo estadístico. A partir de aproximadamente 60 firmas, un atacante podía recuperar la clave privada de firma[s].
Generadores de números aleatorios por hardware y límites de confianza
La instrucción RDRAND de Intel (Ivy Bridge, 2012) y la implementación de AMD (Zen, 2017) proporcionan generación de números aleatorios por hardware. Sin embargo, la dependencia exclusiva de un generador de números aleatorios por hardware plantea preocupaciones de confianza. En 2019, los sistemas AMD Ryzen con ciertas versiones de firmware devolvían valores constantes desde RDRAND, un error confirmado que debilitaría catastróficamente cualquier sistema que confiara exclusivamente en él[s].
El comportamiento actual del kernel combina la salida de RDRAND con el grupo de entropía como una entrada más. Esta defensa en profundidad garantiza que el hardware comprometido no pueda, por sí solo, comprometer el grupo si otras entradas de entropía permanecen independientes.
Generación de claves poscuánticas
El algoritmo de Shor reduce los problemas de factorización de enteros y logaritmo discreto a la búsqueda de períodos, resoluble en tiempo polinomial en una computadora cuántica[s]. Esto amenaza al RSA, Diffie-Hellman y la criptografía de curva elíptica.
La generación de claves criptográficas poscuánticas se basa en problemas basados en retículos. El problema de Aprendizaje con Errores en Módulos (MLWE) subyacente a ML-KEM implica encontrar un vector secreto s dado (A, b) donde b = A·s + e mod q, siendo A una matriz aleatoria y e un pequeño vector de error[s]. La adición de ruido hace que este problema sea difícil incluso para computadoras cuánticas, ya que se mapea al Problema del Vector Más Cercano en retículos.
Pero los requisitos de entropía no se relajan para los sistemas poscuánticos. El FIPS 203 establece que las garantías de seguridad de ML-KEM dependen de que varios valores permanezcan en secreto, incluida la aleatoriedad utilizada por las dos partes[s]. La dureza matemática no puede compensar entradas predecibles.
Derivación de claves y estándares de billeteras
Las billeteras de criptomonedas implementan la derivación jerárquica de claves siguiendo los estándares BIP-32, BIP-39 y BIP-44. Estos protocolos transfieren entropía a números aleatorios, luego a frases mnemotécnicas y, finalmente, a claves jerárquicas que controlan activos[s]. Algunas billeteras de hardware aíslan la generación de claves en hardware dedicado con generadores de números aleatorios verdaderos, separando la recopilación de entropía de sistemas operativos de propósito general potencialmente comprometidos.
