Jason A. Donenfeld , autor de VPN WireGuard va donar a conèixer fa pocs dies una nova implementació actualitzada d'un generador de números aleatoris RDRAND , la qual és responsable del funcionament dels dispositius /dev/random i /dev/urandom al nucli de Linux.
A finals de novembre, Jason va ser inclòs a la llista de mantenidors del controlador aleatori i ara ha publicat els primers resultats del seu treball de reelaboració.
A l'anunci s'esmenta que la nova implementació es destaca pel canvi a l'ús de la funció hash BLAKE2s en lloc de SHA1 per a operacions de barreja d'entropia.
BLAKE2s en si mateix té l'agradable propietat d'estar basat internament en el
permutació ChaCha, que el RNG ja està usant per a l'expansió, de manera que
no hi hauria d'haver cap problema amb la novetat, l'originalitat o la CPU sorprenent
comportament, ja que es basa en una cosa que ja està en ús.
A més d'això es destaca que el canvi també va millorar la seguretat del generador de números pseudoaleatoris en desfer-se del problemàtic algorisme SHA1 i evitar sobreescriure el vector d'inicialització RNG. Atès que l'algorisme BLAKE2s està per davant de SHA1 en rendiment, el seu ús també va tenir un efecte positiu en el rendiment del generador de números pseudoaleatoris (les proves en un sistema amb un processador Intel i7-11850H van mostrar un augment del 131% a la velocitat).
Un altre dels avantatges que es destaca és transferir la barreja d'entropia a BLAKE2 és la unificació dels algorismes utilitzats: BLAKE2 s'usa en el xifrat ChaCha, que ja s'usa per extreure seqüències aleatòries.
Blake2s és generalment més ràpid i certament més segur, ha estat realment molt trencat. A més, la construcció actual a l'RNG no utilitza la funció SHA1 completa, com s'especifica , i permet sobreescriure l'IV amb la sortida RDRAND de manera no documentada, fins i tot en el cas que RDRAND no estigui configurat com a «de confiança», cosa que significa possibles opcions IV malicioses.
I la seva curta longitud vol dir que mantenir només la meitat en secret quan es retroalimenta al mesclador ens dóna només 2^80 bits de secret cap endavant. En altres paraules, no només l'elecció de la funció hash està antiquada, sinó que el seu ús tampoc no és realment bo.
A més, s'han realitzat millores al generador de números pseudoaleatoris CRNG criptosegur que s'utilitza en l'anomenada getrandom.
També s'esmenten que les millores es redueixen a limitar la crida al generador RDRAND lent en extreure entropia, cosa que pot millorar el rendiment en un factor de 3,7. Jason va demostrar que la crida a RDRAND només té sentit en una situació en què CRNG encara no s'ha inicialitzat del tot, però si la inicialització de CRNG està completa, el seu valor no afecta la qualitat de la seqüència generada i en aquest cas, és possible fer-ho sense trucar a RDRAND.
Aquest compromís té com a objectiu solucionar aquests dos problemes i, alhora, mantenir la estructura general i la semàntica el més a prop possible de l'original.
específicament:a) En lloc de sobreescriure el hash IV amb RDRAND, el col·loquem als camps «salt» i «personal» documentats de BLAKE2, que es van crear específicament per a aquest tipus dús.
b) Atès que aquesta funció torna el resultat del hash complet al col·lector d'entropia, només tornem la meitat de la longitud del hash, tal com es va fer abans. Això augmenta el secret d'avenç de la construcció de 2 ^ 80 a 2 ^ 128 molt més còmode.
c) En lloc de fer servir només la funció «sha1_transform» sense format, al seu lloc fem servir la funció BLAKE2s completa i adequada, amb finalització.
Els canvis estan programats per a la seva inclusió al nucli 5.17 i ja han estat revisats pels desenvolupadors Ted Ts'o (el segon responsable del manteniment del controlador aleatori), Greg Kroah-Hartman (responsable de mantenir estable el nucli de Linux) i Jean-Philippe Aumasson (autor dels algorismes BLA).
Finalment si estàs interessat a poder conèixer més sobre això, pots consultar els detalls al següent enllaç.