Czy łączenie / dev / random z / dev / urandom w Linuksie jest błędem?

13

Obecnie testuję gpg --genkeyna maszynie wirtualnej z systemem Linux. Niestety, to oprogramowanie wydaje się polegać na /dev/randomgromadzeniu entropii i uprzejmie prosi użytkownika o ręczne wpisywanie ekranów po ekranach kryptograficznie losowych danych wejściowych, więc może ostatecznie skończyć się generowaniem klucza, i nie znalazłem parametru wiersza polecenia aby użyć innego pliku jako źródła entropii (facet w tym filmie napotyka ten sam problem ...).

Jednak użytkownik powinien mieć swobodę wyboru użycia, /dev/urandomponieważ nie ma w tym nic złego . Jest to głównie wspomnienie starszych algorytmów PRNG, które były słabsze z kryptograficznego punktu widzenia. Na przykład, chociaż strona NetBSD przyznaje, że to rozróżnienie może być nadal przydatne na bardzo wczesnym etapie uruchamiania, opisuje takie rozróżnienie jako „folklor” i „wyimaginowaną teorię, która broni tylko przed modelami zagrożeń fantasy” . Nikt nie zgadza się ani z ilością entropii wymaganą przez to polecenie, ani z faktem, że entropia jest faktycznie konsumowana, jak podano na stronie GPG („PROSZĘ, nie używaj tego polecenia, chyba że wiesz, co robisz, może to usunąć cenną entropię z systemu!” ).

Czytałem o ludziach instalujących rngddemona i skonfigurowałem go tak, aby używał /dev/urandomźródła entropii do zasilania /dev/random, ale uważam, że taka praktyka jest bardzo brudna.

Próbowałem obejść ten problem w sposób FreeBSD, usuwając /dev/randomi łącząc go z /dev/urandom:

rm /dev/random
ln -s /dev/urandom /dev/random

Widzę to jako ustawienie „Ufam /dev/urandomjako źródło entropii” .

Obawiałem się, że napotkam jakiś błąd, ale wydaje się, że zapewnia oczekiwany wynik, ponieważ polecenie natychmiast powraca.

Moje pytanie brzmi: czy istnieje jakiś znany, praktyczny i niewłaściwy efekt uboczny linkowania /dev/randomdo /dev/urandomsystemów Linux, jak to domyślnie wykonywane w systemach FreeBSD? Czy można przewidzieć ustawienie tego na stałe (na przykład w skrypcie na końcu procesu rozruchu) w przypadku powtarzających się problemów z powodu /dev/randomzablokowania niektórych usług?

WhiteWinterWolf
źródło

Odpowiedzi:

2

Zobacz Mity o urandomie , nie ma znanego ataku na / dev / urandom, który nie byłby również atakiem na / dev / random. Główny problem, jaki ma system Linux, polega na sklonowaniu i uruchomieniu go jako kilku maszyn wirtualnych bez resetowania zapisanej puli entropii po klonowaniu. To jest narożny przypadek, który jest styczny do tego, co chcesz.

Walter
źródło
0

Cóż, inna rzecz /dev/randompolega na tym, że zatrzymuje wyjście po użyciu puli entropii. Spróbuj tego:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/dev/urandomjednak ponownie użyje tej samej puli, aby kontynuować drukowanie. jak pokazano tutaj:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Gdy spróbujesz zakotwiczyć te specjalne urządzenia, twój monit może zostać pomieszany. Po prostu wpisz reseti wprowadź, terminal wróci do normy)

Użyj, /dev/urandomgdy potrzebujesz tylko wypełnić coś ciągłym przepływem „losowych” bitów. Użyj /dev/randomdla kluczy, które musisz być całkowicie losowe.

Daniel
źródło
3
Pytanie PO było następujące: czy jest jakiś znany, praktyczny i niewłaściwy efekt uboczny łączenia / dev / random z / dev / urandom w systemach Linux, jak to domyślnie wykonywane w systemach FreeBSD?
kontr-
Interesujące, jeśli różnica jest tak wyraźna, nie należy ich łączyć. Większość innych dyskusji ostatecznie osiąga konsensus bez różnicy po uruchomieniu, ale takie zachowanie może wskazywać na dłuższą różnicę.
KalleMP,
-2

W systemie Linux /dev/randomdaje losowe bity wysokiej jakości. Pochodzą one ze źródeł, które są nie do przewidzenia i nie powtarzalne, na zewnątrz maszyny. W przeciwieństwie do tego /dev/urandomużywa tych samych danych losowych co /dev/random(jeśli są dostępne), jeśli nie ma, używa generatora liczb pseudolosowych, który jest deterministyczny . Dla większości celów jest to dość nieprzewidywalne, ale nie dla bardzo wymagających aplikacji, takich jak kryptografia, a tym bardziej dla tworzenia długowiecznych kluczy, takich jak GPG.

vonbrand
źródło
6
To jest źle. /dev/urandomjest w porządku dla kryptografii .
Gilles „SO- przestań być zły”
@Gilles, który zależy od stopnia paranoi. Dla GPG, każdy ma wpływ klucza (pośrednio).
vonbrand,
5
Jeśli nie ufasz /dev/urandom, nie masz też powodu, by ufać GPG.
Gilles „SO- przestań być zły”
3
@vonbrand: W zależności od mojego stopnia paranoi, jeśli będę musiał wybrać między matematycznie sprawdzonym PRNG w celu wygenerowania losowości lub użytkownikiem zmuszonym do wpisania pełnego ekranu śmieci „asdfghasdfghasdfgh”, zdecydowanie wybrałbym oprogramowanie PRNG. Rozumiem twój punkt widzenia, że ​​komputer nie jest dobry w generowaniu losowości, ale ludzie są jeszcze gorzej. Niemniej jednak, aby wrócić do mojego pytania, z wyjątkiem debaty urandomvs. vs. random, czy potwierdzasz, że zastąpienie /dev/randompliku linkiem nie powinno mieć żadnego innego efektu ubocznego i być realną alternatywą dla rngdsztuczki, o której wspomniałem?
WhiteWinterWolf
2
To jest źle. Używają SAMEGO RNG, ale losowych bloków, jeśli zgadnie, że nie ma wystarczającej entropii.
Duncan X Simpson