Jason A Donenfeld, forfatter til VPN WireGuard gjort det kendt for et par dage siden en ny implementering opdateret fra en RDRAND tilfældig talgenerator, som er ansvarlig for driften af ​​/ dev / random og / dev / urandom-enhederne i Linux-kernen.
I slutningen af ​​november blev Jason inkluderet på listen over vedligeholdere af den tilfældige controller og har nu offentliggjort de første resultater af sit omarbejdningsarbejde.
Det nævnes i meddelelsen, at den nye implementering skiller sig ud for skifte til at bruge BLAKE2s hash-funktion i stedet for SHA1 til entropiblandingsoperationer.
BLAKE2s selv har den pæne egenskab at være internt baseret på
ChaCha-permutation, som RNG'en allerede bruger til udvidelse, så
der burde ikke være noget problem med nyhed, originalitet eller fantastisk CPU
adfærd, da den er baseret på noget, der allerede er i brug.
Udover dette fremhæves det, at ændringen forbedrede også sikkerheden for pseudo-tilfældige tal-generatoren ved at slippe af med den besværlige SHA1-algoritme og undgå at overskrive RNG-initialiseringsvektoren. Da BLAKE2s-algoritmen er foran SHA1 i ydeevne, havde dens brug også en positiv effekt på ydeevnen af ​​pseudo-tilfældige talgeneratoren (test på et system med en Intel i7-11850H-processor viste en stigning på 131 % i hastigheden).
En anden fordel, der skiller sig ud, er at overføre entropiblandingen til BLAKE2 er ensretningen af ​​de anvendte algoritmer: BLAKE2 bruges i ChaCha-krypteringen, som allerede bruges til at udtrække tilfældige sekvenser.
BLAKE2s er generelt hurtigere og helt sikkert mere sikker, det har været virkelig meget ødelagt. Udover det Nuværende build i RNG'en bruger ikke den fulde SHA1-funktion, som specificerer og tillader at overskrive IV'en med RDRAND-output så ikke dokumenteret, selvom RDRAND ikke er sat som 'trusted', er det som står for mulige ondsindede IV-muligheder.
Og dens korte længde betyder for kun at holde en halv hemmelighed, når man føder tilbage til mixeren giver os kun 2 ^ 80 bits fremadrettet hemmeligholdelse. Med andre ord ikke kun valget af hash-funktionen er forældet, men brugen er heller ikke rigtig god.
Derudover er der foretaget forbedringer af den krypto-sikre CRNG pseudo-tilfældige nummergenerator, der bruges i det tilfældige opkald.
Det nævnes også forbedringer er reduceret til at begrænse opkaldet til RDRAND-generatoren langsom, når man udvinder entropi, hvilket Det kan forbedre ydeevnen med en faktor på 3,7. Jason demonstrerede, at opkaldet til RDRAND Det giver kun mening i en situation, hvor CRNG endnu ikke er fuldt initialiseret, men hvis CRNG-initialiseringen er fuldført, påvirker dens værdi ikke kvaliteten af ​​den genererede strøm, og i dette tilfælde er det muligt at gøre det uden at kalde RDRAND.
Denne forpligtelse har til formål at løse disse to problemer og samtidig opretholde generel struktur og semantik så tæt som muligt på originalen.
Specifikt:a) I stedet for at overskrive hash IV med RDRAND, vil det vi indsætter de BLAKE2 dokumenterede "salt" og "personlige" felter, som er skabt specielt til denne type brug.
b) Da denne funktion returnerer resultatet af den komplette hash til entropisamler, returnerer vi kun halvdelen af ​​længden af hash, ligesom det blev gjort før. Dette øger byggeforskudshemmelighed på 2 ^ 80 a 2 ^ 128 meget mere behagelig.
c) I stedet for blot at bruge den rå "sha1_transform"-funktion, i stedet bruger vi den fulde og passende BLAKE2s funktion, med fuldførelse.
Ændringer er planlagt til at blive inkluderet i kerne 5.17 og er allerede blevet gennemgået af udviklerne Ted Ts'o (den anden ansvarlig for at vedligeholde den tilfældige controller), Greg Kroah-Hartman (ansvarlig for at holde Linux-kernen stabil) og Jean-Philippe Aumasson (forfatter af BLAKE2-algoritmerne /3).
Endelig, hvis du er interesseret i at kunne vide mere om det, kan du konsultere detaljerne i følgende link.