Швидкий спосіб рандомізації HD?


14

Я читав про те, як зробити жорсткі диски безпечними для шифрування, і один із кроків - записати випадкові біти на диск, щоб зашифровані дані не відрізнялися від решти даних на жорсткому диску.

Однак коли я намагався використовувати dd if=/dev/urandom of=/dev/sdaв минулому, ЗНО виглядало на замовлення днів. Я бачив щось про використання badblocksзамість урандуму, але це, здається, не дуже допомогло. Я просто хотів би знати, чи є якісь способи, які можуть допомогти мені прискорити це, наприклад, варіанти ddчи щось інше, можливо, мені не вистачає, або якщо швидкість є лише обмеженням HD.


Змініть розмір блоку на щось більш дружнє щодо жорстких дисків. dd bs=1Mнаприклад.
Патрік

Яку швидкість ви набирали? Щоб записати цілий жорсткий диск на 3 ТБ (наприклад), потрібен час. Також перевірте, iostat -kx 10наскільки зайнятий% на диску.
дероберт

5
shred -v -n 1 /dev/overwritethisшвидко. Йдеться про єдиний випадок, коли shredнасправді щось корисне.
frostschutz

@derobert: Я не можу точно сказати, наскільки швидко це було, але я пішов на кілька годин, повернувся, і це було близько 10% в повному обсязі для мого внутрішнього HD 500G, коли я вперше спробував це. Дякуємо за підказку "iostat" btw
bitflips

@Patrick: Я спробував bs = 4M на зразок наосліп, оскільки побачив, що в керівництві про те, як поставити компакт-диск Arch на usb. Це трохи допомогло, але все ще було досить повільним.
bitflips

Відповіді:


14

dd if=/dev/urandom of=/dev/sdaабо, просто cat /dev/urandom >/dev/sda , це не найшвидший спосіб заповнити диск випадковими даними. Linux - /dev/urandomце не найшвидший криптографічний RNG. Чи є альтернатива / dev / urandom? має деякі пропозиції. Зокрема, OpenSSL містить більш швидкий криптографічний PRNG:

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

Зауважте, що зрештою, чи є поліпшення чи ні, залежить від того, яка частина є вузьким місцем: ЦП чи диск.

Хороша новина полягає в тому, що наповнення диска випадковими даними здебільшого марно. По-перше, розвіяти загальний міф, протирання нулями так само добре на сьогоднішньому обладнання . Завдяки технології жорсткого диска 1980-х років, перезавантаження жорсткого диска з нулями залишило невеликий залишковий заряд, який можна було відновити дещо дорогим обладнанням; необхідні кілька пропусків перезапису з випадковими даними ("Гайтмана"). Сьогодні навіть один пропуск запису з нулями залишає дані, які неможливо реально відновити навіть у лабораторних умовах.

Під час шифрування розділу не потрібно заповнювати диск випадковими даними для конфіденційності зашифрованих даних. Це корисно лише в тому випадку, якщо вам потрібно зробити простір, який використовуються зашифрованими даними, які не відрізняються від невикористаного простору. Побудова зашифрованого тома поверх нерандомізованого контейнера виявляє, які дискові блоки коли-небудь використовували зашифрований том. Це дає добрий натяк на максимальний розмір файлової системи (хоча з часом вона стане гіршою і гіршою наближенням) та ще трохи.


4
Гутман - це міф у повному обсязі, я не думаю, що насправді це теж не робилося для жорсткого диска 1980-х років. Іронія полягає в тому, що, коли диски стають розумнішими, ви фактично повинні використовувати випадкові дані сьогодні, щоб переконатися, що накопичувач змушений записувати, а не вільний сектор (обрізка) або стискання даних. Нулі корисні лише тоді, коли вони насправді написані.
frostschutz

1
@mellowmaroon Так, cat /dev/zeroмайже завжди достатньо. Це недостатньо лише, якщо ви хочете приховати, скільки місця буде вільно в зашифрованому томі.
Жил "ТАК - перестань бути злим"

1
@mellowmaroon Це майже марно. Підслуховувач буде знати, що у вас є щонайбільше X MB даних (а можливо, і набагато менше, тому що раніше використовуваний, але тепер вільний простір не відрізняється від використовуваного простору), і що? Також розташування вільного простору може виявити тип файлової системи (копії суперблоку); це рідко викликає занепокоєння (зазвичай це піддається відкритому тексту /etc/fstab, якщо ви не зашифрували кореневий розділ, і навіть тоді не існує такої великої кількості правдоподібних варіантів).
Жил "ТАК - перестань бути злим"

