Przeczytałem o tym, jak zabezpieczyć dyski twarde przed szyfrowaniem, a jednym z kroków jest zapisanie losowych bitów na dysku, aby zaszyfrowane dane były nierozróżnialne od reszty danych na dysku twardym.
Jednak kiedy próbowałem użyć dd if=/dev/urandom of=/dev/sda
w przeszłości, ETA wyglądało na kolejność dni. Widziałem coś o używaniu badblocks
zamiast urandomu, ale to nie bardzo pomogło. Chciałbym tylko wiedzieć, czy istnieją jakieś sposoby, które mogą pomóc mi to przyspieszyć, takie jak opcje dd
lub coś innego, czego może mi brakować, lub czy prędkość jest tylko ograniczeniem HD.
encryption
dd
random
bitflipy
źródło
źródło
dd bs=1M
na przykład.iostat -kx 10
zajęty% na dysku jest.shred -v -n 1 /dev/overwritethis
jest szybki. Chodzi o jedyny przypadek, w którymshred
jest do czegoś przydatny.Odpowiedzi:
dd if=/dev/urandom of=/dev/sda
lub po prostucat /dev/urandom >/dev/sda
nie jest najszybszym sposobem na zapełnienie dysku losowymi danymi. Linux/dev/urandom
nie jest najszybszym kryptograficznym RNG na rynku. Czy istnieje alternatywa dla / dev / urandom? ma jakieś sugestie. W szczególności OpenSSL zawiera szybsze kryptograficzne PRNG:Zauważ, że ostatecznie to, czy nastąpi poprawa, zależy od tego, która część stanowi wąskie gardło: procesor czy dysk.
Dobrą wiadomością jest to, że zapełnianie dysku losowymi danymi jest w większości bezużyteczne. Po pierwsze, aby obalić wspólny mit, czyszczenie zerami jest tak samo dobre na dzisiejszym sprzęcie . W przypadku technologii dysku twardego z lat 80. nadpisanie dysku twardego zerami pozostawiło niewielki ładunek rezydualny, który można odzyskać za pomocą dość drogiego sprzętu; konieczne było wielokrotne nadpisanie losowymi danymi („czyszczenie Gutmanna”). Dziś nawet jedno przejście nadpisania zerami pozostawia dane, których nie można realistycznie odzyskać nawet w warunkach laboratoryjnych.
Podczas szyfrowania partycji wypełnienie dysku losowymi danymi nie jest konieczne dla zachowania poufności zaszyfrowanych danych. Przydaje się to tylko wtedy, gdy trzeba uczynić przestrzeń wykorzystywaną przez zaszyfrowane dane nieodróżnialną od niewykorzystanej przestrzeni. Zbudowanie zaszyfrowanego woluminu na niepodzielonym kontenerze ujawnia, które bloki dyskowe były kiedykolwiek używane przez zaszyfrowany wolumin. Daje to dobrą wskazówkę co do maksymalnego rozmiaru systemu plików (choć z biegiem czasu będzie coraz gorzej) i niewiele więcej.
źródło
cat /dev/zero
prawie zawsze wystarczy. To nie wystarczy, jeśli chcesz ukryć, ile miejsca jest wolne na zaszyfrowanym woluminie./etc/fstab
, chyba że zaszyfrowałeś partycję root, a nawet wtedy nie ma tak dużej liczby możliwych opcji).openssl rand
wydaje się , że ma on górną granicę liczby generowanych bajtów. Jeśli przekroczysz ten limit, np. „Openssl rand 810000000000 openssl”,, then no random output is generated. Only a brief "help" text is printed. I'm trying to random (pretty much) fill a 3TB hard drive. Not sure if there is a way to get
aby wygenerować tyle losowych bajtów.openssl rand
polecenia na każdej partycji w odwrotnej kolejności, zaczynając od sda5 lub cokolwiek innego i pracując wstecz do sda1 i wreszcie sda?Wydaje się, że openssl nie działa. Dostałem „nieznane opcje” i inne problemy z dostarczonymi rozwiązaniami. Więc skończyłem z programem fio.
Wydaje się, że zrobienie 19 TB na 24 dyskach twardych zajmuje 3 godziny. A więc około 1800 MB / s
Mam nadzieję, że to właściwie losowe dane. Strona podręcznika mówi fio „Domyślnie: wypełniaj bufory losowymi danymi”. http://linux.die.net/man/1/fio
Nie robię tego dla celów bezpiecznego / szyfrowania, próbuję tylko upewnić się, że moje późniejsze testy odczytu są rzeczywistymi danymi, a nie tylko zerami. Tego samego polecenia fio można użyć do wstępnego kondycjonowania SSD / NVMe. Ponieważ samo użycie / dev / zero może prowadzić do kompresji na poziomie dysku, „oszukuje”, ile faktycznie jest napisane. Chociaż dodałbym
-loops=2
do niego flagę, jeśli jest to nowy dysk SSD do testów porównawczych.Jeśli chcesz, aby było bezpieczne, możesz skorzystać z tej
-randrepeat=bool
opcji, ponieważ spowoduje to przełączenie „Ziarno generatora liczb losowych w przewidywalny sposób, dzięki czemu wyniki będą powtarzalne dla różnych przebiegów. Domyślnie: prawda.”, Ale nadal nie jestem pewne, jak bezpieczne byłoby to.Ponadto niektóre dyski twarde klasy korporacyjnej są wyposażone w dyski SED (Self Encrypting Drives) i pozwalają na obrócenie klucza szyfrowania, aby natychmiast i bezpiecznie usunąć wszystkie zapisane dane.
Wreszcie, w przeszłości korzystałem z DBAN (znanego również jako Darik's Boot and Nuke), który ma opcje rozruchowe CD i USB i „jest projektem open source hostowanym na SourceForge. Program ma na celu bezpieczne usuwanie dysku twardego, dopóki jego dane nie zostaną trwale usunięte i nie można ich już odzyskać ”
źródło
Możesz zmusić OpenSSL do szyfrowania
/dev/zero
za pomocą losowego hasła, zapewniając bardzo szybkie przyzwoite dane pseudolosowe (jeśli twój procesor obsługuje przyspieszenie).Możesz to
pv
zrobić, aby uzyskać postęp / ETA. Polecenia, które teraz uruchamiam (w powłoce root) to:Ten pomysł czerpałem z tej odpowiedzi , po tym samym problemie jak irracjonalny John , który skomentował powyższą odpowiedź Gillesa. To zwiększyło moją szybkość czyszczenia do mojej nowej macierzy RAID z 11 MB / s do około 300 MB / s, zmniejszając to, co zajęło tydzień do 10 godzin.
Dodam, że powinieneś być w stanie użyć zamiast bardziej skomplikowanej instrukcji powyżej, ale jest błąd, który pozwoli wygenerować tylko 16 MB danych wyjściowych. (Ten błąd został zgłoszony, styczeń 2016 r.)
openssl rand #of_bytes
openssl enc ...
ssl
I zgodnie z odpowiedzią na to pytanie , i nadal zakładając, że procesor jest wąskim gardłem, możliwe może być dalsze zwiększenie prędkości poprzez uruchomienie wielu równoległych
openssl
procesów na osobnych rdzeniach, łącząc je za pomocą FIFO.źródło
openssl rand
.dd if=/dev/urandom
Mb / sopenssl enc
,: ~ 180 Mb / sfio
,: 169 Mb / s,openssl rand
brak wsparcia> 754 GB. Należy pamiętać, że jeśli chcesz kalkulacji auto-size, należy:openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero | pv --progress --eta --rate --bytes --size $(</proc/partitions awk '$4=="sda" {print sprintf("%.0f",$3*1024)}') | dd of=/dev/sda bs=2M
. Uwaga,sda
w tym poleceniu występuje dwukrotnie.Ukończenie odpowiedzi Marco wymaga szybszego generatora liczb losowych.
Używasz prostego programu, który generuje liczby losowe z dobrej biblioteki, takiej jak
boost::random
i używasz tej wdd
.Jeśli wybierzesz opcję wzmocnienia, możesz skorzystać z tego przykładu, zmieniając
experiment
funkcję do swoich potrzeb.źródło
/dev/urandom
.boost::random
nie oferuje kryptograficznego RNG, prawda? Jeśli zamierzasz używać nie kryptograficznego RNG, równie dobrze możesz użyć zer: przynajmniej nie będziesz miał złudzeń bezpieczeństwa.boost::random
są generatory. Jedynym sposobem, aby się przekonać, jest zmierzenie ich najszybszego algorytmu/dev/urandom
Wąskim gardłem nie jest ani rozmiar bloku, ani dysk twardy, ale powolne generowanie liczb pseudolosowych.
/dev/urandom
jest o wielkości o wiele szybszy w porównaniu do,/dev/random
ponieważ nie blokuje na niskiej puli entropii.Możesz to potwierdzić, mierząc nieprzetworzone dane wyjściowe liczb pseudolosowych:
Szybkość ta będzie znacznie mniejsza niż szybkość zapisu na dysku twardym. Prawidłowe rozwiązanie całkowicie zależy od wymaganego poziomu bezpieczeństwa. Jeśli potrzebujesz wysokiego bezpieczeństwa, użyj szybkiego sprzętowego generatora losowego lub zaakceptuj małą prędkość. Jeśli Twoje potrzeby w zakresie bezpieczeństwa nie są tak wysokie, możesz przechwycić kilkadziesiąt MiB danych i wielokrotnie zapisać ten ciąg na dysku. A może nawet pisanie zer
/dev/zero
jest opcją.streszczenie
/dev/random
- bezpieczny, bardzo wolny/dev/urandom
-mniejbezpieczny¹, wolnysprzętowy RNG - bezpieczny, szybki, bardzo drogi
(
/dev/zero
- wcale nie losowy, bardzo szybki)¹ Według Czy rand z / dev / urandom jest bezpieczny dla klucza logowania?
/dev/urandom
jest tak bezpieczny jak/dev/random
. Dzięki Gillesowi za zwrócenie na to uwagi.źródło
urandom
./dev/random
.Próbowałem zapełnić zewnętrzny dysk twardy USB o pojemności 4 TB,
dd if=/dev/urandom of=/dev/sdX status=progress
który był zbyt wolny (niezależnie odbs=
ustawień), i wydaje się, żeopenssl
ma ograniczenie ilości losowych danych, które wyśle (przynajmniej dla wersji 1.0.2p). Najlepszą opcją, jaką znalazłem, był komentarz od frostschutz do użyciashred
, jak w:shred -v -n 1 /dev/sdX
Upewnij się, że użyjesz
-n 1
inaczej, domyślnie zapisuje urządzenie 3 razy (plus ten,-v
który pokazuje postęp). Nie sądzę, aby jakość liczb pseudolosowych była tak wysoka, ale wystarczy mi przygotować przenośny dysk twardy o dużej pojemności do szyfrowania.źródło