¿Un RNG más rápido que/dev/random pero criptográficamente útil?

Question

He comenzado un trabajo que requiere algunos bytes aleatorios de calidad, como 32 a la vez para un vector de inicialización para ciertas aplicaciones criptográficas. Mi problema es que esto puede requerirse varias veces al mismo tiempo y no puedo permitirme bloquear los problemas del bloque /dev/random para esperar a que haya más recopilación de entropía.

Podría usarlo para inicializar otros algoritmos, por ejemplo, lo que /dev/urandom puede hacer; sin embargo, no confío en lo que no puedo entender, no tengo ningún recurso disponible en su método ni sé si sigue siendo el mismo entre muchas versiones de kernel, prefiero un método bien definido de algún tipo.

¿Conoces algún método que se te ocurra sobre los PRNG estándar que serían lo suficientemente adecuados para usar para la generación de claves (simultáneas) y similares?

¿Serían suficientes ciertos cifrados como RC4 con una gran semilla para generar resultados aleatorios? (He visto una implementación de/dev/frandom que usa esto, sin embargo no estoy del todo seguro).

Si esto significa algo, estoy en un servidor Debian sin cabeza, por falta de entropía.

Answer 1

La respuesta es simple: use /dev/urandom, no /dev/random. /dev/urandomes criptográficamente seguro, y no se bloqueará. La "superioridad" de /dev/random sobre /dev/urandom existe solo en una configuración teórica específica que no tiene sentido si los bytes aleatorios se van a usar con casi cualquier algoritmo criptográfico "normal", como el cifrado o las firmas.

Ver this para más detalles.

(Confía en mí, soy un criptógrafo.)

Answer 2

considerar el uso de un generador de números aleatorios de componentes físicos. Por ejemplo, entropy key o Whirlygig. Usar /dev/urandom en su lugar evitará el bloqueo, pero puede (dependiendo de su nivel de paranoia) degradar la seguridad (generará más bits aleatorios que la entropía de entrada, por lo que en teoría la salida es predecible; esto no es un problema si está simplemente utilizándolo para IVs)

Answer 3

Puede intentar usar la salida (o un hash de la misma) de /bin/ps -A v o /bin/ps -A s. No estoy seguro, sin embargo, si ese comando está disponible en todas o la mayoría de las distribuciones de Linux.

Si decide usar /dev/urandom, debe calcular la entropía de los bytes aleatorios generados a partir de esa fuente, preferiblemente el min-entropy.

Answer 4

en una CPU moderna, con la aceleración de hardware AES, se puede llegar fácilmente más de 1 GiB/s de datos aleatorios mediante el cifrado de una cadena de ceros utilizando una contraseña aleatoria (de /dev/urandom), como se muestra por another answer on serverfault. Tenga en cuenta que la contraseña aleatoria se pasa como una tubería, por lo que no aparece en la lista de procesos.

En mi máquina, este enfoque es aproximadamente 100 veces más rápido que /dev/urandom:

$ openssl enc -aes-256-ctr -pass file:<(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64) -nosalt < /dev/zero | pv > /dev/null 
11.2GiB 0:00:09 [1.23GiB/s] [   <=>       ] 
$ 
$ # Let's look at /dev/urandom for comparison: 
$ pv </dev/urandom> /dev/null 
    48MiB 0:00:04 [12.4MiB/s] [  <=>         ] 

Si pones esto en un script de shell, puede fácilmente tubería en otros procesos:

$ cat ~/.bin/fast_random 
#!/bin/bash 
openssl enc -aes-256-ctr \ 
    -pass file:<(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64) \ 
    -nosalt < /dev/zero