Un sistema pide 32 bytes y recibe una cadena distinta cada vez. Eso no demuestra que haya obtenido 256 bits de seguridad. Los bytes podrían proceder de un contador, de una semilla de 20 bits o de un generador cuyo estado fue copiado junto con una máquina virtual. La salida puede verse desordenada, superar pruebas estadísticas y aun ser predecible para quien conoce el proceso.
La aleatoriedad criptográfica no se evalúa por apariencia. Se reconstruye una cadena: qué fenómeno aporta incertidumbre, qué sabe el adversario, cómo se estima y vigila la fuente, cómo se inicializa y actualiza el generador, y qué propiedad exige cada valor producido. Una clave, un salt, un nonce y un token pueden tener la misma longitud y contratos completamente distintos.
Cinco preguntas detrás de «random»
Conviene separar cinco propiedades:
- Distribución. ¿Con qué probabilidades aparecen los valores? Una salida uniforme reparte la probabilidad entre todos los valores del espacio.
- Impredecibilidad. ¿Puede el adversario anticipar el próximo valor con ventaja útil, dado lo que observa y conoce?
- Entropía. ¿Cuánta incertidumbre aporta la fuente bajo un modelo de conocimiento del adversario?
- Unicidad. ¿Puede repetirse un valor dentro del alcance que importa, por ejemplo bajo la misma clave?
- Frescura. ¿Pertenece el valor a esta ejecución y no a una anterior repetida o restaurada?
No son sinónimos. Un contador ofrece unicidad si su estado persiste y hay un solo emisor, pero es predecible. Una muestra aleatoria puede ser impredecible y aun colisionar. Un timestamp cambia y parece fresco, pero un atacante puede adivinarlo. Una secuencia pseudorrandom bien construida puede ser indistinguible de una aleatoria para el adversario y, sin embargo, quedar determinada por su estado interno.
La pregunta profesional no es «¿es random?», sino «¿qué propiedad necesita este campo, contra quién y durante qué intervalo?».
Entropía: incertidumbre, no decoración
La entropía no es una sustancia que se añade a un archivo. Describe una distribución y un modelo de conocimiento. Si una fuente produce 256 valores equiprobables, ofrece ocho bits de incertidumbre. Si un valor aparece con mucha más probabilidad que los demás, el espacio nominal exagera el trabajo del atacante.
Para seguridad interesa especialmente la min-entropía, que se concentra en el resultado más probable. Si la probabilidad máxima de cualquier resultado es (p_{max}), la min-entropía es (-\log_2(p_{max})). Un resultado con 1/16 de probabilidad máxima tiene cuatro bits de min-entropía, aunque esté codificado en 256 bits.
El adversario puede conocer contexto que el operador no incorporó al cálculo: modelo del dispositivo, temperatura, tiempo de arranque, identificador de proceso, estado previo o muestras correlacionadas. Por eso «tiene 256 bits porque ocupa 32 bytes» es una afirmación inválida. RFC 4086 usa el ejemplo de una clave de 128 bits obtenida de una semilla de ocho: el atacante prueba 256 semillas, no (2^{128}) claves.
Una función hash tampoco crea incertidumbre. Puede comprimir y mezclar entradas, eliminar sesgos explotables bajo condiciones y producir una representación conveniente. Pero si el atacante enumera todas las entradas plausibles, calcula el hash de cada una. Codificar en Base64, cifrar con una clave fija o concatenar timestamps tampoco aumenta el conjunto desconocido.
La fuente no es el generador
NIST SP 800-90B modela una fuente de entropía como una fuente de ruido, pruebas de salud y un componente de acondicionamiento opcional. SP 800-90A define mecanismos deterministas de generación. SP 800-90C, final desde septiembre de 2025, especifica construcciones que combinan ambos.
Vista adaptada. Toca el diagrama para ampliarlo.
La fuente de ruido observa un proceso no determinista o suficientemente incierto: jitter, osciladores, fenómenos eléctricos u otras mediciones cuya física y adquisición deben documentarse. Sus muestras crudas pueden tener sesgo, dependencia y fallos.
Las pruebas de salud buscan degradación operacional. SP 800-90B incluye pruebas continuas como repetition count y adaptive proportion, además de pruebas al arranque. Detectan patrones incompatibles con el comportamiento esperado, por ejemplo una muestra atascada o una concentración anómala. No demuestran que cada bit sea impredecible, no reemplazan la caracterización de la fuente y no añaden entropía.
El acondicionamiento transforma muestras para reducir sesgo o concentrar entropía en menos bits. Una función determinista no fabrica incertidumbre: su claim de salida queda limitado por la entrada y por las condiciones de validación. Que el resultado parezca uniforme no rehabilita una fuente rota.
El DRBG recibe material de semilla y mantiene estado secreto. Sus operaciones de instanciación, generación y reseed producen grandes volúmenes de bits a partir de una cantidad limitada de entropía. La expansión es computacional, no física: la seguridad depende de que la semilla y el estado no sean conocidos y de que el mecanismo y su uso respeten límites.
Qué promete un DRBG
Un generador determinista produce siempre la misma secuencia desde el mismo estado. Esto no es un defecto accidental; permite construir y analizar el mecanismo. La propiedad buscada es que, sin conocer el estado, el adversario no distinga con ventaja práctica la salida de bits uniformes ni prediga salidas protegidas.
NIST SP 800-90A Rev. 1 estandariza Hash_DRBG, HMAC_DRBG y CTR_DRBG. El ciclo conceptual es:
- Instantiate: combina entropy input con nonce y, opcionalmente, personalization string para crear el estado.
- Generate: deriva salida y actualiza el estado; puede aceptar additional input.
- Reseed: incorpora nuevo entropy input para renovar el estado.
- Uninstantiate: elimina el estado cuando deja de usarse.
Los nombres de los parámetros importan. En esta interfaz, nonce contribuye a distinguir instanciaciones, pero no sustituye la entropía requerida. personalization_string separa usos o instancias, pero puede ser pública. additional_input modifica la evolución del estado, pero no debe contabilizarse como entropía si no satisface ese contrato.
La security strength solicitada no puede superar la que soportan el mecanismo, sus primitivas y el entropy input. Pedir 256 bits a una instancia sembrada con 64 bits no eleva el costo del ataque a 256. Generar un gigabyte tampoco crea un gigabyte de entropía.
Dos propiedades temporales requieren cuidado. La resistencia a reconstruir salidas anteriores después de descubrir el estado suele llamarse backtracking resistance. La prediction resistance busca que un estado comprometido no permita predecir salidas posteriores una vez incorporada entropía fresca. Ninguna aparece por renombrar una función como CSPRNG: depende del mecanismo, destrucción de estados anteriores, reseed y modelo de compromiso.
Por qué normalmente se pide al sistema operativo
Una aplicación corriente no debería diseñar su propia fuente, estimador ni DRBG. El sistema operativo puede reunir eventos de múltiples dispositivos, inicializar un CSPRNG, coordinar concurrencia y exponer una interfaz estable. La aplicación usa la API criptográfica de su plataforma o biblioteca, no rand(), Math.random() ni un PRNG de simulación.
En Linux, getrandom() sin GRND_RANDOM obtiene bytes de la fuente de urandom y bloquea antes de que el pool se haya inicializado. Una vez listo, la interfaz ofrece salida del CSPRNG del kernel. La documentación actual considera /dev/random una interfaz heredada para la mayoría de usos y recomienda getrandom() o /dev/urandom después de inicialización; «más bloqueo» no equivale automáticamente a «más seguridad».
Esta recomendación no convierte toda llamada en infalible. El caller comprueba errores y longitudes, usa la API adecuada a su plataforma y evita generar secretos antes de readiness en entornos de arranque mínimo. Una biblioteca puede añadir buffering o un DRBG por proceso; entonces su comportamiento ante fork, snapshot y restore forma parte del contrato.
Tampoco se usa el CSPRNG para todo. Una simulación que necesita reproducibilidad puede emplear un PRNG rápido con semilla registrada. Mezclar esa API con generación de claves es peligroso, pero reemplazar toda simulación por entropía del kernel desperdicia recursos y dificulta repetir experimentos. La elección sigue al propósito.
Una taxonomía de valores
Vista adaptada. Toca el diagrama para ampliarlo.
Claves
Una clave simétrica nueva necesita impredecibilidad frente al adversario y suficiente fuerza para el algoritmo. Debe permanecer secreta, estar separada por propósito y entrar a un ciclo de vida. Un identificador de clave puede ser público; el material no.
Salts
El salt de password hashing suele ser público y debe ser único por credencial. Evita que hashes iguales revelen contraseñas iguales y hace que la precomputación se pague por salt. No añade fuerza a una contraseña débil como si fuera una clave secreta. Se almacena junto con algoritmo, parámetros y hash.
Nonces e IV
Nonce significa «number used once», pero el requisito exacto lo define la construcción. En AEAD como AES-GCM, RFC 5116 exige nonces distintos para invocaciones bajo una clave; no necesitan ser secretos. Otros esquemas pueden exigir impredecibilidad, y un IV no hereda automáticamente el contrato de otro modo.
Hay tres estrategias comunes:
- un contador persistente y coordinado ofrece unicidad determinista;
- un valor aleatorio suficientemente ancho ofrece unicidad con una probabilidad de colisión que debe presupuestarse;
- una construcción sintética o misuse-resistant puede tolerar algunos fallos mejor, pero sólo bajo su especificación.
La etiqueta «UUID» no demuestra ninguna. Hay versiones, fuentes y truncamientos diferentes. Tampoco demuestra que dos workers, regiones o clones coordinen el mismo espacio bajo la misma clave.
Tokens bearer
Un token de sesión o recuperación concede autoridad a quien lo presenta. Necesita impredecibilidad, suficiente espacio, comparación segura, expiración y normalmente uso único o revocación. Debe evitarse en URLs, logs y analytics. Hashearlo en almacenamiento puede limitar daño de una lectura, pero no corrige un token de baja entropía.
Identificadores
Un ID de objeto necesita unicidad y quizá opacidad, no necesariamente secreto. Aunque sea aleatorio, no debe actuar como autorización: si conocer /invoice/7fa… concede acceso, el ID se volvió una credencial sin controles explícitos. El sistema valida identidad y permiso por separado.
Desafíos
Un challenge de autenticación necesita frescura, binding a sesión/operación y una regla de consumo. Ser impredecible ayuda contra precomputación, pero si el servidor acepta el mismo challenge indefinidamente sigue habiendo replay.
Colisiones: medir en vez de desear
Al elegir valores uniformes aleatorios de un espacio de (2^n), la probabilidad aproximada de al menos una colisión después de (q) muestras, mientras sea pequeña, es (q(q-1)/2^{n+1}). Este es el efecto cumpleaños: la probabilidad crece aproximadamente con el cuadrado del volumen.
No basta decir «128 bits es enorme». Se calcula el número de emisores, tasa, vida de clave, reintentos y truncamientos. También se define qué ocurre si el backend detecta un duplicado. Para nonces, el dominio relevante suele ser por clave, de modo que rotar claves reinicia el espacio sólo si la asignación entre clave y contador es correcta.
Un contador evita colisiones aleatorias, pero introduce estado. Debe persistir antes de usar el valor, sobrevivir reinicios, no retroceder al restaurar backups y asignar rangos distintos a escritores concurrentes. Si se comparte una clave entre regiones, un prefijo por emisor puede separar espacios; ese prefijo también necesita una asignación que no se repita.
Una muestra aleatoria evita coordinación central, pero acepta una probabilidad no nula. Cuando el límite del algoritmo es estricto o el volumen es alto, se siguen sus bounds, no una intuición genérica.
Sesgo por transformación
Obtener bytes seguros no garantiza un resultado uniforme después de transformarlos. El error clásico es calcular x mod m cuando el rango de x no es múltiplo de m. Algunos residuos reciben una preimagen adicional y se vuelven más probables.
La solución general es rejection sampling: tomar una muestra, aceptar sólo el intervalo más grande cuyo tamaño sea múltiplo de m y repetir en caso contrario. Las bibliotecas ofrecen funciones seguras para rangos; conviene usarlas en vez de implementar aritmética propia.
Truncar también reduce el espacio. Veinte bytes codificados en Base64 no contienen más entropía que los veinte bytes; cortar caracteres puede reducirla de manera no evidente si se corta en medio de la codificación. Normalizar mayúsculas, eliminar símbolos o mapear caracteres parecidos comprime aún más el conjunto.
Las pruebas estadísticas son útiles para encontrar errores: patrones, sesgos o regresiones. No certifican impredecibilidad criptográfica. Un cifrador de flujo alimentado con una clave pública fija puede producir secuencias que pasan muchas pruebas y que el atacante reproduce exactamente.
Fork, clonación y rollback
Un DRBG por proceso puede estar correctamente sembrado y aun fallar cuando su estado se duplica. Después de fork, padre e hijo heredan memoria; una biblioteca debe detectar el evento, reseed o delegar al kernel. Una imagen de VM o container puede capturar estado ya inicializado. Al restaurar dos copias, ambas continúan desde el mismo punto.
Vista adaptada. Toca el diagrama para ampliarlo.
El caso más severo combina estado clonado y clave clonada. Las dos instancias emiten el mismo nonce para mensajes distintos bajo AES-GCM. RFC 5116 advierte que esa repetición socava confidencialidad y toda la protección de autenticidad e integridad de la clave. El problema no es que los bytes «se vean poco random»: se violó una precondición concreta.
Añadir PID, hostname o timestamp después del snapshot puede no resolverlo: los valores pueden repetirse, ser predecibles o incorporarse de forma no analizada. Una mitigación defendible identifica clones, obtiene entropía del sistema ya inicializado, reseed/reinstancia el generador y, cuando el protocolo lo exige, asigna una clave o dominio de nonce distinto antes de emitir.
Los contadores sufren el mismo rollback. Restaurar una base a counter=400 después de haber usado hasta 900 repite 401. La persistencia exige monotonicidad fuera del snapshot o rotación de clave al restaurar. «Nunca ocurrió en producción» no es un invariante.
RFC 8937 trata explícitamente la clonación de estado CSPRNG en entornos virtuales y recomienda incorporar información que distinga instancias en su construcción de tags. No autoriza a improvisar mixers en aplicaciones; confirma que identidad de instancia y restauración pertenecen al modelo.
Salud, monitorización y secretos
Una fuente validada necesita límites y respuesta frente a fallos. Si una health test falla, continuar y registrar un warning convierte una señal crítica en decoración. La política define bloqueo, aislamiento, recuperación y revalidación. A la vez, un único fallo no demuestra que todas las claves históricas estén comprometidas; hay que delimitar cuándo comenzó la degradación y qué material se generó.
La observabilidad no debe exponer material que permita reconstruir el generador. No se registran muestras crudas, seeds, estado DRBG, claves, tokens ni nonces secretos por requisito de protocolo. Sí pueden registrarse eventos de inicialización, proveedor, readiness, versión, reseed, contador de fallos, antigüedad y scope de instancia, evitando fingerprints explotables.
Para valores que sólo requieren unicidad, detectar duplicados puede ser un control útil. Para claves y tokens no se centraliza plaintext con el propósito de buscar colisiones: se usan mecanismos adecuados y, si hace falta, identificadores o digests cuidadosamente acotados. La telemetría nunca debe crear una base de secretos.
Caso trabajado: tokens repetidos después de un snapshot
Un servicio de recuperación de cuentas crea tokens de 32 bytes con un DRBG en memoria. Durante una migración, operaciones clona una VM ya arrancada. Ambas copias conservan el mismo estado y comienzan a atender tráfico. Cada una genera la misma secuencia.
El primer síntoma es una violación de unicidad en la tabla. El código reintenta: cada VM avanza igual y choca otra vez. Un parche añade el timestamp en milisegundos; bajo solicitudes simultáneas sigue coincidiendo y, además, el timestamp es público.
La revisión reconstruye el contrato. El token es bearer, por lo que necesita impredecibilidad; debe ligarse a usuario, propósito y expiración; sólo se almacena su digest; y su consumo es atómico y único. El generador debe obtener material del CSPRNG del sistema después de clone detection o pedir bytes directamente por token.
La remediación inmediata detiene emisión en clones, invalida tokens generados durante la ventana, revoca sesiones derivadas, rota secretos auxiliares afectados y revisa logs sin publicar tokens. Luego la imagen se cambia para no capturar estado de aplicación inicializado; cada instancia espera readiness, obtiene identidad efímera, abre el proveedor de randomness tras arrancar y prueba duplicación/snapshot en CI de plataforma.
La investigación no concluye «el algoritmo estaba roto». Concluye que se duplicó un estado cuyo contrato exigía una instancia única. Ese diagnóstico permite reparar arquitectura y valorar el alcance real.
Método de revisión
Para cualquier campo descrito como random:
- Uso: ¿clave, salt, nonce, IV, token, ID, challenge o muestra?
- Propiedad: ¿impredecibilidad, unicidad, frescura, distribución o combinación?
- Dominio: ¿por clave, usuario, dispositivo, sesión, región o vida completa?
- Adversario: ¿qué entradas, timing, estado o muestras conoce?
- Origen: ¿API criptográfica del sistema, DRBG de biblioteca o fuente propia?
- Readiness: ¿puede ejecutarse antes de que la fuente esté inicializada?
- Transformación: ¿hay módulo, truncamiento, normalización o encoding sesgado?
- Estado: ¿qué ocurre con fork, concurrencia, reboot, snapshot y rollback?
- Volumen: ¿qué bound de colisión y límite de generación aplica?
- Fallo: ¿se bloquea emisión, se rota clave y se delimita material afectado?
- Observabilidad: ¿se detectan fallos sin registrar secretos?
- Evidencia: ¿qué estándar, test de integración y operación demuestra cada condición?
La respuesta «usa una función crypto» cubre sólo una parte. La respuesta «es 128-bit» cubre longitud, no origen ni dominio.
Transferencia al capítulo 63
Este capítulo separó generación e incertidumbre de los usos concretos. El capítulo 63 estudiará funciones hash, MAC y KDF: cómo transforman datos y claves, qué propiedades sí aportan y por qué ninguna sustituye una fuente de entropía.
Síntesis
Aleatoriedad estadística, impredecibilidad, entropía, unicidad y frescura responden preguntas distintas. El ancho de una salida no prueba su incertidumbre; un hash y un DRBG determinista no crean entropía física. Una fuente aporta incertidumbre modelada, las health tests detectan ciertos fallos, el acondicionamiento transforma y el DRBG expande un estado secreto.
Las aplicaciones suelen usar el CSPRNG del sistema operativo y respetar readiness, errores y semántica de plataforma. Claves, salts, nonces, tokens e IDs no son intercambiables. El requisito de nonce pertenece a la construcción y a su dominio por clave; un valor público puede ser correcto. Los tokens bearer, en cambio, requieren impredecibilidad y tratamiento de secreto.
Fork, snapshot y rollback pueden duplicar tanto DRBGs como contadores. La defensa no es añadir ruido cosmético, sino reinstanciar con una fuente fresca, separar dominios o claves, preservar monotonicidad y comprobar el ciclo operacional. Las pruebas estadísticas ayudan a detectar defectos; no certifican seguridad frente a un adversario.
Fuentes primarias y documentación técnica
- NIST, SP 800-90A Rev. 1 — Recommendation for Random Number Generation Using Deterministic Random Bit Generators; CSRC, 2015. NIST abrió trabajo preliminar para Rev. 2 en 2025; Rev. 1 sigue siendo la publicación final consultada.
- NIST, SP 800-90B — Recommendation for the Entropy Sources Used for Random Bit Generation; CSRC, 2018, con aviso de errata de 2025.
- NIST, SP 800-90C — Recommendation for Random Bit Generator Constructions; CSRC, 2025.
- IETF, RFC 4086 — Randomness Requirements for Security; RFC Editor, 2005.
- IETF, RFC 5116 — An Interface and Algorithms for Authenticated Encryption; RFC Editor, 2008.
- IETF, RFC 8937 — Randomness Improvements for Security Protocols; RFC Editor, 2020.
- Linux man-pages, getrandom(2), random(4) y random(7); man7.org, consultados 2026-10-06.