Czy istnieje alternatywa dla / dev / urandom?

21

Czy istnieje jakiś szybszy sposób niż losowy / dev / [u]? Czasami muszę robić takie rzeczy jak

cat / dev / urandom> / dev / sdb

Losowe urządzenia są „zbyt” bezpieczne i niestety zbyt wolne na to. Wiem, że istnieją wipei podobne narzędzia do bezpiecznego usuwania, ale przypuszczam, że istnieją również pewne wbudowane środki do tego w Linuksie.

cgp
źródło
Odpowiednik na StackOverflow: stackoverflow.com/questions/841356/…
David Z
1
Czy dd nie jest lepszym sposobem na zrobienie tego ... Być może pretendent do nagrody UUoC?
Tom O'Connor,

Odpowiedzi:

12

Jeśli chcesz wykonać „bezpieczne” usunięcie dysku twardego (lub pliku), powinieneś spojrzeć na narzędzie do niszczenia.

Jak podkreślają poprzednie plakaty, losowe urządzenia / dev / * mają być używane jako źródło małych porcji losowych danych.

MikeyB
źródło
1
Według strony podręcznika „shred” używa / dev / urandom. Tak więc, chociaż jest dobrą odpowiedzią na wyczyszczenie dysku, nie oferuje przyspieszenia w stosunku do jakiejkolwiek innej techniki czytania z / dev / urandom. (Inna wskazówka, jeśli używasz „niszczenia”: większość ludzi prawdopodobnie będzie szczęśliwsza z 1-2 przepustkami, niż z gigantyczną domyślną liczbą, aby czyszczenie nie trwało dni).
gojomo
4
W rzeczywistości niszczenie jest znacznie szybsze niż / dev / urandom. Domyślam się, że dostarcza własnych danych pseudolosowych przy użyciu / dev / urandom lub / dev / random jako materiału siewnego.
thomasrutter
24

Niestety Linux ma złą implementację urandomu. Możesz użyć aes256-ctr z losowym kluczem i uzyskać kilkaset megabajtów pseudolosowości na sekundę, jeśli twój procesor obsługuje AES-NI (przyspieszenie sprzętowe). Z niecierpliwością czekam na bezmyślne przejście na nowoczesne podejście.

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > randomfile.bin

Szczeniak robi 1,0 GB / s na moim pudełku (w porównaniu do 14 MB / s / dev / urandom). Używa urandom tylko do utworzenia losowego hasła, a następnie wykonuje bardzo szybkie szyfrowanie / dev / zero przy użyciu tego klucza. To powinien być kryptograficznie bezpieczny PRNG, ale nie dam gwarancji.

Tronic
źródło
Dziękuję za tę niesamowitą odpowiedź. Udało mi się zwiększyć z 9,5 MB / s za pomocą / dev / urandom do ponad 120 MB / s za pomocą openssl.
NRD
Z wyjątkiem pierwszego stwierdzenia, że Linux ma złą implementację urandomu , zatwierdzam tę odpowiedź. Wystarczająco dobry, aby wyczyścić (lub wypełnić?) Dysk twardy przed szyfrowaniem.
Vikrant Chaudhary
5
Przejdź, pvaby uzyskać ładny wskaźnik postępu. openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | pv -pterb > /dev/sdb.
Vikrant Chaudhary
@VikrantChaudhary urandom produkuje pseudolosowe liczby wysokiej jakości, jasne, ale to nie jest usprawiedliwienie dla powolności. Tryb licznika AES jest znacznie szybszy i trudno jest spierać się o to, czy byłby mniej bezpieczny niż / dev / urandom.
Perseidy
1
Wystarczy dodać do pvzaleceń, można by rura pv -pterb -s $(blockdev --getsize64 /dev/sdb) >/sdbaby pvpokazać postęp w kierunku ukończenia zapisu.
asciiphil
7

W szybkim teście pod Ubuntu 8.04 na Thinkpad T60p z procesorem T2500, 1 GB losowych danych openssl randbyło 3-4 razy szybszych niż /dev/urandom. To jest,

time cat /dev/urandom | head -c 1000000000 > /dev/null

było około 4 minut, podczas gdy ...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

... było nieco ponad 1 minutę.

Nie jestem pewien, czy jest jakaś różnica w jakości losowej, ale jedno z nich prawdopodobnie nadaje się do wycierania w jakości HD.

gojomo
źródło
5

Widzę wiele odpowiedzi, które mówią, że używanie losowych danych nie jest ważne. To prawie prawda, jeśli wszystko, co próbujesz zrobić, to wyczyścić dysk, ale nie tak bardzo, jeśli czyścisz go w celu przygotowania do szyfrowania dysku.

Jeśli wypełnisz urządzenie nieprzypadkowymi danymi, umieść na nim zaszyfrowaną partycję, co może powodować problemy. Część dysku, na której przechowywane są zaszyfrowane dane, będzie się wyróżniać od reszty dysku, ponieważ zaszyfrowane dane będą wyglądać losowo, a reszta nie. Można to wykorzystać do ustalenia informacji o dysku kryptograficznym, który mógłby zostać wykorzystany do jego złamania. Poniższy link wyjaśnia teorię, w jaki sposób działają niektóre z bardziej powszechnych ataków i jak się przed nimi bronić (w każdym razie w Linuksie).

