Agregar un archivo como fuente de entropía para / dev / random

En primer lugar, para responder a su pregunta directamente: Esto no se puede hacer. A propósito no está permitido.

De hecho, puede escribir en / dev / random y mezclará su entrada en el grupo aleatorio, lo que podría mejorar la calidad de la salida. Pero no actualizará el entropy_count y desbloqueará / dev / random para leer, porque sería cheating . De lo contrario, podrías hacer algo como esto:

cat /dev/urandom > /dev/random  # Sup dawg, I heard you like random pools...

Excepto que puedes. Tipo de.

Hay un ioctl llamado RNDADDENTROPY disponible en / dev / random que actualiza el grupo de entropía y luego incrementa el entropy_count en consecuencia. La idea es permitirle leer un RNG de hardware en el espacio de usuario y volcarlo en el grupo del kernel sin escribir su propio controlador. Hábil. Y mientras que cualquier persona puede volcar su entropía en / dev / random (no puede lastimar ), solo la raíz puede usar RNDADDENTROPY .

Y sí, hay una herramienta por ahí que te permite hacerlo con relativa facilidad; se llama rngd . Su propósito principal es leer un RNG como /dev/hwrandom o la instrucción RDRAND de su procesador, y re-sembrar constantemente su grupo de entropía a medida que disminuye. Pero se necesita un nombre de archivo arbitrario para la entrada, así que sí, incluso puedes hacer esto:

rngd -r /dev/urandom

Lo que, con toda honestidad, no es totalmente diferente a hacer esto:

ln -sf /dev/urandom /dev/random

Pero como dije originalmente, no significa que pueda usar esta herramienta para hacer que el kernel use su archivo como fuente de entropía. Ese bit, Al menos, no está permitido. Puede usarlo como una fuente adicional de entropía combinada con todas las demás, pero no como la única fuente de entropía.

Si está convencido de que su archivo es de aleatoriedad de primer grado, simplemente use eso. No tiene que tener que inyectarlo a través del sistema de estimación de entropía del kernel. Si, en cambio, tiene un mecanismo para generar TRNG, entonces, por supuesto, descargue allí con el resto de las fuentes de entropía; rngd lo hace bastante simple.

No me molestaré en informarle sobre el absurdo absoluto de evitar religiosamente / dev / urandom en servidores reales, como claramente ha escuchado esa conferencia varias veces y ha decidido no escuchar.

Pero para todos los demás, la diferencia entre / dev / random y / dev / urandom solo importa inmediatamente en el inicio en dispositivos sin fuentes razonables de aleatoriedad (como algunos dispositivos integrados), donde las condiciones de inicio son repetibles con precisión, y donde El grupo aleatorio no se guarda entre las botas. En todos los demás casos, cualquier ataque teórico contra / dev / urandom requeriría técnicas y tecnología que literalmente no existen, y se espera que nunca existan, nunca.

En la redacción de su pregunta, parece que tiene la impresión de que / dev / random produce el resultado de un TRNG, mientras que / dev / urandom usa un PRNG. Esto no es exacto. La única diferencia en la salida es que random se "bloqueará" si genera bytes más rápido que si observa eventos aleatorios, mientras que urandom no lo hará. De lo contrario, ambos ejecutan exactamente el mismo código en sus grupos respectivos. Tampoco emite directamente los bits en bruto desde un TRNG. Ambos utilizan eventos aleatorios para volver a generar un PRNG constantemente.

Teniendo en cuenta todo lo que ha dicho, probablemente debería leer directamente desde su archivo en lugar de desde / dev / random. Como aparentemente no confía en cómo funciona / dev / random (quizás haya leído este documento ), entonces sea declarativo. y no confíes en él.

A estas alturas, debería darse cuenta de que no debería haber manera de permitir que alguien pueda inyectar datos directamente en el grupo de entropía. De lo contrario, sería un vector de ataque que podría comprometer la generación de claves SSL / TLS, y todos los malos ya lo estarían haciendo.

Si insiste en presionar hacia adelante, vea cómo rng-tools inserta datos en el grupo de entropía. Está diseñado para integrar la salida de un RNG de hardware, y usted podría modificarlo para leerlo desde su archivo en lugar de hacerlo desde un dispositivo de hardware. Mi preocupación es que incluso si proporciona suficientes datos de su archivo, / dev / random puede bloquear si no obtiene suficiente entropía de sus otras fuentes. No se supone que obtenga todos sus bits de entropía de una sola fuente, por lo que no importa qué tan rápido los suministre, creo que podría bloquearse.

Si está utilizando un generador de números aleatorios de hardware real para crear sus archivos, consideraría usar rng-tools para vincularlo directamente al grupo de entropía sin el paso intermedio de enviarlo al sistema de archivos.

Lo bueno de este enfoque es que reduce el riesgo de que su archivo sea una influencia dañina en los números aleatorios (los datos se mezclan con otras fuentes de entropía) y reduce el riesgo de que un atacante copie su archivo y aprenda su Números aleatorios (debido a las otras fuentes de entropía).

En la mayoría de los sistemas Linux, el grupo de entropía utilizado por / dev / random es inicializado en el arranque usando /var/run/random-seed . Si se omitiera este proceso, entonces dos servidores idénticos que usan la misma distribución de Linux pueden tener una secuencia de inicio idéntica y, por lo tanto, tendrían un estado / dev / random idéntico.

Para evitar que esto ocurra, al apagar, el valor actual del grupo de entropía /dev/random se guarda en /var/run/random-seed y luego se restaura al iniciar. Hacer que la piscina de entropía de todos sea un poco diferente, lo que es un gran diseño.

Para aumentar el contador de entropía del kernel se requiere RNDADDENTROPY ioctl.

La forma más sencilla de llamarlo es usar el daemon rngd del paquete rng-tools :

rngd -r /path/to/F

(Nota: rngd esperaba que fuera un dispositivo de hardware, por lo que cuando llegue al final del archivo, se quejará de que la fuente de entropía ya no funciona)