¿Vale la pena aumentar / entrop / random entropía en el software?

La respuesta corta es que devolver /dev/random con la salida de /dev/urandom no disminuirá la seguridad. Para aclarar las cosas (los comentarios indican que no fui lo suficientemente preciso), mi punto es que alimentar a /dev/random con la salida de /dev/urandom es inofensivo (aunque no aumenta la seguridad); también es bastante inútil (excepto como una forma de admitir fácilmente aplicaciones que insisten en usar /dev/random y bloquear en momentos inoportunos sin una buena razón).

Para simplificar las cosas, definamos un modelo operativo del funcionamiento de /dev/random y /dev/urandom :

• Hay un estado interno p que consta de k bytes (para algunos enteros k ).
• Se inyecta entropía adicional x reemplazando p con H ( p , x ), donde H es un "tipo de" función hash. Por ejemplo, el estado actual se concatena con la nueva entropía, el resultado se oculta y la salida de hash es la nueva p .
• La salida se produce utilizando p como entrada para un CSPRNG ; los primeros bytes k son el nuevo valor de p , y los bytes subsiguientes son la salida para esa ejecución.
• /dev/random difiere de /dev/urandom en que ocasionalmente se negará a generar bytes hasta que se inyecte nueva entropía (o se recopile desde el hardware).

(Lo anterior es un modelo conceptual que está lo suficientemente cerca de la implementación real para los propósitos de la discusión actual.)

La seguridad de todo depende de la entropía de p ; En términos generales, la cantidad de p es desconocida para los atacantes. Los atacantes saben que p tiene el tamaño k , por lo que pueden intentar adivinar p por fuerza bruta, que tiene un costo de aproximadamente 2 ^{8 k -1} en promedio. El CSPRNG se considera criptográficamente seguro porque el análisis de muchos bytes de la salida no proporciona información sobre otros bytes de salida, en particular, no proporciona información sobre p (tampoco antes o después de la carrera).

Supongamos ahora que el atacante elige x . Mientras H se comporte como una función hash segura, H ( p , x ) tiene la misma entropía que p : el atacante aún no tiene información sobre p después de la operación. Hablando estrictamente, puede haber un efecto de "reducción de espacio", hasta aproximadamente el tamaño 2 ^{8 k / 2} si el atacante puede hacer el truco de "alimentación de entropía" ^{8 k / 2} veces. Si k es lo suficientemente grande (por ejemplo, 32, para un estado interno de 256 bits), el tamaño del espacio restante todavía es lo suficientemente grande para la seguridad, y esta situación no se puede lograr de todos modos .

Dado que el CSPRNG no proporciona información sobre p , la salida de ese CSPRNG no puede ser peor para la seguridad que un x controlado por un atacante. . Esta es la parte que sería más difícil formalizar de manera académica (esto tomaría algunas páginas para escribirla correctamente). Intuitivamente, el CSPRNG, al usar k bytes de entrada y tomar k bytes de salida, se comporta como un oráculo aleatorio.

Por lo tanto, la alimentación de /dev/random desde la salida de /dev/urandom no reducirá la seguridad.

Por supuesto, esto se basa en la idea de que la función de actualización de estado (para inyección de entropía) y el CSPRNG son funciones "ideales". Si no lo están, entonces estás condenado de todos modos (el comportamiento de bloqueo automático de /dev/random no te salvaría en ese caso).

Desafortunadamente, algunas de las personas que prefieren /dev/random son FIPS y Common Criteria. [EDIT: No puedo encontrar una cita para eso, pero vea en la parte inferior una fuente no oficial] Entonces, si quiere que su software tenga la certificación FIPS / CC, no puede usar /dev/urandom . debe demostrar que mantiene una estimación precisa de su entropía, y debe bloquear cuando la entropía es baja.

Breve reseña:

Todos los generadores de números aleatorios deterministas son tan aleatorios como su semilla. Entropy es una estimación de qué tan aleatorio (o inesperado , o impredecible ) es tu semilla. Para aumentar la entropía de su RNG, necesita mezclar aleatoriedad nueva de una fuente externa. Si tiene acceso a fuentes de datos impredecibles (a menudo con temporización en dispositivos de entrada humana o ruido térmico), entonces con toda seguridad, aliméntelos a /dev/random para aumentar la entropía de su semilla.

El kernel de Linux se mezclará automáticamente en tantas fuentes de aleatoriedad como tenga acceso a, sincronización de paquetes, sincronización de pulsaciones de teclas, aleatoriedad del programador de procesos, generadores de números aleatorios de hardware adjuntos (que están comenzando a incluirse en las placas madre del consumidor ). Así que eso es genial.

El único caso que conozco donde se sabe que /dev/random es débil es en máquinas virtuales sin cabeza, donde literalmente no hay nada de lo que presumir por imprevisibilidad.

Muy bien, vamos a la pregunta real:

  

Quiero estar seguro de que usar un demonio como rngd o haveged para volver a la aleatoriedad en /dev/random , incluso si están basados en /dev/urandom like rngd , en la mayoría de los casos, no es No introducir debilidades.

Mi pregunta es: ¿de dónde obtienen rngd , haveged y /dev/urandom su aleatoriedad? ¿Es realmente una aleatoriedad nueva que viene de fuera de la máquina, o está en una re-hash de /dev/random ?

No puedo hablar con rngd o haveged , pero sé que en Linux /dev/urandom comparte un RNG con /dev/random (consulte esta impresionante perorata , de la cual tomé prestada una imagen a continuación), y en FreeBSD /dev/urandom es literalmente un puntero hacia /dev/random , por lo que con toda probabilidad solo estás devolviendo /dev/random a sí mismo.

No soy lo suficientemente experto para saber si esto introduce debilidades o no, pero ciertamente no está haciendo ningún bien.

Laúnicamenciónde"no / dev / urandom" que puedo encontrar en los documentos FIPS fue un borrador de 2014 que nunca se publicó al público. Incluía la nota a pie de página:

  

Nota2: Se supone que el generador / dev / urandom no proporciona entropía a menos que esté específicamente instrumentado para garantizar un mínimo de 112 bits de entropía disponible en todo momento.

Luego procede a enumerar las formas en que puede garantizar esa entropía. Esto es mucho menos rígido de lo que me habían hecho creer. Genial, hoy he aprendido!

No hagas cosas pesadas con la alimentación de datos de hogwash en / dev / random etc. Si lo desea, puede reemplazar / dev / random con un enlace simbólico a / dev / urandom

Puedes usar haveged o algo así, pero no uses nada sin ninguna entrada externa. (también, especialmente con havaged tenga cuidado si ejecuta hardware virtualizado)

/ dev / random es bastante robusto contra la entrada con mala entropía, pero si le das demasiadas tonterías, ¿quién sabe qué pasa?

/ dev / urandom es bien conocido y probado. Si vinculas / dev / random a él, probablemente no tendrás problemas. ¡Si haces cosas con peces, podrías tener problemas!

También: ¿De qué te gustaría ser responsable: "¡La primera conexión segura a nuestro servidor después de reiniciar toma casi un segundo!" / "Generar muchos certificados es lento" o "Lo que hiciste con nuestro Al azar, todas nuestras llaves están rotas, todos nuestros datos son robados. ¿QUÉ HAN HECHO? "

¡Decidir sabiamente!