Jasona A. Donenfelda, autor VPN WireGuard dał mi znać kilka dni temu nowa realizacja zaktualizowany z generatora liczb losowych RDRAND, który jest odpowiedzialny za urządzenia /dev/random i /dev/urandom w jądrze Linux.
Pod koniec listopada Jason został wymieniony jako opiekun kontrolera losowego, a teraz opublikował pierwsze wyniki swojej przeróbki.
W ogłoszeniu wspomniano, że nowa realizacja wyróżnia się przełączenie na używanie funkcji skrótu BLAKE2s zamiast SHA1 do operacji mieszania entropii.
Sam BLAKE2 ma tę przyjemną właściwość, że jest wewnętrznie oparty na
Permutacja ChaCha, której RNG już używa do ekspansji, więc
nie powinno być problemu z nowością, oryginalnością czy niesamowitym procesorem
zachowanie, ponieważ opiera się na czymś, co jest już w użyciu.
Oprócz tego podkreślono, że zmiana poprawiono również bezpieczeństwo generatora liczb pseudolosowych pozbywając się kłopotliwego algorytmu SHA1 i unikając nadpisywania wektora inicjującego RNG. Ponieważ algorytm BLAKE2s wyprzedza pod względem wydajności SHA1, jego użycie miało również pozytywny wpływ na wydajność generatora liczb pseudolosowych (testy na systemie z procesorem Intel i7-11850H wykazały 131% wzrost prędkości ).
Kolejną wyróżniającą się zaletą jest przeniesienie mieszaniny entropii do BLAKE2 to ujednolicenie stosowanych algorytmów: BLAKE2 jest używany w szyfrowaniu ChaCha, które jest już używane do wyodrębniania losowych sekwencji.
BLAKE2s jest generalnie szybszy i na pewno bezpieczniejszy, to było naprawdę bardzo zepsute. Poza tym Obecna kompilacja w RNG nie wykorzystuje pełnej funkcji SHA1, ponieważ określa i pozwala nadpisać IV wyjściem RDRAND, więc nieudokumentowane, nawet jeśli RDRAND nie jest ustawiony jako „zaufany”, to co oznacza możliwe złośliwe opcje IV.
A jego krótka długość oznacza zachować tylko pół tajemnicy podczas podawania z powrotem do miksera daje nam tylko 2 ^ 80 bitów utajnienia przekazywania. Innymi słowy nie tylko wybór funkcji skrótu jest przestarzały, ale jej użycie też nie jest dobre.
Ponadto wprowadzono ulepszenia do bezpiecznego w kryptografii generatora liczb pseudolosowych CRNG używanego w wywołaniu getrandom.
Wspomniano również, że usprawnienia sprowadzają się do ograniczenia połączenia do generatora RDRAND powolne podczas ekstrakcji entropii, co może poprawić wydajność o współczynnik 3,7. Jason zademonstrował, że wezwanie do RDRAND Ma to sens tylko w sytuacji, gdy CRNG nie został jeszcze w pełni zainicjalizowany, ale jeśli inicjalizacja CRNG jest zakończona, jego wartość nie wpływa na jakość generowanego strumienia i w takim przypadku można to zrobić bez wywoływania RDRAND.
To zobowiązanie ma na celu rozwiązanie tych dwóch problemów, a jednocześnie utrzymanie ogólna struktura i semantyka jak najbardziej zbliżona do oryginału.
Konkretnie:a) Zamiast nadpisywać hash IV przez RDRAND, umieszczamy w BLAKE2 udokumentowane pola „solne” i „osobiste”, które są stworzony specjalnie do tego typu zastosowań.
b) Ponieważ ta funkcja zwraca wynik pełnego hasha do kolektor entropii, zwracamy tylko połowę długości hasz, tak jak wcześniej. Zwiększa to tajemnica zaliczki budowlanej 2 ^ 80 a 2^128 znacznie wygodniejsze.
c) Zamiast używać tylko surowej funkcji „sha1_transform”, zamiast tego używamy pełnej i odpowiedniej funkcji BLAKE2s, z uzupełnieniem.
Zmiany są zaplanowane do włączenia do jądra 5.17 i zostały już sprawdzone przez programistów Ted Ts'o (drugiego opiekuna losowego sterownika), Grega Kroah-Hartmana (odpowiedzialnego za utrzymywanie stabilności jądra Linuksa) i Jean-Philippe'a Aumassona (autora algorytmów BLAKE2/3).
Wreszcie, jeśli chcesz dowiedzieć się więcej na ten temat, możesz zapoznać się ze szczegółami w następujący link.