Jason A. Donenfeld, autor de VPN WireGuard dio a conocer hace pocos dias una nueva implementación actualizada de un generador de números aleatorios RDRAND, la cual es responsable del funcionamiento de los dispositivos /dev/random y /dev/urandom en el kernel de Linux.
A finales de noviembre, Jason fue incluido en la lista de mantenedores del controlador aleatorio y ahora ha publicado los primeros resultados de su trabajo de reelaboración.
Se menciona en el anuncio que la nueva implementación se destaca por el cambio al uso de la función hash BLAKE2s en lugar de SHA1 para operaciones de mezcla de entropía.
BLAKE2s en sí mismo tiene la agradable propiedad de estar basado internamente en el
permutación ChaCha, que el RNG ya está usando para la expansión, por lo que
no debería haber ningún problema con la novedad, la originalidad o la CPU sorprendente
comportamiento, ya que se basa en algo que ya está en uso.
Ademas de ello se destaca que el cambio tambien mejoró la seguridad del generador de números pseudoaleatorios al deshacerse del problemático algoritmo SHA1 y evitar sobrescribir el vector de inicialización RNG. Dado que el algoritmo BLAKE2s está por delante de SHA1 en rendimiento, su uso también tuvo un efecto positivo en el rendimiento del generador de números pseudoaleatorios (las pruebas en un sistema con un procesador Intel i7-11850H mostraron un aumento del 131 % en la velocidad).
Otra de las ventajas que se destaca es la de transferir la mezcla de entropía a BLAKE2 es la unificación de los algoritmos utilizados: BLAKE2 se usa en el cifrado ChaCha, que ya se usa para extraer secuencias aleatorias.
BLAKE2s es generalmente más rápido y ciertamente más seguro, ha estado realmente muy roto. Además, la construcción actual en el RNG no utiliza la función SHA1 completa, como se especifica, y permite sobrescribir el IV con la salida RDRAND de forma no documentada, incluso en el caso de que RDRAND no esté configurado como «de confianza», lo que significa posibles opciones IV maliciosas.
Y su corta longitud significa que mantener solo la mitad en secreto cuando se retroalimenta al mezclador nos da solo 2^80 bits de secreto hacia adelante. En otras palabras, no solo la elección de la función hash está anticuada, sino que su uso tampoco es realmente bueno.
Además, se han realizado mejoras en el generador de números pseudoaleatorios CRNG criptoseguro que se utiliza en la llamada getrandom.
Tambien se mencionan que las mejoras se reducen a limitar la llamada al generador RDRAND lento al extraer entropía, lo que puede mejorar el rendimiento en un factor de 3,7. Jason demostró que la llamada a RDRAND solo tiene sentido en una situación en la que CRNG aún no se ha inicializado por completo, pero si la inicialización de CRNG está completa, su valor no afecta la calidad de la secuencia generada y en este caso, es posible hacerlo sin llamar a RDRAND.
Este compromiso tiene como objetivo solucionar estos dos problemas y, al mismo tiempo, mantener la estructura general y la semántica lo más cerca posible del original.
Específicamente:a) En lugar de sobrescribir el hash IV con RDRAND, lo colocamos en los campos «salt» y «personal» documentados de BLAKE2, que se crearon específicamente para este tipo de uso.
b) Dado que esta función devuelve el resultado del hash completo al colector de entropía, solo devolvemos la mitad de la longitud del hash, tal como se hizo antes. Esto aumenta el secreto de avance de la construcción de 2 ^ 80 a 2 ^ 128 mucho más cómodo.
c) En lugar de usar solo la función «sha1_transform» sin formato, en su lugar usamos la función BLAKE2s completa y adecuada, con finalización.
Los cambios están programados para su inclusión en el kernel 5.17 y ya han sido revisados por los desarrolladores Ted Ts’o (el segundo responsable del mantenimiento del controlador aleatorio), Greg Kroah-Hartman (responsable de mantener estable el kernel de Linux) y Jean-Philippe Aumasson (autor de los algoritmos BLAKE2/3).
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.