Kiedy używać / dev / random vs / dev / urandom

Czy powinienem użyć /dev/randomlub /dev/urandom?

W jakich sytuacjach wolałbym jedną od drugiej?

TL; DR

Użyj /dev/urandomdo najbardziej praktycznych celów.

Dłuższa odpowiedź zależy od smaku Uniksa, z którego korzystasz.

Linux

Historycznie, /dev/randomi /dev/urandomoba zostały wprowadzone w tym samym czasie.

Jak zauważył @DavidSchwartz w komentarzu , użycie /dev/urandomjest preferowane w zdecydowanej większości przypadków. On i inni podali również link do doskonałych mitów na temat/dev/urandom artykułu, który polecam do dalszej lektury.

W podsumowaniu:

• Strona man wprowadza w błąd
• Oba są zasilane przez ten sam CSPRNG w celu generowania losowości ( diagramy 2 i 3 )
• /dev/random blokuje się, gdy skończy się entropia
• Ilość entropii jest ostrożnie szacowana, ale nie jest liczona
• /dev/urandomnigdy się nie zablokuje, odczytywanie /dev/randommoże zatrzymać wykonywanie procesów.
• W rzadkich przypadkach, bardzo krótko po rozruchu, CSPRNG może nie mieć wystarczającej entropii, aby zostać poprawnie zaszczepionym i /dev/urandommoże nie generować losowości wysokiej jakości.
• Niski poziom entropii nie stanowi problemu, jeśli CSPRNG został początkowo poprawnie zaszczepiony
• CSPRNG jest ciągle odnawiany
• W Linuksie 4.8 i nowszych /dev/urandomnie wyczerpuje puli entropii (używanej przez /dev/random), ale korzysta z danych wyjściowych CSPRNG z nadrzędnego.
• Użyj /dev/urandom.

Wyjątki od reguły

W Cryptography Stos Exchange Kiedy używać /dev/randomponad /dev/urandomw Linux @otus daje dwa przypadki użycia :

1. Krótko po uruchomieniu na urządzeniu o niskiej entropii, jeśli nie została jeszcze wygenerowana wystarczająca ilość entropii do prawidłowego uruchomienia /dev/urandom.

2. Generowanie jednorazowej podkładki z teoretycznym bezpieczeństwem informacji

Jeśli martwisz się (1), możesz sprawdzić entropię dostępną w/dev/random .

Jeśli robisz (2) to już wiesz :)

Uwaga: Możesz sprawdzić, czy odczyt z / dev / random zablokuje , ale uważaj na możliwe warunki wyścigu.

Alternatywnie: nie używaj ani!

@otus wskazał również, że getrandom()system będzie czytał /dev/urandomi blokował tylko wtedy, gdy początkowa entropia nasion jest niedostępna.

Występują problemy ze zmianą sposobu /dev/urandomużytkowaniagetrandom() , ale możliwe jest, że nowe /dev/xrandomurządzenie zostanie utworzone na podstawie getrandom().

System operacyjny Mac

Nie ma znaczenia, jak mówi Wikipedia :

macOS wykorzystuje 160-bitowy Yarrow oparty na SHA1. Nie ma różnicy między / dev / random i / dev / urandom; oba zachowują się identycznie. Apple iOS używa również Yarrow.

FreeBSD

Nie ma znaczenia, jak mówi Wikipedia :

/dev/urandomjest tylko linkiem do /dev/randombloków i tylko do prawidłowego zaszczepienia.

Oznacza to, że po uruchomieniu FreeBSD jest wystarczająco inteligentny, aby poczekać, aż zostanie zgromadzona wystarczająca entropia nasion, zanim dostarczy niekończący się strumień losowej dobroci.

NetBSD

Użyj /dev/urandom, zakładając, że twój system przynajmniej raz przeczytał, /dev/randomaby zapewnić prawidłowe początkowe inicjowanie.

Strona rnd (4) mówi :

/dev/urandom Nigdy nie blokuje.

/dev/randomCzasem bloki. Blokuje się wcześnie podczas rozruchu, jeśli wiadomo, że stan systemu jest przewidywalny.

Aplikacje powinny czytać z / dev / urandom, gdy potrzebują losowo generowanych danych, np. Kluczy kryptograficznych lub zarodków do symulacji.

Systemy powinny być tak zaprojektowane, aby przynajmniej rozsądnie czytały z / dev / random podczas rozruchu przed uruchomieniem jakichkolwiek usług komunikujących się z Internetem lub w inny sposób wymagających kryptografii, aby uniknąć przewidywalnego generowania kluczy.

Tradycyjnie jedyną różnicą pomiędzy /dev/urandomi /dev/randomjest to, co dzieje się, gdy jądro myśli, że w systemie /dev/randomnie ma entropii - zawodzi zamknięte, /dev/urandomzawodzi otwarte. Obaj kierowcy byli pozyskiwania od entropii add_disk_randomness(), add_interrupt_randomness()oraz add_input_randomness(). Sprawdź /drivers/char/random.cszczegóły.

