Szybki sposób na zrandomizowanie HD?

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/sdaw przeszłości, ETA wyglądało na kolejność dni. Widziałem coś o używaniu badblockszamiast 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 ddlub coś innego, czego może mi brakować, lub czy prędkość jest tylko ograniczeniem HD.

dd if=/dev/urandom of=/dev/sdalub po prostu cat /dev/urandom >/dev/sda nie jest najszybszym sposobem na zapełnienie dysku losowymi danymi. Linux /dev/urandomnie jest najszybszym kryptograficznym RNG na rynku. Czy istnieje alternatywa dla / dev / urandom? ma jakieś sugestie. W szczególności OpenSSL zawiera szybsze kryptograficzne PRNG:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

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.

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.

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

Wydaje się, że zrobienie 19 TB na 24 dyskach twardych zajmuje 3 godziny. A więc około 1800 MB / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

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=2do 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ć ”

Możesz zmusić OpenSSL do szyfrowania /dev/zeroza pomocą losowego hasła, zapewniając bardzo szybkie przyzwoite dane pseudolosowe (jeśli twój procesor obsługuje przyspieszenie).

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

Możesz to pvzrobić, aby uzyskać postęp / ETA. Polecenia, które teraz uruchamiam (w powłoce root) to:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

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_bytesopenssl 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 opensslprocesów na osobnych rdzeniach, łącząc je za pomocą FIFO.

Ukończenie odpowiedzi Marco wymaga szybszego generatora liczb losowych.

Używasz prostego programu, który generuje liczby losowe z dobrej biblioteki, takiej jak boost::randomi używasz tej w dd.

Jeśli wybierzesz opcję wzmocnienia, możesz skorzystać z tego przykładu, zmieniając experimentfunkcję do swoich potrzeb.

Wąskim gardłem nie jest ani rozmiar bloku, ani dysk twardy, ale powolne generowanie liczb pseudolosowych. /dev/urandomjest o wielkości o wiele szybszy w porównaniu do, /dev/randomponieważ nie blokuje na niskiej puli entropii.

Możesz to potwierdzić, mierząc nieprzetworzone dane wyjściowe liczb pseudolosowych:

pv /dev/urandom >/dev/null

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/zerojest opcją.

streszczenie

/dev/random - bezpieczny, bardzo wolny
/dev/urandom- mniej bezpieczny¹, wolny
sprzę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/urandomjest tak bezpieczny jak /dev/random. Dzięki Gillesowi za zwrócenie na to uwagi.}

Próbowałem zapełnić zewnętrzny dysk twardy USB o pojemności 4 TB, dd if=/dev/urandom of=/dev/sdX status=progressktóry był zbyt wolny (niezależnie od bs=ustawień), i wydaje się, że opensslma 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życia shred, jak w:

shred -v -n 1 /dev/sdX

Upewnij się, że użyjesz -n 1inaczej, domyślnie zapisuje urządzenie 3 razy (plus ten, -vktó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.