Jason A Donenfeld, författare till VPN WireGuard gjorde det känt för några dagar sedan en ny implementering uppdaterad från en slumptalsgenerator RDRAND, som är ansvarig för enheterna /dev/random och /dev/urandom i Linux-kärnan.
I slutet av november listades Jason som slumpmässig kontrollanthållare och har nu publicerat de första resultaten av sitt omarbetningsarbete.
Det nämns i tillkännagivandet att den nya implementeringen är känd för växla till att använda BLAKE2s hashfunktion istället för SHA1 för entropiblandningsoperationer.
BLAKE2s själv har den fina egenskapen att vara baserad internt på
ChaCha-permutation, som RNG redan använder för expansionen, så
det borde inte vara några problem med nyhet, originalitet eller fantastisk CPU
beteende, eftersom det är baserat på något som redan används.
Därutöver noteras att ändringen förbättrade också säkerheten för pseudoslumptalsgeneratorn genom att bli av med den besvärliga SHA1-algoritmen och undvika att skriva över RNG-initieringsvektorn. Eftersom BLAKE2s-algoritmen ligger före SHA1 i prestanda, hade dess användning också en positiv effekt på prestandan hos pseudo-slumptalsgeneratorn (tester på ett system med en Intel i7-11850H-processor visade en hastighetsökning på 131 %). .
En annan fördel som sticker ut är att överföra entropiblandningen till BLAKE2 är föreningen av algoritmerna som används: BLAKE2 används i ChaCha-chifferet, som redan används för att extrahera slumpmässiga sekvenser.
BLAKE2s är generellt sett snabbare och säkert säkrare, Det har verkligen varit väldigt trasigt. Förutom nuvarande build i RNG använder inte hela SHA1-funktionen, som specificerar och låter dig skriva över IV med RDRAND-utgången på ett sätt odokumenterad, även om RDRAND inte är konfigurerad som "trusted", vilket vilket innebär möjliga skadliga IV-alternativ.
Och dess korta längd betyder att bara hålla en halv hemlighet när man matar tillbaka till mixern det ger oss bara 2^80 bitar av framåtriktat sekretess. Med andra ord, inte bara valet av hash-funktionen är föråldrat, men dess användning är inte heller riktigt bra.
Dessutom har förbättringar gjorts av den kryptosäkra CRNG pseudo-slumptalsgeneratorn som används i det slumpmässiga samtalet.
Det nämns också att förbättringar går ut på att begränsa anropet till RDRAND-generatorn långsam i att extrahera entropi, vilket kan förbättra prestandan med en faktor 3,7. Jason visade att samtalet till RDRAND Det är bara vettigt i en situation där CRNG inte har initierats helt ännu, men om CRNG-initieringen är klar påverkar dess värde inte kvaliteten på den genererade strömmen, och i det här fallet är det möjligt att göra det utan att anropa RDRAND.
Denna kompromiss syftar till att lösa dessa två problem och samtidigt upprätthålla generell struktur och semantik så nära originalet som möjligt.
Specifikt:a) Istället för att skriva över IV-hash med RDRAND, vi lägger i de dokumenterade BLAKE2 "salt" och "personliga" fälten, som är skapad speciellt för denna typ av användning.
b) Eftersom denna funktion returnerar resultatet av hela hashen till entropisamlare returnerar vi bara halva längden av hash, precis som det gjordes tidigare. Detta ökar bygga förskottshemlighet från 2^80 till 2^128 mycket bekvämare.
c) Istället för att bara använda den råa "sha1_transform"-funktionen, istället använder vi den fullständiga och korrekta BLAKE2s-funktionen, med komplettering.
Ändringar är schemalagda för inkludering i kärnan 5.17 och har redan granskats av utvecklarna Ted Ts'o (slumpmässiga förarens andra underhållare), Greg Kroah-Hartman (ansvarig för att hålla Linux-kärnan stabil) och Jean-Philippe Aumasson (författare till BLAKE2-algoritmerna /3).
Slutligen, om du är intresserad av att kunna veta mer om det, kan du konsultera detaljerna i följande länk.