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.
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.
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.
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.
/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.
/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.
BSD: Użyj/dev/urandom - z wyjątkiem tego, że /dev/urandomna OpenBSD nie ma czegoś takiego jak . OpenBSD ma /dev/arandom, ale nie powinieneś go używać, arc4random(3)zamiast tego powinieneś użyć tej funkcji. Być może porady dotyczące losowych urządzeń i funkcji należy pozostawić osobom, które faktycznie rozumieją, o co w tym wszystkim chodzi?
Satō Katsura,
1
@SatoKatsura Dobry połów. Zaktualizowano do FreeBSD, aby odzwierciedlić ofertę. Jak zaproponowałbyś ustalenie, kim są ci ludzie?
Tom Hale,
3
Kwalifikacje akademickie? Praca recenzowana?
Satō Katsura,
1
„ /dev/randomblokuje się, gdy zabraknie entropii” - w systemie Linux zależy to od sposobu otwarcia urządzenia. Jeśli openflagi zawierają, O_NONBLOCKto nie będzie blokować. Jeśli nie ma entropii, wywołanie natychmiast powróci i wskaże 0 odczytanych bajtów.
1
@TomHale Zachowanie jest mniej zaskakujące IMO. Jeśli /dev/randomjest tylko (np. :) 60 bajtów, ddotrzymasz plik 60 bajtów. Używanie headw tym samym scenariuszu prawdopodobnie będzie wyglądało na zawieszenie na zawsze. Nie robi też tego, co chcesz, ale przynajmniej dla mnie bardziej oczywiste headjest, że nie robi się tego, czego się spodziewano.
Ryan J,
5
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 .
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.
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.
Odpowiedzi:
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/urandomartykułu, który polecam do dalszej lektury.W podsumowaniu:
/dev/randomblokuje się, gdy skończy się entropia/dev/urandomnigdy się nie zablokuje, odczytywanie/dev/randommoże zatrzymać wykonywanie procesów./dev/urandommoże nie generować losowości wysokiej jakości./dev/urandomnie wyczerpuje puli entropii (używanej przez/dev/random), ale korzysta z danych wyjściowych CSPRNG z nadrzędnego./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 :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.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 podstawiegetrandom().System operacyjny Mac
Nie ma znaczenia, jak mówi Wikipedia :
FreeBSD
Nie ma znaczenia, jak mówi Wikipedia :
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 :
źródło
/dev/urandom- z wyjątkiem tego, że/dev/urandomna OpenBSD nie ma czegoś takiego jak . OpenBSD ma/dev/arandom, ale nie powinieneś go używać,arc4random(3)zamiast tego powinieneś użyć tej funkcji. Być może porady dotyczące losowych urządzeń i funkcji należy pozostawić osobom, które faktycznie rozumieją, o co w tym wszystkim chodzi?/dev/randomblokuje się, gdy zabraknie entropii” - w systemie Linux zależy to od sposobu otwarcia urządzenia. Jeśliopenflagi zawierają,O_NONBLOCKto nie będzie blokować. Jeśli nie ma entropii, wywołanie natychmiast powróci i wskaże 0 odczytanych bajtów./dev/randomjest tylko (np. :) 60 bajtów,ddotrzymasz plik 60 bajtów. Używanieheadw tym samym scenariuszu prawdopodobnie będzie wyglądało na zawieszenie na zawsze. Nie robi też tego, co chcesz, ale przynajmniej dla mnie bardziej oczywisteheadjest, że nie robi się tego, czego się spodziewano.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 entropiiadd_disk_randomness(),add_interrupt_randomness()orazadd_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 .źródło
Jest to poniekąd odpowiedź „ja też”, ale wzmacnia zalecenie Toma Hale'a. Dotyczy to tylko Linuksa.
/dev/urandom/dev/randomWedł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 :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 :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:
Kompromis osiągnięty później w wątku wynosił co najmniej jeden dmesg na moduł wywołujący.
źródło