linux - cryptsetup - ¿Se considera/dev/random verdaderamente aleatorio?
archlinux cryptsetup (3)
Por ejemplo, ¿podría usarse para generar una tecla de almohadilla de una sola vez?
Además, ¿cuáles son sus fuentes y cómo podría usarse para generar un número aleatorio entre xe y ?
Estrictamente hablando, /dev/random no es realmente completamente al azar. /dev/random alimenta de fuentes de hardware que se supone que son impredictibles de alguna manera; luego mezcla dichos datos usando funciones (funciones hash, en su mayoría) que también se supone que son unidireccionales. Entonces, la "verdadera aleatoriedad" de /dev/random es relativa a la seguridad inherente de las funciones de mezcla, seguridad que no está más garantizada que la de cualquier otra primitiva criptográfica, en particular, el PRNG oculto en /dev/urandom .
La diferencia entre /dev/random y /dev/urandom es que el primero intentará mantener una estimación (lo que significa "una suposición descabellada") de cuánta entropía ha reunido, y se negará a generar más bits que esa. Por otro lado, /dev/urandom producirá felizmente megabytes de datos de la entropía que tiene.
La diferencia de seguridad entre los dos enfoques no tiene sentido a menos que suponga que los algoritmos criptográficos "clásicos" pueden romperse, y utiliza uno de los pocos algoritmos de teoría de la información (por ejemplo, OTP o el intercambio secreto de Shamir ); y, incluso entonces, /dev/random se puede considerar como más seguro que /dev/urandom solo si las funciones de mezcla aún se consideran unidireccionales, lo que no es compatible con la idea de que un algoritmo criptográfico clásico pueda romperse. Entonces, en la práctica e incluso en teoría, no hay diferencia alguna. Puede usar la salida de /dev/urandom para una OTP y no se romperá debido a cualquier estructura interna a /dev/urandom - la administración real de la secuencia obtenida será el punto débil (especialmente el almacenamiento a largo plazo). Por otro lado, /dev/random tiene problemas prácticos muy reales, a saber, que puede bloquearse en instantes intempestivos. Es realmente fastidioso cuando un sistema operativo automatizado bloquea (¡durante horas!) Porque la generación de la clave del servidor SSH insiste en usar /dev/random y se detiene innecesariamente en la entropía.
Hay muchas aplicaciones que leen /dev/random como una especie de ritual, como si fuera "mejor" que /dev/urandom , probablemente en un nivel kármico. Esto es completamente incorrecto, especialmente cuando el alea se va a utilizar con algoritmos criptográficos clásicos (por ejemplo, para generar una clave pública del servidor SSH). No hagas eso. En su lugar, use /dev/urandom y vivirá más tiempo y más feliz. Incluso para una almohadilla de una sola vez.
(Para completar, hay una peculiaridad con /dev/urandom tal como se implementa en Linux: nunca se bloqueará, incluso si no ha reunido ninguna entropía desde el arranque anterior. Las distribuciones evitan este problema al crear una "semilla aleatoria" en tiempo de instalación, con /dev/random , y usando esa semilla en cada arranque para inicializar el PRNG usado por /dev/urandom , una nueva semilla aleatoria se regenera inmediatamente, para el siguiente inicio. Esto asegura que /dev/urandom siempre funciona en un semilla interna suficientemente grande. La implementación de FreeBSD de /dev/urandom se bloqueará hasta que se alcance un umbral de entropía dado, que es más seguro).
Lo único en este universo que se puede considerar verdaderamente es uno basado en los efectos cuánticos. Un ejemplo común es la descomposición radiactiva. Para ciertos átomos, puedes estar seguro solo de la semivida, pero no puedes estar seguro de cuál será el siguiente.
Acerca de /dev/random : depende de la implementación. En Linux utiliza como fuentes de entropía:
El kernel de Linux genera entropía a partir de los tiempos del teclado, los movimientos del mouse y las temporizaciones IDE y pone los datos de caracteres aleatorios a disposición de otros procesos del sistema operativo mediante los archivos especiales / dev / random y / dev / urandom.
Significa que es mejor que los generadores algorítmicos aleatorios, pero tampoco es perfecto. La entropía no se puede distribuir de forma aleatoria y puede estar sesgada.
Esto fue filosofía La práctica es que en Linux /dev/random es lo suficientemente aleatorio para la gran mayoría de las tareas.
Hay implementaciones de generadores aleatorios que tienen más fuentes de entropía, incluido ruido en las entradas de audio, sensores de temperatura de la CPU, etc. De todos modos, no son ciertas .
Hay un sitio interesante donde puedes obtener números aleatorios genuinos, generados por la descomposición radiactiva .
/dev/random bloqueará si no hay suficientes datos aleatorios en el conjunto de entropía mientras que /dev/urandom no lo hará. En cambio, /dev/urandom recurrirá a un PRNG ( kernel docs ). De los mismos documentos:
El generador de números aleatorios [pool de entropía] reúne el ruido ambiental de los controladores de dispositivos y otras fuentes en un conjunto de entropía.
Así que /dev/random no es algorítmico, como un PRNG, pero tampoco puede ser "verdaderamente aleatorio". Los movimientos del mouse y los tiempos de pulsación tienden a seguir patrones y se pueden usar para explotar, pero deberá sopesar el riesgo en función de su caso de uso.
Para obtener un número aleatorio entre y usando /dev/random , suponiendo que esté contento con un número entero de 32 bits, podría echarle un vistazo a la forma en que lo hace Java java.util.Random class ( nextInt() ) , sustituyendo en el código apropiado para leer de /dev/random para el método nextBytes() .