random(7)

NAZWA
random - przegląd interfejsów do pozyskiwania losowości

OPIS
Generator liczb losowych jądra generuje ziarno dla kryptograficznie bezpiecznego generatora liczb pseudolosowych (ang. cryptographically secure pseudorandom number generator — CSPRNG), w oparciu o entropię zebraną ze sterowników urządzeń i innych źródeł szumu środowiskowego. Jest on zaprojektowany nie pod kątem szybkości, lecz bezpieczeństwa.

Dostęp do wyjścia z CSPRNG jądra dają następujące interfejsy:

•   Urządzenia /dev/urandom i /dev/random, opisane w podręczniku random(4). Urządzenia te istniały od wczesnego Linuksa i są dostępne również na wielu innych systemach.

•   Typowo linuksowe wywołanie systemowe getrandom(2), dostępne od Linuksa 3.17. To wywołanie systemowe zapewnia dostęp do tego samego źródła co /dev/urandom (dalej: „źródło urandom”) albo do tego samego źródła co /dev/random (dalej: „źródło random”). Domyślnym źródłem jest źródło urandom; źródło random jest wybierane podając do wywołania systemowego znacznik GRND_RANDOM (funkcja getentropy(3) zapewnia nieco bardziej przenośny interfejs zbudowany na getrandom(2)).

  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.
Interfejs | Pula | Zachowanie blokowania | Zachowanie, gdy pula nie jest jeszcze gotowa
/dev/random | Pula blokująca | Gdy zbyt mało entropii, blokuje do momentu wystąpienia wystarczającej entropii | Blokuje, do momentu zebrania wystarczającej entropii
/dev/urandom | Wyjście CSPRNG | Nigdy nie blokuje | Zwraca wyjście z niezainicjowanej CSPRNG (być może ze zbyt niską entropią, nieodpowiednią dla kryptografii)
getrandom() | Jak /dev/urandom | Nie blokuje po uzyskaniu gotowości puli | Blokuje, do momentu uzyskania gotowości puli
getrandom() GRND_RANDOM | Jak /dev/random | Gdy zbyt mało entropii, blokuje do momentu wystąpienia wystarczającej entropii | Blokuje, do momentu uzyskania gotowości puli
getrandom() GRND_NONBLOCK | Jak /dev/urandom | Nie blokuje po uzyskaniu gotowości puli | EAGAIN
getrandom() GRND_RANDOM + GRND_NONBLOCK | Jak /dev/random | EAGAIN gdy zbyt mało entropii | EAGAIN

  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.

ZOBACZ TAKŻE
getrandom(2), getauxval(3), getentropy(3), random(4), urandom(4), signal(7)

http://www.2uo.de/myths-about-urandom/

TŁUMACZENIE
Tłumaczenie niniejszej strony podręcznika: Michał Kułach <michal.kulach@gmail.com>

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 (https://www.gnu.org/licenses/gpl-3.0.html) lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-list@lists.sourceforge.net.