EXACTO. Si tienes varias fuentes de números aleatorios y las mezclas con un tipo de operación matemática adecuada, que entre otras cosas "no sobreescriba" el estado previo (la más simple es XOR), todas contribuyen a la entropía del estado.
Si una es predecible, sencillamente no contribuye a la entropía, pero los futuros estados no son predecible porque hay entropía procedente de otras fuentes, la entropía total es más pequeña, hay un término que añaqde 0, pero no inexistente.
Para que RDRAND haga "inútil" la entropía del "almacén" de entropía que alimenta/dev/random tendia que pasar cosas como:
-- la aplicación ignora/dev/random y genera sus propios números, posiblememnte alguien te ha metido una librería no segura que utiliza RDRAND en vez de/dev/random. ahí los tíos del kernel tienen poco que hacer.
-- RDRAND es tan inteligente que es capaz de adivinar los pasos que viene a continuación y compensar la aleatoriedad de las fuentes que se mezclan con sus resultados. Esto implica compensar tanto una serie arbitraria de instrucciones como las contribuciones de por ejemplo el tiempo del último seek en el disco duro, o el tiempo entre tus pulsaciones en el teclado, movimientos del ratón o micrófono.
Así, aunque se sepa que RDRAND da un número predecible, puede servir para "batir" el almacén de entropía. La entropía disponible no se aumenta, pero la aleatoriedad aparente de los números dados por/dev/random se mejora o queda igual (imagínate que el resultado de RDRAND es simepre cero y con esto se hace un XOR con lo que dan las otras fuentes).
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.
Re:Problema con RdRand
(Puntos:3, Interesante)( http://kernel.org/ | Última bitácora: Viernes, 31 Julio de 2015, 11:54h )
Si una es predecible, sencillamente no contribuye a la entropía, pero los futuros estados no son predecible porque hay entropía procedente de otras fuentes, la entropía total es más pequeña, hay un término que añaqde 0, pero no inexistente.
Para que RDRAND haga "inútil" la entropía del "almacén" de entropía que alimenta
-- la aplicación ignora
-- RDRAND es tan inteligente que es capaz de adivinar los pasos que viene a continuación y compensar la aleatoriedad de las fuentes que se mezclan con sus resultados. Esto implica compensar tanto una serie arbitraria de instrucciones como las contribuciones de por ejemplo el tiempo del último seek en el disco duro, o el tiempo entre tus pulsaciones en el teclado, movimientos del ratón o micrófono.
Así, aunque se sepa que RDRAND da un número predecible, puede servir para "batir" el almacén de entropía. La entropía disponible no se aumenta, pero la aleatoriedad aparente de los números dados por
Saludos.
1 + 2 + 3 + 4 + 5 + 6 + 7 +... = -1/12
Re:Linus Torvalds no es un experto en criptograf
(Puntos:2)( http://kernel.org/ | Última bitácora: Viernes, 31 Julio de 2015, 11:54h )
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
Saludos.
1 + 2 + 3 + 4 + 5 + 6 + 7 +... = -1/12