2
@Gilles Проблема, з якою я зіткнувся в Ubuntu 13.10, полягає в тому, що, openssl randсхоже, є верхня межа кількості байтів, які він буде генерувати. Якщо ви перевищите цей ліміт, наприклад, 'openssl rand 810000000000 , 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 openssl`, щоб отримати стільки випадкових байтів.
нераціональне Іоанна

1
Для ірраціональної проблеми з верхніми межами Джона 810 мільярдів байтів виходять близько 754 ГБ. Як щодо розподілу диска на кілька розділів 700 ГБ, потім запуску openssl randкоманди на кожному розділі в зворотному порядку, починаючи від sda5 або будь-якого іншого і працюючи назад до sda1 і нарешті sda?
jia103

6

Здається, що Opensl для мене не працює. У мене з'явилися "невідомі варіанти" та інші проблеми із наданими рішеннями. Тому я закінчив програму fio.

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

Мабуть, потрібно 20 годин, щоб зробити 19 ТБ на 24 HDD. Так приблизно 1800 Мб / с

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]

Я сподіваюся, що це насправді випадкові дані. На головній сторінці пише fio "За замовчуванням: заповнюйте буфери випадковими даними". http://linux.die.net/man/1/fio

Я не роблю це в цілях безпеки / шифрування, просто намагаюся бути впевненим, що мої пізніші тести для читання - це фактичні дані, а не лише 0. Ця ж команда fio може використовуватися для попередньої кондиціонування SSD / NVMe. Оскільки тільки використання / dev / zero може призвести до стиснення рівня диска, що «обманює», скільки насправді написано. Хоча я би додав -loops=2до нього прапор, якщо це свіжий SSD для бенчмаркінгу.

Якщо ви хочете, щоб він був захищеним, можливо, ви зможете скористатись -randrepeat=bool опцією, оскільки це переключить "Посіяти генератор випадкових чисел передбачуваним способом, щоб результати можна повторювати через прогони. За замовчуванням: вірно", але я все одно не певна, наскільки це було б безпечно.

Крім того, деякі жорсткі диски корпоративного класу існують SED (самокодируючі диски), які дозволять вам повернути ключ шифрування, щоб миттєво та надійно стерти всі записані дані.

Нарешті, я раніше використовував DBAN (він же "Дарік Boot and Nuke"), який має варіанти завантаження CD та USB, і "це проект з відкритим кодом, розміщений на SourceForge. Програма призначена для безпечного видалення жорсткого диска, поки його дані не будуть постійно вилучено і більше не підлягає відновленню "


1
Розмір = 100% не працював для мене, але fill_device = 1 (або fill_fs = 1) зробив.
d.jamison

Я думаю, що це буде залежно, якщо ви надасте йому пристрій рівня блоку або файлову систему для заповнення. Завдяки пристрою рівня блоку він знає, наскільки він великий, а розмір - відсоток від розміру пристрою. Куди йде, як fill_device, поки не отримає повну помилку пристрою. Я думаю, що прапор fill_device може не перезаписати жодні файли, просто невикористаний простір. Я не піддавав це тесту, оскільки зазвичай уникаю файлових систем, якщо це не потрібно, коли я роблю тестування пристроїв.
Тейлор Санчес

6

Ви можете отримати OpenSSL для шифрування /dev/zeroз випадковим паролем, даючи пристойні псевдовипадкові дані дуже швидко (якщо ваш процесор підтримує його прискорення).

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

Ви можете pvподати цю заявку, щоб отримати прогрес / ЗНО. Команди, які я зараз виконую (у кореневій оболонці), є:

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

Цю думку я отримав з цієї відповіді , маючи ту ж проблему, що і нераціональний Джон , коментуючи відповідь Гілла вище. Це збільшило швидкість стерти до мого нового RAID-масиву з 11 МБ / с до приблизно 300 МБ / с, зайнявши те, що зайняло тиждень до 10 годин.

Додам, що ви повинні мати можливість скоріше використовувати складніші твердження, але є помилка, яка дозволить отримати лише 16 Мб результатів. (Ця помилка була подана, січень 2016 р.)openssl rand #of_bytesopenssl enc ...ssl

