Entropy Mixing

Imagina dos registros del mismo suceso. Los nombres de archivo cambian, pero el segundo registro no añade una incógnita independiente. Del mismo modo, los tiempos de llegada de paquetes y de acceso al disco pueden estar relacionados. NIST SP 800-90B advierte que no basta con sumar las estimaciones de entropía de fuentes dependientes. Primero hay que determinar qué sigue siendo incierto si el atacante conoce también las otras entradas. [1]

Un hash es una huella calculada a partir de datos. Pero si el atacante conoce todas las entradas, puede calcular el mismo resultado. Ni un hash largo ni una constante pública añadida las convierten en un secreto. RFC 4086 distingue entre mezclar incertidumbre disponible y producir más valores de forma determinista. Una mezcla bien diseñada aprovecha lo que realmente aportan las fuentes; no sustituye la entropía que falta. [2]

XOR compara bits: si son iguales, da cero; si son distintos, da uno. Por eso X XOR X = 0: mezclar un valor con su copia elimina aquí toda incertidumbre. En cambio, si una entrada es aleatoria uniforme e independiente de la otra, el resultado sigue siendo uniforme. RFC 4086 muestra así por qué importan las condiciones. No es una receta para construir un generador casero de carteras. [2]

Al evaluar un diseño, pregunta de dónde vienen sus entradas y qué puede hacerles un atacante. HKDF, un método para derivar claves criptográficas, utiliza una entrada auxiliar llamada salt. No tiene que ser secreta, pero RFC 5869 supone que es independiente del material inicial de la clave y exige impedir que un atacante la elija o modifique. Salt es aquí el nombre de un parámetro. Ni la lista de fuentes ni un resultado de aspecto aleatorio garantizan seguridad si falla una fuente. [4]

NIST SP 800-90B parte de una fuente principal de ruido. Permite añadirle resultados de otras fuentes si los datos pasan juntos por un método de procesamiento aprobado, llamado conditioning. En ese marco no les atribuye entropía adicional. Por tanto, más entradas no elevan automáticamente la cantidad reconocida. Es una regla de esa evaluación concreta, no una afirmación de que las demás fuentes nunca puedan ayudar. [1]

La diferencia aparece en OpenSSL 3.5, una biblioteca criptográfica que los programas pueden usar para cifrado y números aleatorios. Su función RAND_add() mezcla datos de un búfer, una zona de memoria destinada a guardarlos. num indica cuántos bytes se leen; randomness estima su entropía en bytes desde cero hasta num. El tamaño de la zona de memoria no demuestra esa estimación. El generador predeterminado normalmente se inicializa y repone entropía automáticamente desde fuentes del sistema. [3]

Incorporar entropía nueva a un generador se llama reseeding. Es distinto de añadir datos cualesquiera. La documentación OpenSSL 3.5 explica que, en modo FIPS, sujeto a reglas para módulos criptográficos, los datos aportados por la aplicación no se aceptan como fuente de entropía fiable. Se mezclan solo como entrada adicional y no cuentan como reseed completo. Llamar a RAND_add() por sí solo no demuestra esa renovación. [3]

HKDF, descrito en RFC 5869, divide el trabajo en HKDF-Extract y HKDF-Expand. El primer paso concentra la entropía disponible en una clave intermedia; el segundo deriva de ella datos con la longitud requerida. No obtiene así otro secreto independiente. El parámetro info permite vincular el resultado a su uso, por ejemplo indicar para qué servirá una clave derivada. Ese contexto no sustituye datos iniciales de calidad ni demuestra que se haya creado entropía. [4]