Barrapunto

No es eso a lo que me estoy refiriendo. El quid de la cuestión es la diferencia de caudal en la entropía que producen las diferentes fuentes disponibles y a que la de RdRand es órdenes de magnitud superior a todas las otras.

Imagina que Mr.Snowden quiere cifrar todos los documentos que consiguió de la NSA y por seguridad y porque ya no se fía ni de su sombra prefiere no usar RSA ni AES ni leches sino OTP [wikipedia.org] ya que puede usar muy fácilmente el estupendo RdRand para hacerlo.

Para ello digamos que necesita generar 400 Gbits de números aleatorios con los que hacer XOR a sus datos.

Supongamos que RdRand es seguro:

- RdRand genera entropía a una velocidad órdenes de magnitud superior a todas las otras fuentes disponibles.
- Usando RdRand vía /dev/random esto le puede llevar unos minutos.
- Usando sólo otras fuentes vía /dev/random esto le puede llevar toda la vida.
- Igualmente usando /dev/urandom con RdRand o no, también le lleva unos minutos porque no se bloquea al quedarse sin entropía.
- No quiere usar /dev/urandom porque si se le acaba la entropía no es más que un PRNG y porque para eso usa cualquier otro stream cipher y acaba antes.
- Usando RdRand, las demás fuentes de entropía generan bits a una tasa insignificante.
- Prácticamente toda la entropía del sistema proporcionada a /dev/random procede de la generada por RdRand, y sólo mínimamente de las otras fuentes.
- Conforme se van leyendo bits de /dev/random gracias a que RdRand puede proporcionar entropía a gran velocidad, no como el resto de fuentes disponibles, digamos que por cada 100 Mbit proporcionados por RdRand hay 1 bit de entropía disponible de otras fuentes.
- En principio no es problema porque como se supone que RdRand es seguro y se mezcla con el resto de fuentes, toda la entropía generada va a parar a los datos que proporciona /dev/random.

Ahora supongamos que RdRand NO es seguro:

- Necesita generar los mismos 400 Gbits de números aleatorios para el OTP.
- Usa RdRand vía /dev/random y le lleva los mismo minutos.
- Como está usando RdRand y resulta que es inseguro, en realidad la entropía que aporta es 0.
- Igual que antes, las demás fuentes de entropía generan bits a una tasa insignificante.
- En realidad toda la entropía del sistema proporcionada a /dev/random procede de las otras fuentes.
- Como el sistema está usando RdRand el núcleo actualiza el contador de entropía con la que se supone que debería obtener de RdRand y las demás fuentes.
- La entropía aparentemente disponible es órdenes de magnitud superior a la real y parece que hay entropía de sobra, por lo que /dev/random no se bloquea y proporciona números alegremente.
- El sistema lee los datos para el OTP de /dev/random en unos pocos minutos, que se suponen eran 400 Gbits pero en realidad la única entropía que contienen es la que en esos pocos minutos el sistema ha obtenido de las otras fuentes ya que la de RdRand era 0.

Voilá. Tienes un OTP de 400 Gbit con digamos 4 Kbit de entropía. Similar a como si hubieses usado /dev/urandom sin RdRand.

Si el ejemplo de los papeles de la NSA te parece muy específico. Imagina que tienes que generar de una sentada 5000 claves públicas para tu empresa/gobierno. O vas a generar 40 millones de certificados para tus ciudadanos.

Usando sólo otras fuentes vía /dev/random esto le puede llevar toda la vida.

Pues si usa /dev/random le llevará toda la vida.

/dev/random usa además de RDRAND otras fuentes de entropía, será tan rápido como la más lenta de las fuentes de entropía.

Si necesita 100 Gbits

1. /dev/random bloqueará el proceso
2. Pedirá 100 Gbits a RDRAND, que se los dará en un momento
3. Pedirá 100 Gbits a otras fuentes, que tardarán lo que tarden
4. Hará un XOR
5. Se los devolverá al proceso desbloquéandolo.