І, відповідно до відповіді на це питання , і продовжуючи вважати, що процесор є вузьким місцем, можливо, можна збільшити швидкість ще більше, запустивши кілька паралельних opensslпроцесів на окремих ядрах, поєднуючи їх за допомогою FIFO.


Не впевнений, що редагування було необхідним. Інші відповіді на це питання підказують openssl rand.
тремтіння

2
Орієнтир:: dd if=/dev/urandom18MiB / s openssl enc,: ~ 180MiB / s fio,: 169MiB / s, openssl randнемає підтримки> 754GB. Зверніть увагу , що якщо ви хочете автоматичне обчислення розміру, використовуйте: 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. Обережно, sdaдвічі присутній у цій команді.
KrisWebDev

0

Завершуючи відповідь Марко, вам потрібно швидший генератор випадкових чисел.

Ви використовуєте просту програму, яка відображає випадкові числа з хорошої бібліотеки, як boost::randomі використовує це в dd.

Якщо ви виберете імпульс, ви можете використовувати цим прикладом, змінивши experimentфункцію на свої потреби.


Наскільки швидше розширювальне рішення у вашій системі? Швидкий ненауковий орієнтир на моїй машині дає точно таку ж швидкість, як і /dev/urandom.
Марко

boost::randomне пропонує крипто RNG, чи не так? Якщо ви збираєтесь використовувати некриптовий RNG, ви також можете використовувати нулі: принаймні, у вас не буде ілюзії безпеки.
Жиль "ТАК - перестань бути злим"

Я не можу бути конкретним щодо того, наскільки швидкіші boost::randomгенератори, єдиний спосіб точно знати - це виміряти їх найшвидший алгоритм проти/dev/urandom
RSFalcon7

0

Вузьке місце, якщо ні розмір блоку, ні жорсткий диск, але повільне генерування псевдовипадкових чисел. /dev/urandomна величину швидше порівняно /dev/randomз тим, що він не блокується на пулі з низькою ентропією.

Ви можете підтвердити це, вимірявши вихідний вихід псевдовипадкових чисел:

pv /dev/urandom >/dev/null

Ця швидкість буде набагато повільніше, ніж швидкість запису вашого жорсткого диска. Правильне рішення повністю залежить від необхідного рівня безпеки. Якщо вам потрібен високий рівень безпеки, використовуйте швидкий апаратний генератор випадкових випадків або прийміть низьку швидкість. Якщо ваші потреби в безпеці не такі високі, ви можете зафіксувати кілька десятків МіБ даних і повторно записати цей рядок на диск. А може, навіть написання нулів /dev/zero- це варіант.

Підсумок

/dev/random - безпечний, дуже повільний
/dev/urandom- менш безпечний¹, повільний
апаратний RNG - безпечний, швидкий, дуже дорогий
( /dev/zero - зовсім не випадковий, дуже швидкий)

¹ Відповідно Чи безпечний rand від / dev / urandom для ключа входу? /dev/urandomтак само безпечно, як і /dev/random. Дякую Жилсу, що вказав на це.


Він уже використовує urandom.
Патрік

Справді. Моя думка, що навіть урандум занадто повільний для його потреб, тому йому потрібне інше рішення, ніж урадон.
Марко


@Gilles Дякуємо за посилання. На сторінці людини чітко зазначено: … Як результат, якщо в пулі ентропії недостатньо ентропії, повернені значення теоретично вразливі до криптографічної атаки… Ось чому я класифікував це як менш безпечний.
Марко

0

Я намагався заповнити зовнішній жорсткий диск USB 4 ТБ, dd if=/dev/urandom of=/dev/sdX status=progressякий був занадто повільним (незалежно від bs=налаштувань), і, здається, opensslмає обмеження на кількість випадкових даних, які він виведе (принаймні для версії 1.0.2p). Найкращим варіантом, який я знайшов, був коментар від frostschutz для використання shred, як у:

shred -v -n 1 /dev/sdX

Переконайтеся, що в -n 1іншому випадку це буде за замовчуванням записати пристрій 3 рази більше (плюс той, -vщо показує прогрес). Я не думаю, що якість псевдовипадкових чисел така висока, але мені достатньо підготувати портативний жорсткий диск великої ємності для шифрування.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.