Быстрый способ рандомизировать HD?

Я читал о том, как сделать жесткие диски безопасными для шифрования, и одним из шагов является запись случайных битов на диск, чтобы сделать зашифрованные данные неотличимыми от остальных данных на жестком диске.

Тем не менее, когда я пытался использовать dd if=/dev/urandom of=/dev/sdaв прошлом, ETA выглядела на порядок дней. Я видел кое-что об использовании badblocksвместо случайного, но это, казалось, не очень помогло. Я просто хотел бы знать, есть ли какие-либо способы, которые могут помочь мне ускорить это, такие как варианты ddили что-то еще, что я могу пропустить, или если скорость - только ограничение HD.

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-х, перезапись жесткого диска нулями оставила небольшой остаточный заряд, который можно было бы восстановить с помощью довольно дорогого оборудования; было необходимо несколько проходов перезаписи со случайными данными («стирание Гутмана»). Сегодня даже один проход перезаписи с нулями оставляет данные, которые не могут быть реально восстановлены даже в лабораторных условиях.

При шифровании раздела заполнение диска случайными данными не требуется для обеспечения конфиденциальности зашифрованных данных. Это полезно, только если вам нужно сделать пространство, используемое зашифрованными данными, неотличимым от неиспользуемого пространства. Создание зашифрованного тома поверх неслучайного контейнера показывает, какие блоки диска когда-либо использовались зашифрованным томом. Это дает хороший намек на максимальный размер файловой системы (хотя со временем это будет становиться все хуже и хуже) и немного больше.

Openssl, похоже, не работает для меня. Я получил "неизвестные варианты" и другие проблемы с предоставленными решениями. Так что я закончил с программой FIO.

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

Что, кажется, занимает 3 часа, чтобы сделать 19 ТБ на 24 жестких дисках. Итак, примерно 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]

Я надеюсь, что это на самом деле случайные данные. Страница man говорит fio "По умолчанию: заполнить буферы случайными данными." http://linux.die.net/man/1/fio

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

Если вы хотите, чтобы он был безопасным, вы можете использовать эту -randrepeat=bool опцию, так как она переключит «Заполнить генератор случайных чисел предсказуемым образом, чтобы результаты можно было повторять при каждом прогоне. По умолчанию: true.», Но я все еще не уверен, насколько это безопасно.

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

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

Вы можете заставить 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чтобы получить прогресс / ETA. Команды, которые я сейчас запускаю (в корневой оболочке):

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.

Завершая ответ Марко, вам нужен более быстрый генератор случайных чисел.

Вы используете простую программу, которая выводит случайные числа из хорошей библиотеки, например, boost::randomи используете ее в dd.

Если вы выберете boost, вы можете использовать этот пример, изменив experimentфункцию в соответствии с вашими потребностями.

Узким местом является не размер блока и не жесткий диск, а медленная генерация псевдослучайных чисел. /dev/urandomпо величине быстрее по сравнению /dev/randomс тем, что он не блокируется в пуле с низкой энтропией.

Вы можете подтвердить это, измерив необработанный вывод ваших псевдослучайных чисел:

pv /dev/urandom >/dev/null

Эта скорость будет намного ниже, чем скорость записи вашего жесткого диска. Правильное решение полностью зависит от вашего уровня безопасности. Если вам требуется высокий уровень безопасности, используйте быстрый аппаратный генератор случайных чисел или примите медленную скорость. Если ваши потребности в безопасности не так высоки, вы можете записать несколько десятков МБ данных и многократно записать эту строку на диск. Или, может быть, даже запись нулей из /dev/zero- это вариант.

Резюме

/dev/random - безопасный, очень медленный
/dev/urandom- менее безопасный - медленный
аппаратный ГСЧ - безопасный, быстрый, очень дорогой
( /dev/zero - вообще не случайный, очень быстрый)

¹ _{Согласно: Является ли ранд из / dev / urandom безопасным для ключа входа? /dev/urandomтак же безопасно, как /dev/random. Спасибо Жилю за указание на это.}

Я пытался заполнить внешний жесткий диск 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что показывает прогресс). Я не думаю, что качество псевдослучайных чисел такое высокое, но мне достаточно подготовить переносной жесткий диск большой емкости для шифрования.