¿Qué problemas surgen al usar / dev / urandom de Linux para generar claves criptográficas?

Question

A partir de Linux 5.1, /dev/randomya no utiliza el grupo de bloqueo. Hay una charla sobre el cambio en la página Eliminación del grupo de bloqueo de Linux / dev / random

Creo que el grupo de bloqueo de Linux ha dejado de ser útil. El CRNG de Linux genera una salida que es lo suficientemente buena para usar incluso para la generación de claves. El grupo de bloqueo no es más fuerte de ninguna manera material, y mantenerlo requiere mucha infraestructura de dudoso valor.

Esta serie no debe romper ningún programa existente. / dev / urandom no se modifica. / dev / random seguirá bloqueándose justo después de arrancar, pero bloqueará menos de lo que solía hacerlo. getentropy () con banderas existentes devolverá una salida que es, para propósitos prácticos, tan fuerte como antes.

Lutomirski señaló que todavía existe la cuestión abierta de si el núcleo debería proporcionar los llamados "números aleatorios verdaderos", que es, hasta cierto punto, lo que se supone que debe hacer el grupo de bloqueo. Solo ve una razón para hacerlo: "el cumplimiento de las normas gubernamentales". Sugirió que si el kernel proporcionara eso, debería hacerse a través de una interfaz completamente diferente, o ser enviado al espacio del usuario proporcionando una forma de extraer muestras de eventos sin procesar que podrían usarse para crear tal grupo de bloqueo.

y después

Para los criptógrafos y otros que realmente necesitan un TRNG, Ts'o también está a favor de proporcionarles una forma de recopilar su propia entropía en el espacio de usuario para usarla como mejor les parezca. La colección de entropía no es algo que el kernel pueda hacer de manera confiable en todos los diferentes hardware que admite, ni puede estimar la cantidad de entropía proporcionada por las diferentes fuentes, dijo. (Las negritas son mías)

Entonces, ¿qué problemas hay al usar Linux /dev/urandompara generar claves criptográficas?

Answer 1

El uso /dev/urandompara generar claves criptográficas o secretos puede ser un problema cuando el estado del sistema operativo no es único. Este es el caso típico cuando una máquina virtual se inicia desde una plantilla: el estado del CSPRNG se puede compartir entre varias máquinas virtuales. En casos similares a este, es importante usar /dev/randomo en getrandom()lugar de /dev/urandom, para que la salida del CSPRNG se bloquee hasta que haya recolectado suficiente entropía.

Por supuesto, los clones de VM deben reiniciarse o iniciarse desde un estado de apagado para que el recuento de entropía se restablezca a cero.

La salida de /dev/urandomy /dev/randomproviene de ChaCha20. Para considerar inseguro crear claves criptográficas una vez que el estado interno de ChaCha20 se inicializa con suficiente entropía, uno tiene que:

• conocer el estado interior de ChaCha20,
• o romper el cifrado ChaCha20, que hoy se considera uno de los más seguros.

El problema restante es cómo contar la entropía. El kernel de Linux es extremadamente conservador en este punto, y el estado interno del CSPRNG probablemente tenga mucha más entropía de la que se cuenta (alrededor de dos órdenes de magnitud más). Sin embargo, contarlo con exactitud es matemáticamente imposible.

Descargo de responsabilidad: esta respuesta es válida para el kernel de Linux desde la versión 4.8 hasta la versión 5.9 , que es la última versión en el momento de escribir esta respuesta. El CSPRNG de Linux fue refactorizado en gran medida en las versiones 4.8 ( introducción del cifrado ChaCha20 ) y en la versión 5.6 ( simplificación de la arquitectura ), con cambios menores introducidos en la versión 4.17 y en el camino.