¿Sería seguro generar un número aleatorio usando AES?

Lo que estás describiendo es un PRNG personalizado basado en AES. Cifrar los valores sucesivos de un contador con AES y una clave secreta es un buen método para crear un PRNG (de hecho, es equivalente a cifrar una larga secuencia de ceros con AES / CTR), siempre que tome cuidado de lo siguiente:

• Debe usar el cifrado de bloque "tal cual": codifique el contador como un solo bloque de 16 bytes, procesarlo con AES (sin "modo de cifrado de bloque"), obtenga los siguientes 16 bytes pseudoaleatorios. Incrementa el contador y el bucle.

• Esto no será más fuerte que la clave de cifrado es secreta. ¡Mantenga la llave segura!

• Por supuesto, esto supone que ya tiene una clave secreta, lo que implica que se usó algún otro PRNG criptográficamente seguro en algún momento. Un PRNG no crea aleatoriedad, expande alguna aleatoriedad inicial (la "semilla", aquí la clave AES) en un largo flujo de bytes pseudoaleatorios.

• Este PRNG se basa en que nunca reutiliza un valor de contador. Por lo tanto, debe asegurarse de que el contador siempre esté aumentado y no pueda ser forzado a "rebobinar". Esto no es tan fácil como parece, en particular en dispositivos incrustados, donde el almacenamiento permanente de lectura-escritura es muy importante, y el usuario (quien puede ser el atacante) puede forzar el reinicio del hardware en cualquier momento (retirando la batería).

• AES es un cifrado de bloque, es una permutación del espacio de valores de bloque. Como tal, nunca emitirá dos veces el mismo bloque de 16 bytes, lo que se desvía de lo que produciría una verdadera fuente aleatoria. Esto puede comenzar a mostrar (estadísticamente) después de aproximadamente 2 bytes ⁶⁸ , que es lo suficientemente alto como para no ser un problema. Sin embargo, piense dos veces antes de intentar el mismo truco con un cifrado de bloque con bloques más pequeños (3DES, Blowfish ...).

Una mejora puede consistir en volver a generar una nueva clave AES cada vez que se inicie el servidor, utilizando /dev/urandom . De esa manera, no hay llave para almacenar en ningún lugar. De hecho, no hay necesidad de reutilizar siempre la misma clave.

(Podría decirse que es incluso más sencillo usar el PRNG fuerte que ya está allí, por ejemplo, /dev/urandom . Cambiar a un PRNG personalizado como el que imaginas es bastante injustificado; a menos que necesites pseudorandom bytes a más de 10 megabytes por segundo, lo que puede suceder en algunos casos, pero es extraño. Si necesita lotes de bytes pseudoaleatorios, puede considerar usar otros algoritmos más especializados como < a href="http://www.ecrypt.eu.org/stream/"> estos cifrados de flujo .)

En teoría, sí, pero hay preocupaciones prácticas.

Como generador de números pseudoaleatorios, funciona bien. Pero para hacer un CSPRNG fuera de él, tendría que comenzar con una clave aleatoria criptográficamente segura ... y para obtener una clave aleatoria criptográficamente segura, necesita un CSPRNG. Este es un problema de la gallina y el huevo: para crear un CSPRNG a partir de AES, es necesario que ya tenga un CSPRNG.

¿Por qué harías eso? En la mayoría de los casos, no tendría mucho sentido: si tiene acceso a un CSPRNG para hacer su clave, entonces también puede usarla directamente. Sin embargo, todavía hay casos en los que puede ser útil. Por ejemplo, si está codificando en una situación en la que no tiene acceso a un CSPRNG, pero sí tiene acceso a una clave secreta que se creó con una (y usted sabe que esta clave se ha mantenido seguro), entonces usted podría usar AES para hacer números aleatorios criptográficamente seguros a partir de la clave. Sin embargo, los problemas de implementación mencionados en otras respuestas todavía se aplican.

Creo que la salida debería parecer bastante aleatoria. Pero es, sin embargo, una identificación muy predecible, su clave privada es conocida. Así que los números generados tienen muy poca entropía. Llamaría al resultado PRNG pero nunca SPRNG o CSPRNG.