En general:
-
/dev/urandom no es menos seguro que /dev/random . De hecho, ambos usan los mismos algoritmos y las mismas semillas. De vez en cuando, /dev/random simplemente se detiene porque alguien, algún día, leyó algo sobre la entropía, no lo entendió, y ahora piensa que la aleatoriedad es algo que se quema con el uso y se debe rellenar regularmente.
( Esta página hace un buen trabajo explicando cosas sobre ese tema.)
-
Puede haber situaciones en las que no haya suficiente entropía disponible en todo el sistema. Estas situaciones no se producen con las distribuciones normales de Linux porque generan y guardan una semilla aleatoria en el momento del arranque, que se utilizará para el siguiente arranque, lo que garantiza de manera efectiva que /dev/urandom sea criptográficamente seguro en todo momento. Para entrar en una de estas situaciones, debes jugar algunos juegos extraños con instantáneas de VM, o usar no una PC, sino un sistema integrado muy limitado; esto está bastante lejos de los contextos donde usaría GnuPG.
-
Es muy notable que en el caso de las instantáneas de VM, la "estimación de entropía" de /dev/random informará alegremente que está lleno de cosas, lo que es, en este caso, muy incorrecto. Es decir, no solo el comportamiento de bloqueo de /dev/random carece de fundamento científico, sino que tampoco se desencadena por completo en el caso práctico (instantáneas de VM) donde se podría temer la pérdida de entropía.
-
También recuerda que los contextos donde /dev/urandom es inapropiado son también contextos donde /dev/random es inapropiado. Usar /dev/random no hará que las cosas sean "más aleatorias"; en el mejor de los casos , se negará a trabajar en lugar de generar una clave de seguridad teóricamente más baja ("teóricamente" porque nada de esto ha resultado nunca en una interrupción práctica, incluso como una demostración en condiciones controladas por el laboratorio) . Como se explicó anteriormente, esto es realmente un "en el mejor de los casos" y no funcionará de esa manera con las instantáneas de VM y el reinicio.
Afortunadamente, toda la actividad involucrada por un arranque implica la recopilación de suficiente entropía para lograr seguridad criptográfica (incluso para salidas de /dev/urandom arbitrariamente largas, incluso). Consulte este artículo para un análisis más detallado. La generación de claves GnuPG no se realiza mediante el kernel en los primeros pasos de arranque; ocurre mucho más tarde, durante la operación normal, cuando el PRNG se ha sembrado correctamente.
Nada de esto impide que algunas personas insistan en bailar ritualmente con entropía. Aparentemente, los autores de GnuPG son parte de esa interpretación teológica específica, ya sea porque lo creen o porque ceden bajo la presión del mercado.
Resumen: usar /dev/urandom en lugar de /dev/random no es no débil para GnuPG. GnuPG se usa en un contexto donde /dev/urandom está correctamente sembrado y logrará toda la imprevisibilidad requerida, y /dev/random no lo hará mejor (no en la práctica, tampoco en teoría). En una situación (instantáneas de VM) donde la salida de /dev/urandom podría ser inadecuada para GnuPG, la salida de /dev/random será igualmente inadecuada por las mismas razones, y el mecanismo de bloqueo de /dev/random no se activará. La conclusión es que cambiar de /dev/urandom a /dev/random por GnuPG es completamente inútil .
... es decir, desde un punto de vista técnico. El uso de /dev/random en lugar de /dev/urandom podría inducir a algún bloqueo que pueda ayudar a persuadir a los débiles de que "está ocurriendo una criptografía seria". No hará las cosas más seguras, pero puede hacer que el usuario se sienta más seguro.