Jason A. Donenfeld , autore di WireGuard VPN, ha recentemente annunciato una nuova implementazione aggiornata del generatore di numeri casuali RDRAND , responsabile del funzionamento dei dispositivi /dev/random e /dev/urandom nel kernel Linux.
A fine novembre Jason è stato inserito nell'elenco dei manutentori del random controller e ora ha pubblicato i primi risultati del suo lavoro di rielaborazione.
L'annuncio menziona che la nuova implementazione si distingue per il passaggio all'utilizzo della funzione hash BLAKE2s al posto di SHA1 per le operazioni di miscelazione dell'entropia.
BLAKE2s stesso ha la bella proprietà di essere internamente basato sul
Permutazione ChaCha, che l'RNG sta già utilizzando per l'espansione, quindi
non dovrebbero esserci problemi con la novità , l'originalità o la straordinaria CPU
comportamento in quanto si basa su qualcosa che è già in uso.
Inoltre, è opportuno sottolineare che la modifica ha anche migliorato la sicurezza del generatore di numeri pseudo-casuali, eliminando il problematico algoritmo SHA1 e impedendo la sovrascrittura del vettore di inizializzazione del generatore. Poiché l'algoritmo BLAKE2s offre prestazioni superiori rispetto a SHA1, il suo utilizzo ha avuto un effetto positivo anche sulle prestazioni del generatore di numeri pseudo-casuali (i test su un sistema con processore Intel i7-11850H hanno mostrato un aumento di velocità del 131%).
Un altro vantaggio evidenziato è che il trasferimento della miscela di entropia a BLAKE2 rappresenta l'unificazione degli algoritmi utilizzati: BLAKE2 è impiegato nel cifrario ChaCha, che a sua volta viene utilizzato per estrarre sequenze casuali.
BLAKE2s è generalmente più veloce e certamente più sicuro, ma è stato gravemente compromesso. Inoltre, l' attuale struttura del generatore di numeri casuali non utilizza la funzione SHA1 completa come specificato e consente la sovrascrittura non documentata del vettore di inizializzazione (IV) con l'output di RDRAND , anche se RDRAND non è configurato come "attendibile", il che implica opzioni di IV potenzialmente dannose.
E la sua breve lunghezza significa che mantenere segreta solo metà del dato quando lo si restituisce al mixer ci fornisce solo 2^80 bit di segretezza in avanti. In altre parole, non solo la scelta della funzione hash è obsoleta, ma anche il suo utilizzo non è ottimale.
Inoltre, sono stati apportati miglioramenti al generatore di numeri pseudocasuali CRNG criptato utilizzato nella chiamata getrandom.
Si menziona inoltre che i miglioramenti si riducono alla limitazione della chiamata al generatore RDRAND, che è lento, durante l'estrazione dell'entropia, il che può migliorare le prestazioni di un fattore 3,7. Jason ha dimostrato che la chiamata a RDRAND ha senso solo in una situazione in cui il CRNG non è ancora stato completamente inizializzato, ma se l'inizializzazione del CRNG è completa, il suo valore non influisce sulla qualità della sequenza generata e, in questo caso, è possibile farlo senza chiamare RDRAND.
Questo impegno mira a risolvere questi due problemi e, allo stesso tempo, a mantenere il struttura generale e semantica il più vicino possibile all'originale.
Nello specifico:a) Invece di sovrascrivere l'hash IV con RDRAND, lo farà inseriamo nei campi "sale" e "personale" documentati di BLAKE2, che sono creato appositamente per questo tipo di utilizzo.
b) Poiché questa funzione restituisce il risultato dell'hash completo a collettore di entropia, restituiamo solo metà della lunghezza del hash, proprio come è stato fatto prima. Questo aumenta il anticipo di costruzione segreto di 2^ 80 a 2^ 128 molto più comodo.
c) Invece di usare solo la funzione grezza "sha1_transform", invece utilizziamo la funzione BLAKE2s completa e appropriata, con completamento.
Le modifiche sono programmate per essere incluse nel kernel 5.17 e sono già state esaminate dagli sviluppatori Ted Ts'o (la seconda persona responsabile della manutenzione del driver per la generazione casuale), Greg Kroah-Hartman (responsabile del mantenimento della stabilità del kernel Linux) e Jean-Philippe Aumasson (autore degli algoritmi BLAKE2/3).
Infine, se siete interessati ad approfondire l'argomento, potete trovare maggiori dettagli al seguente link.