Zmodyfikowano, aby dodać: Począwszy od Linuksa 4.8 /dev/urandomzostał przerobiony na CSPRNG.

Więc kiedy powinieneś zawieść zamknięty? Do wszelkiego rodzaju zastosowań kryptograficznych, w szczególności do rozsiewania DRBG. Istnieje bardzo dobry artykuł wyjaśniający konsekwencje używania /dev/urandompodczas generowania kluczy RSA i braku wystarczającej entropii. Przeczytaj Mining Your Ps and Qs .

Jest to poniekąd odpowiedź „ja też”, ale wzmacnia zalecenie Toma Hale'a. Dotyczy to tylko Linuksa.

• Posługiwać się /dev/urandom
• Nie używaj /dev/random

Według Theodore Ts'o na liście mailingowej Linux Kernel Crypto /dev/randomjest przestarzały od dekady. Z Re: [RFC PATCH v12 3/4] Linux Generator liczb losowych :

Praktycznie nikt nie używa / dev / random. Jest to zasadniczo przestarzały interfejs; głównymi interfejsami, które były zalecane od ponad dekady, jest / dev / urandom, a teraz getrandom (2).

Regularnie testujemy /dev/randomi napotyka on często awarie. Test wykonuje trzy kroki: (1) drenaż /dev/random, prosząc o 10 KB bajtów w trybie nieblokującym; (2) zażądaj 16 bajtów w trybie blokowania (3) spróbuj skompresować blok, aby sprawdzić, czy jest on losowy (test biedaka). Test trwa kilka minut.

Problem jest tak poważny w systemach Debain (i686, x86_64, ARM i MIPS), że poprosiliśmy GCC Compile Farm o zainstalowanie rng-toolspakietu dla ich maszyn testowych. Z Instaluj narzędzia rng na gcc67 i gcc68 :

Chciałbym poprosić o zainstalowanie narzędzi rng na gcc67 i gcc68. Są to systemy Debian i / dev / random cierpi na wyczerpanie entropii bez narzędzi rng podczas bibliotek testujących tortury, które korzystają z tego urządzenia.

BSD i OS X wydają się OK. Problemem jest zdecydowanie Linux.

Warto również wspomnieć, że Linux nie rejestruje awarii generatora. Nie chcieli, aby wpisy wypełniały dziennik systemu. Do tej pory większość awarii jest cicha i pozostaje niezauważona przez większość użytkowników.

Sytuacja powinna się wkrótce zmienić, ponieważ jądro wydrukuje co najmniej jeden komunikat o błędzie. Z [PATCH] losowo: wycisz ostrzeżenia kompilatora i napraw wyścig na liście kryptograficznej jądra:

W szczególności dodałem depends on DEBUG_KERNEL. Oznacza to, że te przydatne ostrzeżenia będą atakować tylko innych programistów jądra. To jest prawdopodobnie dokładnie to, czego chcemy. Jeśli różni powiązani programiści zobaczą ostrzeżenie pochodzące z ich konkretnego podsystemu, będą bardziej zmotywowani do jego naprawy. Zwykli użytkownicy w jądrach dystrybucji w ogóle nie powinni widzieć ostrzeżeń ani spamu, ponieważ zazwyczaj użytkownicy nie używają DEBUG_KERNEL.

Myślę, że złym pomysłem jest tłumienie wszystkich wiadomości z punktu widzenia inżynierii bezpieczeństwa.

Wielu ludzi nie uruchamia jądra debugowania. Większość użytkowników, którzy chcą lub muszą wiedzieć o problemie, nie zdają sobie sprawy z jego wystąpienia. Zastanów się, powodem, dla którego dowiedzieliśmy się o problemach systemd, był dmesg.

Pomijając wszystkie wiadomości dla wszystkich konfiguracji, rzucono szerszą sieć niż to konieczne. Konfiguracje, które potencjalnie mogą zostać wykryte i naprawione, prawdopodobnie pozostaną niezauważone. Jeśli problem nie zostanie ujawniony, nie zostanie rozwiązany.

Wydaje mi się, że jądro podejmuje decyzje polityczne dla niektórych organizacji. Dla tych, którzy mają sprzęt, którego nie da się naprawić, organizacja musi zdecydować, co zrobić na podstawie przeciwności ryzyka. Mogą zdecydować się na życie z ryzykiem lub mogą odświeżyć sprzęt. Jednak bez informacji na ten temat mogą nawet nie zdawać sobie sprawy, że mają przedmiot, który można wykonać.

Kompromis osiągnięty później w wątku wynosił co najmniej jeden dmesg na moduł wywołujący.