Jason A Donenfeld, forfatter av VPN WireGuard gjort det kjent for noen dager siden en ny implementering oppdatert fra en RDRAND tilfeldig tallgenerator, som er ansvarlig for driften av / dev / random og / dev / urandom enhetene i Linux-kjernen.
I slutten av november ble Jason oppført som en tilfeldig kontrollerende vedlikeholder og har nå lagt ut de første resultatene av omarbeidingsarbeidet hans.
Det er nevnt i kunngjøringen at den nye implementeringen skiller seg ut for bytte til å bruke BLAKE2s hash-funksjon i stedet for SHA1 for entropiblandingsoperasjoner.
BLAKE2s selv har den fine egenskapen å være internt basert på
ChaCha-permutasjon, som RNG allerede bruker for utvidelse, så
det skal ikke være noe problem med nyhet, originalitet eller fantastisk CPU
atferd ettersom den er basert på noe som allerede er i bruk.
I tillegg til dette fremheves det at endringen forbedret også sikkerheten til pseudo-tilfeldig tallgenerator ved å kvitte seg med den plagsomme SHA1-algoritmen og unngå å overskrive RNG-initialiseringsvektoren. Siden BLAKE2s-algoritmen er foran SHA1 i ytelse, hadde bruken også en positiv effekt på ytelsen til pseudo-tilfeldig tallgenerator (tester på et system med en Intel i7-11850H-prosessor viste en hastighetsøkning på 131 %).
En annen fordel som skiller seg ut er den å overføre entropiblandingen til BLAKE2 er foreningen av algoritmene som brukes: BLAKE2 brukes i ChaCha-krypteringen, som allerede brukes til å trekke ut tilfeldige sekvenser.
BLAKE2s er generelt raskere og sikkert sikrere, det har vært veldig ødelagt. Ved siden av Gjeldende bygg i RNG bruker ikke hele SHA1-funksjonen, som spesifiserer, og tillater å overskrive IV med RDRAND-utgangen så ikke dokumentert, selv om RDRAND ikke er satt som 'trusted', det som står for mulige ondsinnede IV-alternativer.
Og dens korte lengde betyr å holde bare en halv hemmelighet når du mater tilbake til mikseren gir oss bare 2 ^ 80 biter av hemmelighold fremover. Med andre ord, ikke bare valget av hash-funksjonen er utdatert, men bruken er heller ikke bra.
I tillegg er det gjort forbedringer av den kryptosikre CRNG pseudo-tilfeldige tallgeneratoren som brukes i det tilfeldige anropet.
Det er også nevnt at forbedringer er redusert til å begrense anropet til RDRAND-generatoren sakte når man trekker ut entropi, som Det kan forbedre ytelsen med en faktor på 3,7. Jason demonstrerte at samtalen til RDRAND Det gir bare mening i en situasjon der CRNG ennå ikke er fullstendig initialisert, men hvis CRNG-initialiseringen er fullført, påvirker ikke verdien kvaliteten på den genererte strømmen, og i dette tilfellet er det mulig å gjøre det uten å ringe RDRAND.
Denne forpliktelsen tar sikte på å løse disse to problemene og samtidig opprettholde generell struktur og semantikk så nær originalen som mulig.
Nærmere bestemt:a) I stedet for å overskrive hash IV med RDRAND, vil den gjøre det vi legger inn de BLAKE2 dokumenterte "salt" og "personlige" feltene, som er laget spesielt for denne typen bruk.
b) Siden denne funksjonen returnerer resultatet av hele hashen til entropisamler, returnerer vi bare halve lengden av hasj, akkurat som det ble gjort før. Dette øker byggeforskuddshemmelighet på 2 ^ 80 a 2 ^ 128 mye mer behagelig.
c) I stedet for bare å bruke den rå "sha1_transform"-funksjonen, i stedet bruker vi den fullstendige og passende BLAKE2s-funksjonen, med fullføring.
Endringer er planlagt for inkludering i kjerne 5.17 og har allerede blitt anmeldt av utviklerne Ted Ts'o (den andre ansvarlige for å vedlikeholde den tilfeldige kontrolleren), Greg Kroah-Hartman (ansvarlig for å holde Linux-kjernen stabil) og Jean-Philippe Aumasson (forfatter av BLAKE2-algoritmene /3).
Til slutt, hvis du er interessert i å kunne vite mer om det, kan du se detaljene i følgende lenke.