Ustawienia szyfrowania dysku twardego w systemie Linux

użytkownik104021
źródło
1
Bardzo dobrze. W przypadku stosunkowo nowoczesnych dysków (> 20 GB) każde nadpisanie jednoprzebiegowe wystarczy. Trudno byłoby nawet uzyskać NSA i podobne dane, aby uzyskać znaczną ilość danych z dysku. I to jest bardzo kosztowne. Pomyśl o 100 000 USD za megabajt. Uwaga dotycząca szyfrowania jest bardzo prawdziwa. Chcesz, aby nieużywane części dysku wyglądały „tak losowo” jak używane części.
Tonny
Czy oprogramowanie do szyfrowania urządzenia nie losuje całego dysku?
Nathan Garabedian
5

Jeśli chcesz bezpiecznie wyczyścić HD, istnieje jedno bardzo potężne narzędzie : DBAN

Arg
źródło
5

Jeśli chcesz skasować ogromne urządzenie blokowe, uważam, że jest bardziej niezawodne w użyciu ddi mapowaniu urządzeń zamiast wyjściowego przekierowywania losowych danych. Poniższe będzie mapowane /dev/sdbna /dev/mapper/deviceToBeErasedszyfrowanie i deszyfrowanie w sposób przezroczysty pomiędzy nimi. Aby wypełnić urządzenie na zaszyfrowanym końcu, zera są kopiowane na stronę tekstową mapera ( /dev/mapper/deviceToBeErased).

cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

Zaszyfrowane dane na /dev/sdbpewno są nie do odróżnienia od danych losowych, jeśli nie ma poważnego osłabienia w AES. Używany klucz jest pobierany /dev/random(nie martw się - używa tylko 32 bajtów).

Perseidy
źródło
2

Im szybsze narzędzie, tym mniej bezpieczny będzie wynik. Generowanie dobrej losowości wymaga czasu.

W każdym razie możesz użyć czegoś takiego jak dd, jeśli = / dev / zero of = / dev / sdb , ale oczywiście nie będzie to przypadkowe, po prostu skasuje się znacznie szybciej.

Inną opcją może być użycie tej metody / sbin / badblocks -c 10240 -s -w -t random -v / dev / sdb , jest szybszy niż urandom, ale badblocks PRNG jest mniej losowy.

Zoredache
źródło
1
i szczerze mówiąc - to jest mnóstwo bezpieczeństwa dla dysku
warren
Wielokrotne nadpisywanie, podobnie jak niszczenie, zajmuje dużo czasu i zapewnia większe bezpieczeństwo niż nadpisywanie „idealnie” przypadkowych danych.
Wstrzymano do odwołania.
„Im szybsze narzędzie, tym mniej bezpieczny będzie wynik. Generowanie dobrej losowości wymaga czasu”. - To nieprawda. Generator liczb losowych w trybie licznika AES (pseudo) jest znacznie lepiej analizowany, a rzędy wielkości są szybsze niż / dev / urandom. (Zobacz odpowiedź Tronic.)
Perseidy
2

/dev/random zużywa dużo entropii systemowej, a zatem generuje tylko wolny strumień danych.

/dev/urandom jest mniej bezpieczny i szybszy, ale nadal jest ukierunkowany na mniejsze porcje danych - nie ma na celu zapewnienia ciągłego strumienia dużych liczb losowych.

Powinieneś zrobić PRNG według własnego projektu i zaszczepić go czymś z /dev/randomlub /dev/urandom. Jeśli potrzebujesz go trochę bardziej losowo, wysiewaj go okresowo - co kilka MB (lub niezależnie od długości twojego pliku PRng). Pobieranie 4 bajtów (wartość 32-bitowa) z losowego lub losowego jest wystarczająco szybkie, abyś mógł to zrobić co 1k danych (ponownie ładował twój prng co 1k) i uzyskać bardzo losowe wyniki, idąc bardzo, bardzo, bardzo szybko.

-Adam

Adam Davis
źródło
7
Bardzo rzadko ktoś może napisać własny generator liczb losowych, który jest lepszy niż te, które są już łatwo dostępne. Najczęściej wynik jest przewidywalny i fałszywe poczucie bezpieczeństwa. Poleciłbym użycie shred na dysku poprzez wejście / dev lub bardzo dokładne fizyczne zniszczenie.
Wstrzymano do odwołania.
Zgadzam się. Użyłbym shred, który domyślnie używa urandom (którego szczerze mówiąc nie uważam za powolny). Uwaga: można używać / dev / random z shred (określając --random-source = / dev / random), jeśli jesteś bardzo cierpliwy.
Matthew Flaschen
2

