Barrapunto

La entropia de un sistema es la suma de las entropías entrantes (+ la entropía generada si el sistema es capaz de generar una propia). Si añades 0 muchas veces no obtienes menos, obtienes exactamente lo mismo (o sea, el estado n+1 del pool tiene la misma entropía que el estado en n).

Puedes tener este hecho en cuenta, si desconfias y piensas que la fuente proporciona entropía nula (o muy baja), la puedes eliminar del cómputo de bits de entropía disponibles, o sencillamente desconectar la fuente en tu sistema (otra opción, nadie te obliga a utilizarla, hay un parámetro del kernel para deshabilitarla, por lo que Linus no tiene por qué hacer nada tampoco).

En ningún caso puedes evitar que una aplicación lo use, es meramente una instrucción de la CPU y no es privilegiada que yo sepa, así que poco puede hacer el kernel (con lo cual Linus no puede hacer nada).

Lo bueno de esa instrucción es que permite generar números aleatorios rápidamente, y no todas las aplicaciones de números aleatorios son criptográficas.

No sé que tiene que ver el caudal de RDRAND, porque lo importante es como afecta a la entropía del pool, en el peor de los casos no añade nada, igual no he entendido tu comentario (o igualmente, necesitas repasar el concepto de entropía en teoría de información y como /dev/random funciona, hay un artículo en la wikipedia). El kernel genera los números de /dev/random a partir del pool, no da los valores que obtiene de las fuentes.

Saludos.

No exactamente. Cada una de las fuentes usadas en /dev/urandom puede aportar entropía a un ritmo distinto. En el caso de RDRAND hablamos de Gbps (gigabits por segundo). Otras pueden tener Mbps, Kbps o incluso sólo bps, pero eso sólo te marca el ritmo al que se recupera entropía al ir pidiendo números aleatorios: La clave es el ritmo al que se gasta esa entropía.

Por poner un ejemplo sencillo: Supongamos que RDRAND efectivamente está comprometido y se comporta como el generador aleatorio Dilbert [dilbert.com]. El resultado sería que RDRAND no aporta entropía (siempre es nueve), es decir, no suma. Eso no significa que debilite los números aleatorios de ningún modo; mientras el ritmo de petición no exceda la capacidad de regeneración de entropía de las otras fuentes no habrá problema.

El problema surge únicamente si estamos pidiendo números aleatorios a un ritmo tan alto que las demás fuentes de entropía son incapaces de mantener el ritmo, pero es que en ese caso da igual que incorpores RDRAND o no, porque los números aleatorios no son directamente el resultado de RDRAND sino la aplicación de la entropía acumulada a un generador de números pseudoaleatorios y mientras no tengas suficiente para reiniciar el generador con una nueva semilla, éste simplemente seguirá una secuencia. Es decir, en el peor de los casos tienes el resultado de un PRNG, hayamos usado o no RDRAND para generar la semilla de dicho PRNG, pero es que esa misma situación se daría si no usas RDRAND y pides números aleatorios a un ritmo mayor del que el sistema es capaz de generar entropía suficiente.

Sé que es un poco enrevesado, pero una vez que entiendes cómo funciona ves por qué no supone un problema.