Inicjowanie puli entropii¶

Jądro zbiera bity entropii ze środowiska. Gdy zbierze odpowiednią ilość losowych bitów, pula entropii jest uważana za zainicjowaną.

Wybór źródła losowości¶

O ile nie generuje się długoterminowych kluczy (a zwykle nawet wówczas), prawdopodobnie nie ma potrzeby odczytywania z urządzenia /dev/random, ani korzystania z getrandom(2) ze znacznikiem GRND_RANDOM. W zamian powinno się odczytywać z urządzenia /dev/urandom lub korzystać z getrandom(2) bez znacznika GRND_RANDOM. Algorytmy kryptograficzne używane jako źródło urandom są dość konserwatywne, dlatego powinny być wystarczające do wszystkich zastosowań.

Wadą GRND_RANDOM i odczytywania z /dev/random jest fakt, że operacja ta może blokować na nieokreślony czas. Co więcej, radzenie sobie z częściowo zaspokojonymi żądaniami, co może zdarzyć się przy korzystaniu z GRND_RANDOM lub odczytywaniu z /dev/random, zwiększa złożoność kodu.

Monte Carlo i inne zastosowania próbkowania probabilistycznego¶

Korzystanie z tych interfejsów w celu dostarczania dużej ilości danych symulacjom Monte Carlo i innym programom/algorytmom wykonującym próbkowanie probabilistyczne będzie wolne. Ponadto jest niezasadne, ponieważ takie aplikacje nie wymagają liczb losowych kryptograficznie bezpiecznych. Zamiast tego, należy korzystać z opisanych w niniejszym podręczniku interfejsów do pozyskania niewielkiej ilości danych jako ziarna do generatora liczb pseudolosowych, znajdującego się w przestrzeni użytkownika, używanego przez aplikacje tego typu.

Porównanie pomiędzy getrandom, /dev/urandom i /dev/random¶

Poniższa tabela podsumowuje zachowanie różnych interfejsów, jakie mogą być stosowane do pozyskania losowości. GRND_NONBLOCK jest znacznikiem kontrolującym blokujące zachowanie getrandom(2). Ostatnia kolumna dotyczy przypadku, jaki może mieć miejsce we wczesnej fazie rozruchu, gdy pula entropii nie została jeszcze zainicjowana.

Generowanie kluczy kryptograficznych¶

Ilość ziarna, potrzebnego do wygenerowania klucza kryptograficznego równa się efektywnemu rozmiarowi klucza. Przykładowo, 3072-bitowy klucz prywatny RSA lub Diffiego-Hellmana ma efektywny rozmiar 128 bitów (wymaga około 2^128 operacji do złamania), zatem generator klucza potrzebuje jedynie 128 bitów (16 bajtów) ziarna z /dev/random.

Choć pewien margines bezpieczeństwa ponad to minimum jest rozsądny, jako zabezpieczenie wobec ułomności w algorytmie CSPRNG, żadna z dostępnych aktualnie funkcji pierwotnych nie może obiecać więcej niż 256 bitów bezpieczeństwa, zatem jeśli program odczytuje więcej niż 256 bitów (32 bajty) z puli losowości jądra na wywołanie albo na rozsądny interwał ponownego generowania ziarna (nie mniejszy niż minutę), należy to uznać za oznakę braku umiejętnej implementacji kryptograficznej.