Jeśli chcesz szybko wyczyścić dysk twardy, zapisz na nim nielosowe dane. Jest to nie mniej bezpieczne niż używanie losowych danych. Tak czy inaczej, po podłączeniu do komputera nie można odczytać oryginalnych danych. Nadpisywanie danych na dysku twardym: Wielka kontrowersja dotycząca wymazywania pokazuje, że oryginalnych danych nie można odczytać za pomocą mikroskopu.

Sciurus
źródło
2

Sformatuj za pomocą LUKS i dd na zaszyfrowanym woluminie. Następnie użyj / dev / urandom, aby wyczyścić nagłówek LUKS.

Jeśli masz sprzętową obsługę AES, jest to bardzo szybkie rozwiązanie.

Krótko:

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX cryptodev
dd if=/dev/zero bs=1M of=/dev/mapper/cryptodev
cryptsetup luksClose cryptodev
# wipe the luks header.  Yes, it uses /dev/urandom but only for 2MB of data:
dd if=/dev/urandom bs=1M count=2 of=/dev/sdX

gotowy!

Zobacz mój blog: szybko zapełnij dysk losowymi bitami (bez / dev / urandom)

Eric Wheeler
źródło
Dlaczego zawracasz sobie głowę LUKS, jeśli wszystko, co chcesz zrobić, to zastąpić urządzenie? Zwykły dm-crypt („tryb zwykły” cryptsetup) jest do tego znacznie łatwiejszy w użyciu.
Perseidy
2

Jeśli chcesz skasować dysk twardy, dd nie usuwa zawartości przeniesionych sektorów i jest bardzo powolny, jeśli dysk twardy umiera. Zamiast tego można użyć wbudowanej funkcji wymazywania dysków, która była standaryzowana od dłuższego czasu.

W tym przykładzie kasuję mechaniczny dysk twardy o pojemności 500 GB w zaledwie 102 minuty. Nawet jeśli jest pełna realokowanych sektorów:

root@ubuntu:~# hdparm --security-set-pass Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
root@ubuntu:~# time hdparm --security-erase-enhanced Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_ERASE command, password="Eins", user=user

real    102m22.395s
user    0m0.001s
sys     0m0.010s

root@ubuntu:~# smartctl --all /dev/sdaj | grep Reallocated
  5 Reallocated_Sector_Ct   0x0033   036   036   036    Pre-fail Always   FAILING_NOW 1327 

Możesz zobaczyć więcej szczegółów na stronie ata.wiki.kernel.org , jednak w ich przykładzie nie użyto opcji --security-erase-ulepszone, co jest konieczne do usunięcia wcześniej wymienionych ponownie przeniesionych sektorów.

Per Mejdal Rasmussen
źródło
1

W praktyce prawdopodobnie nie ma potrzeby inicjowania całego dysku z jednego, losowego strumienia.

Możesz utworzyć skrawek losowych danych o niewielkich rozmiarach, a następnie powtarzać je w kółko.

Upewnij się tylko, że ten fragment danych nie jest wielokrotnością normalnego rozmiaru bloku dysku, aby nie dopuścić do nadpisania skorelowanych bloków danych dokładnie tym samym bitem losowych danych. Wielkość porcji, która jest liczbą pierwszą w zakresie ~ 1 MB, powinna być dobra.

Aby zwiększyć bezpieczeństwo, zrób to jeszcze kilka razy, za każdym razem używając innego rozmiaru porcji.

Alnitak
źródło
1

Narzędzie „niszczenia” jest łatwe i szybkie. Jeśli atrybuty SMART napędu wskazują zero ponownie przydzielonych sektorów, „niszczenie” jest prawdopodobnie wystarczająco bezpieczne.

Jeśli jednak dysk ma ponownie przydzielone sektory, dane dotyczące uszkodzonych sektorów nie zostaną zastąpione. Jeśli uszkodzone lokalizacje zawierały poufne dane przed ich ponownym przydzieleniem, „niszczenie” może nie być wystarczająco dobre. „Złe” sektory można odczytać, resetując mapę alokacji dysku i (wielokrotnie) czytając je.

Możliwość zresetowania mapy alokacji złych sektorów różni się w zależności od producenta i modelu napędu.

drok
źródło
0

Jeśli wszystko, co chcesz zrobić, to zastąpić dysk, to nie ma znaczenia, czego użyjesz, ponieważ cokolwiek w ogóle pobije wszystko poza laboratorium kryminalistycznym, a ja nie ufałbym niczego, gdyby nie wkurzyć dysku, aby zatrzymać ten poziom zasobów .

Wystarczy użyć nieprzypadkowego źródła, takiego jak wszystkie zera lub zera, lub powtarzającego się wzoru, takiego jak (myślę, że to zadziała)

(head -c 4096 /dev/urandom; cat /dev/sdb/) > /dev/sdb
BCS
źródło
Może się tak zdarzyć, ale czasami nie można przekonać kierownictwa, że ​​bezpieczeństwo zapewniane przez losowy zapis nie jest tak naprawdę większe niż użycie wszystkich zer, biorąc pod uwagę, że poziom technologii wymagany do odzyskania danych jest taki sam dla obu scenariuszy. W takim przypadku często lepiej jest spełnić ten warunek, budując własny szybki generator liczb losowych.
Adam Davis