Use USB TRNG como fuente de aleatoriedad para la generación de claves OpenSSL

Use /dev/[u]random tanto para alimentarlo con la entropía del generador de números aleatorios de hardware como para usarlo con cualquier consumidor de bits aleatorios que quiera usar (también OpenSSL se basará en esas interfaces). La forma más sencilla es simplemente canalizar la entrada a / dev / random, pero esto no aumentará el contador de entropía (el conductor tendrá que registrarse como fuente de entropía para hacerlo).

El kernel mezclará la entropía de diferentes fuentes: interrupciones debido a la entrada del teclado y el mouse, la red y la sincronización del disco duro, ... Si agrega su generador de números aleatorios de hardware, obtendrá una combinación de entropía de todos esos fuentes. Al final, cualquier número aleatorio con un número constante agregado seguirá siendo aleatorio, por lo que incluso si el generador de números aleatorios de hardware está completamente predeterminado, no interrumpirá el generador de números aleatorios.

Al menos, tan pronto como se haya agregado suficiente entropía de otras fuentes: la única vez que podría resultar en números aleatorios adivinables es inmediatamente después de que el grupo de números aleatorios no tenga suficiente entropía de otras fuentes.

Recomiendo encarecidamente ver la conferencia de media hora La simple realidad de la entropía. O cómo. Aprendí a dejar de preocuparme y me encantaba el amor al azar celebrado en el Chaos Communication Congress 2015, que tiene una muy buena explicación de cómo los generadores de números aleatorios combinan diferentes fuentes de entropía. También explica por qué no debería importarle demasiado a /dev/random y su contador aleatorio de bits, y en su lugar usa /dev/urandom .

La entropía de inicio insuficiente puede provocar fallas criptográficas catastróficas - lea Extracción de sus Ps y Q: Detección de claves débiles generalizadas en dispositivos de red . Sin embargo, confiar en una fuente de entropía potencialmente cuestionable es solo una leve mejora sobre la entropía insuficiente: solo está reduciendo un conjunto de personas que podrían comprometer su sistema. Afortunadamente, hay generadores de entropía de software de fuente abierta, uno de ellos es CPU Time Jitter por Stephan Muller.

Sin embargo, a menos que tenga un sistema sin cabeza con un SSD, ¿por qué cree que / dev / [u] random no está generando una entropía adecuada? En la mayoría de los casos, el kernel de Linux moderno es lo suficientemente bueno.

Como @ this.josh y estas respuestas para una pregunta similar sugerida: el comando rngd -r /dev/deviceId permite agregar una nueva fuente (a menudo un dispositivo de hardware) para alimentar el grupo de entropía.

Dado que la diferencia principal entre /dev/random y /dev/urandom es respectivamente su comportamiento de bloqueo o no bloqueo cuando las fuentes de entropía no son suficientes , ¿agregar un dispositivo a la agrupación de entropía con rngd hace /dev/random menos seguro si el nuevo dispositivo conectado tiene puertas traseras?

En otras palabras, rngd make /dev/random confía plenamente en el nuevo dispositivo conectado hasta el punto de no bloquearse para esperar suficiente entropía proveniente de otras fuentes (como actividad de red, mouse y teclado) y por lo tanto, ¿impide que su salida sea una mezcla de todas las fuentes de entropía disponibles en la computadora? Si es el caso, podría ser un problema cuando todas las demás fuentes de entropía no crearon suficiente entropía mientras que mi generador cuántico sí lo hizo (como lo es producir una salida aleatoria todo el tiempo) en el momento exacto en que mi programa llamado /dev/random para generar pares de claves, por ejemplo: un atacante que conoce los patrones de repetición del generador cuántico podría adivinar fácilmente los números "aleatorios" utilizados en ese momento desde la salida no era una mezcla de todas las fuentes de entropía disponibles en el sistema.