Źródła Entropy dla systemu Linux

Powiedzmy, że chcę około gigabajta przypadkowych danych z / dev / random, odpowiednich dla jednorazowego padu (więc / dev / urandom jest wyłączony.) Jak mogę zapełnić mój / dev / random wystarczającą entropią, aby to zrobić? Szukam do tego konkretnych poleceń i programów. Nie chcę nic kupować. Używam Arch Linux, jeśli to robi różnicę.

Dwa programy, które mogą zwiększyć pulę entropii bez dodatkowego sprzętu, to rng-toolsi haveged. rng-toolswykorzystuje RNG dostępne w nowoczesnych procesorach i mikroukładach, havegedwykorzystuje nowoczesną losowość procesora (zachowanie pamięci podręcznej itp.). Oba są dostępne w Arch, a wiki Arch ma ciekawą stronę na ich temat. Nie próbowałem ich używać do generowania gigabajta danych, ale powinno to być możliwe w rozsądnym czasie.

Wyraźnie wykluczasz kupowanie czegokolwiek, ale dla kompletności jest ciekawy artykuł w LWN na temat entropii z NeuG , który obejmuje dyskusję havegedi różne inne podejścia. Możesz kupić kartę STM8S z obsługą NeuG za mniej niż 10 USD lub FST-01 za 35 USD.

Niestety, / dev / random nie nadaje się również do użycia na padzie jednorazowym, a przynajmniej nie na padzie jednorazowym (z możliwymi do udowodnienia gwarancjami bezpieczeństwa), którą większość ludzi wyobraża sobie, gdy myśli o lub wdraża pady jednorazowe. Większość poniższych informacji streszczono w (bardzo długim) artykule na stronie http://www.2uo.de/myths-about-urandom/

Problem polega na tym, że / dev / random nie jest tak naprawdę losowy; wykorzystuje CSPRNG do generowania danych wyjściowych. W rzeczywistości / dev / random używa dokładnie tego samego CSPRNG, co / dev / urandom. Jedyną różnicą jest to, że / dev / random blocks, jeśli wewnętrzne oszacowanie entropii jest niewystarczające.

Kluczowe jest słowo „oszacowanie” w poprzednim zdaniu. Większość ludzi uważa, że ​​ta ocena jest zawsze dokładna i idealna, ale w rzeczywistości wcale nie jest dokładna. Gdy tylko oszacowanie jest błędne, tracisz wszystkie możliwe do udowodnienia gwarancje jednorazowego padu, a wszystko, co pozostało, to bezpieczeństwo obliczeniowe - nie lepiej niż gdybyś użył / dev / urandom!

Nieprawidłowe oszacowanie entropii nie powoduje, że twój jednorazowy pad jest trochę niepewny. Udokumentowana gwarancja bezpieczeństwa jednorazowej podkładki to wszystko albo nic.

Założeniem tego pytania jest to, że problemy z / dev / random można „naprawić”, dodając więcej entropii. Niestety, ta przesłanka jest błędna. Złośliwe źródło entropii jest znacznie gorsze niż brak entropii, ponieważ źródła entropii często mają dostęp do danych wewnętrznych i mogą je eksportować potajemnie przy użyciu danych wyjściowych RNG - patrz http://blog.cr.yp.to/20140205-entropy .html do pełnej dyskusji (zbyt długo, by streścić tutaj). W szczególności sprzętowe źródło entropii (zalecane przez kilka innych odpowiedzi) jest bardzo złym wyborem z punktu widzenia bezpieczeństwa, ponieważ sprzęt ten jest w najlepszej pozycji do robienia szkodliwych rzeczy i jest zasadniczo niesłyszalny.

Wygląda na to, że komponent sprzętowy jest najlepszym pomysłem. Istnieje kilka układów scalonych generatora HW, ale musisz im zaufać, gdy tylko przyjdą.

Dwa prawdopodobnie dobre rozwiązania to wywołanie szumu w komponencie; wydaje się, że dwa główne rozwiązania to odchylenie temperatury i hałas lawinowy powstały za pomocą diody (patrz http://web.archive.org/web/20061117145903/http://willware.net:8080/hw-rng.html )

Ponieważ elementy takie jak żyroskop i akcelerometr stały się bardziej sensowne, dzięki czemu pracują z najwyższą czułością, a używanie ich wartości LSB może być również dobrym rozwiązaniem, ale AFAIK nikt tego nie kontrolował.

To zabawne, ponieważ jest dużo papieru na NIE robić RNG, ale nie jest otwarta i zweryfikowana implementacja HW

Możesz użyć pycsprng.py . Kryptograficznie bezpieczny? Nie jestem do końca pewien, ale chciałbym trochę recenzji.

python pycsprng.py | pv | dd of=data.file bs=1024 count=1000

Potok do pvjest opcjonalny i pomoże ci tylko dowiedzieć się, ile danych zostało przesłanych.

Może się okazać, że większe rozmiary bloków (bs) zwiększają wydajność. Musisz zwiększyć liczbę, aby nie generować zbyt dużego pliku, jeśli zwiększysz rozmiar bloku.

To, co otrzymujesz z kanału mikrofonu analogowego, gdy nie podłączysz mikrofonu, jest zwykle po prostu statyczne. Prześlij go przez bzip2, na przykład w celu wybielenia, zmieszaj z innym źródłem losowości (urandom lub inne gniazdo mikrofonu), być może przesuń wynik przez openssl, aby uzyskać dobrą miarę, a to, co otrzymasz, powinno być dość losowe.

Trudno byłoby jednak udowodnić twarde i szybkie właściwości bezpieczeństwa dotyczące losowości wyniku.

Jeśli używasz jądra Linuksa 2.6.9 lub nowszego na procesorze amd64 / x86_64, w środowisku wirtualnym lub fizycznym, możesz wypróbować ncomputers.org/pandom prawdziwy generator liczb losowych, który oferuje entropię 8 KiB / s 64 ubitów / 64 bitów przez/dev/random

Aby wygenerować 100 MB losowych danych generowanych sprzętowo, możesz:

• Nagraj 20 minut dźwięku (mono 96 kHz 16 bitów) za pomocą wbudowanego mikrofonu komputera (dostępnego na laptopie). Otrzymasz plik WAV ~ 220 MB.

• Odrzuć niepotrzebne bity i potasuj bity danych binarnych (wiele sposobów na zrobienie tego) z pewną matematyką

• Wyeksportuj przetasowane bity jako plik binarny ~ 100 MB

Oto artykuł na ten temat: Próba wygenerowania prawdziwej entropii i losowych danych z dźwiękiem (i wbudowanym mikrofonem komputera) .