Veamos cómo podría funcionar tal cosa:
Un ejemplo clásico es el DRBG de doble EC , que emplea a un RNG con puerta trasera para crear un ataque general contra TLS. La otra mitad de este ataque más allá del RNG vulnerable es un mecanismo para revelar al atacante el estado del RNG en el momento de su uso para permitir al atacante predecir el contenido "aleatorio" restante según lo producido por el RNG de la víctima.
Entonces, hay una función no estándar implementada en TLS llamada Random Extendido , a través del cual un servidor TLS simplemente descarga un montón de salida de su RNG en la negociación TLS, que se revela a cualquiera que esté escuchando la conversación. De hecho, se ha calculado que esta característica mejora el ataque de Dual EC en un factor de 64000X.
Por lo tanto, un sistema que use un RNG diferente para el componente "Random extendido" que para la obtención de claves estaría significativamente protegido (64000x) contra este ataque.
Pero no completamente inmune. El RNG es vulnerable en sí mismo, incluso si mantiene su aleatoriedad de "alto valor" por separado. Una segunda instancia de RNG es útil, pero no infalible.
El objetivo de este sistema es proteger contra lo desconocido, por lo que medir su utilidad es, en el mejor de los casos, difícil. Y otras protecciones pueden funcionar mejor.
Por ejemplo, los valores aleatorios XORed con cualquier cosa aún son aleatorios. Entonces, si su aplicación ejecuta múltiples RNG y XOR su salida, entonces la calidad de la aleatoriedad que obtiene es igual a la calidad más alta de todos los RNG de entrada. Entonces, si una aplicación XOR es una lista completa de RNG de calidad variable, entonces si alguno de los RNG es seguro, la salida también será segura.
Entonces, ¿qué tan buena sería esta técnica para protegerse contra amenazas desconocidas? No lo sabemos Pero lo que podemos decir es que protegería contra amenazas conocidas como la puerta trasera Dual EC mencionada anteriormente.