Jason A Donenfeld, autor al cărții VPN WireGuard a făcut-o cunoscută acum câteva zile o nouă implementare actualizat de la un generator de numere aleatoare RDRAND, care este responsabil pentru dispozitivele /dev/random și /dev/urandom din nucleul Linux.
La sfârșitul lunii noiembrie, Jason a fost listat ca întreținător ale controlerului aleatoriu și acum a postat primele rezultate ale lucrării sale de reluare.
Se menționează în anunț că noua implementare este remarcabilă trecerea la utilizarea funcției hash BLAKE2s în loc de SHA1 pentru operaţiile de amestecare a entropiei.
BLAKE2s în sine are proprietatea plăcută de a fi bazat intern pe
Permutația ChaCha, pe care RNG o folosește deja pentru extindere, deci
nu ar trebui să existe nicio problemă cu noutatea, originalitatea sau CPU uimitor
comportament, deoarece se bazează pe ceva care este deja în uz.
În plus, se remarcă faptul că schimbarea a îmbunătățit, de asemenea, securitatea generatorului de numere pseudoaleatoare scăpând de deranjantul algoritm SHA1 și evitând suprascrierea vectorului de inițializare RNG. Deoarece algoritmul BLAKE2s este înaintea lui SHA1 în performanță, utilizarea sa a avut, de asemenea, un efect pozitiv asupra performanței generatorului de numere pseudoaleatoare (testele pe un sistem cu procesor Intel i7-11850H au arătat o creștere cu 131% a vitezei). .
Un alt avantaj care iese în evidență este acela de a transfera amestecul de entropie la BLAKE2 este unificarea algoritmilor folosiți: BLAKE2 este folosit în cifrul ChaCha, care este deja folosit pentru a extrage secvențe aleatorii.
BLAKE2s este în general mai rapid și cu siguranță mai sigur, A fost într-adevăr foarte stricat. În plus, cel construcția curentă în RNG nu utilizează funcția SHA1 completă, așa cum specifică și vă permite să suprascrieți IV-ul cu ieșirea RDRAND într-un fel nedocumentat, chiar dacă RDRAND nu este configurat ca „de încredere”, care ceea ce înseamnă posibile opțiuni IV rău intenționate.
Și lungimea sa scurtă înseamnă pentru a păstra doar jumătate de secret atunci când se alimentează înapoi la mixer ne oferă doar 2 ^ 80 de biți de secret înainte. Cu alte cuvinte, nu numai alegerea funcției hash este depășită, dar nici utilizarea acesteia nu este chiar bună.
În plus, au fost aduse îmbunătățiri la generatorul de numere pseudoaleatoare CRNG cripto-securizat utilizat în apelul getrandom.
Se mai mentioneaza ca îmbunătățirile se rezumă la limitarea apelului către generatorul RDRAND lent la extragerea entropiei, care poate îmbunătăți performanța cu un factor de 3,7. Jason a demonstrat că apelul la RDRAND Are sens doar într-o situație în care CRNG-ul nu a fost încă inițializat complet, dar dacă inițializarea CRNG este completă, valoarea sa nu afectează calitatea fluxului generat și, în acest caz, este posibil să se facă acest lucru fără a apela RDRAND.
Acest compromis are ca scop rezolvarea acestor două probleme și, în același timp, menținerea structura generala si semantica cat mai apropiate de original.
Specific:a) În loc să suprascrieți hashul IV cu RDRAND, punem în BLAKE2 câmpurile „sare” și „personale” documentate, care sunt creat special pentru acest tip de utilizare.
b) Deoarece această funcție returnează rezultatul hashului complet la colector de entropie, returnăm doar jumătate din lungimea hash, exact cum se făcea înainte. Acest lucru mărește build advance secret from 2^80 to 2^128 mult mai confortabil.
c) În loc să utilizați doar funcția brută „sha1_transform”, în schimb folosim funcția completă și corespunzătoare BLAKE2s, cu completare.
Modificările sunt programate pentru a fi incluse în nucleul 5.17 și au fost deja revizuite de dezvoltatorii Ted Ts'o (al doilea întreținător al driverului aleatoriu), Greg Kroah-Hartman (responsabil pentru menținerea stabilă a nucleului Linux) și Jean-Philippe Aumasson (autorul algoritmilor BLAKE2 /3).
În fine, dacă sunteți interesat să puteți afla mai multe despre acesta, puteți consulta detaliile în următorul link.