Я читал о том, как сделать жесткие диски безопасными для шифрования, и одним из шагов является запись случайных битов на диск, чтобы сделать зашифрованные данные неотличимыми от остальных данных на жестком диске.
Тем не менее, когда я пытался использовать dd if=/dev/urandom of=/dev/sda
в прошлом, ETA выглядела на порядок дней. Я видел кое-что об использовании badblocks
вместо случайного, но это, казалось, не очень помогло. Я просто хотел бы знать, есть ли какие-либо способы, которые могут помочь мне ускорить это, такие как варианты dd
или что-то еще, что я могу пропустить, или если скорость - только ограничение HD.
encryption
dd
random
bitflips
источник
источник
dd bs=1M
например.iostat -kx 10
что занято% на диске.shred -v -n 1 /dev/overwritethis
это быстро. Это единственный случай, когдаshred
что-то действительно полезно.Ответы:
dd if=/dev/urandom of=/dev/sda
или простоcat /dev/urandom >/dev/sda
не самый быстрый способ заполнить диск случайными данными. Linux/dev/urandom
не самый быстрый криптографический RNG. Есть ли альтернатива / dev / urandom? есть некоторые предложения. В частности, OpenSSL содержит более быстрый криптографический PRNG:Обратите внимание, что в конечном итоге, есть ли улучшение или нет, зависит от того, какая часть является узким местом: процессор или диск.
Хорошей новостью является то, что заполнение диска случайными данными в большинстве случаев бесполезно. Во-первых, чтобы развеять общий миф, стереть с нуля так же хорошо на современном оборудовании . С технологией жесткого диска 1980-х, перезапись жесткого диска нулями оставила небольшой остаточный заряд, который можно было бы восстановить с помощью довольно дорогого оборудования; было необходимо несколько проходов перезаписи со случайными данными («стирание Гутмана»). Сегодня даже один проход перезаписи с нулями оставляет данные, которые не могут быть реально восстановлены даже в лабораторных условиях.
При шифровании раздела заполнение диска случайными данными не требуется для обеспечения конфиденциальности зашифрованных данных. Это полезно, только если вам нужно сделать пространство, используемое зашифрованными данными, неотличимым от неиспользуемого пространства. Создание зашифрованного тома поверх неслучайного контейнера показывает, какие блоки диска когда-либо использовались зашифрованным томом. Это дает хороший намек на максимальный размер файловой системы (хотя со временем это будет становиться все хуже и хуже) и немного больше.
источник
cat /dev/zero
почти всегда достаточно. Недостаточно, если вы хотите скрыть, сколько свободного места на зашифрованном томе./etc/fstab
, если только вы не зашифровали корневой раздел, и даже в этом случае не так много правдоподобных вариантов).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`, вы получите столько случайных байтов.openssl rand
выполнить команду для каждого раздела в обратном порядке, начиная с sda5 или чего-то еще и работая в обратном направлении к sda1 и, наконец, sda?Openssl, похоже, не работает для меня. Я получил "неизвестные варианты" и другие проблемы с предоставленными решениями. Так что я закончил с программой FIO.
Что, кажется, занимает 3 часа, чтобы сделать 19 ТБ на 24 жестких дисках. Итак, примерно 1800 МБ / с
Я надеюсь, что это на самом деле случайные данные. Страница 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
случайным паролем, предоставляя приличные псевдослучайные данные очень быстро (если ваш процессор поддерживает их ускорение).Вы можете передать это,
pv
чтобы получить прогресс / ETA. Команды, которые я сейчас запускаю (в корневой оболочке):Я получил эту идею из этого ответа , после того, как столкнулся с той же проблемой, что и иррациональный Джон , который прокомментировал ответ Жиля выше. Это увеличило мою скорость очистки до моего нового RAID-массива с 11 МБ / с до примерно 300 МБ / с, что заняло неделю до 10 часов.
Я добавлю, что вы должны быть в состоянии использовать, а не более сложный оператор, описанный выше, но есть ошибка, которая позволит производить только 16 МБ вывода. (Эта ошибка была подана, январь 2016 г.)
openssl rand #of_bytes
openssl enc ...
ssl
И, согласно ответу на этот вопрос , и продолжая предполагать, что ЦП является узким местом, возможно, можно еще больше увеличить скорость, запустив несколько параллельных
openssl
процессов на отдельных ядрах, комбинируя их с помощью FIFO.источник
openssl rand
.dd if=/dev/urandom
18 МБ / с,openssl enc
~ 180 МБ / с,fio
169 МБ / с,openssl rand
без поддержки> 754 ГБ. Обратите внимание , что если вы хотите автоматическое вычисление размера, используйте: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
присутствует дважды в этой команде.Завершая ответ Марко, вам нужен более быстрый генератор случайных чисел.
Вы используете простую программу, которая выводит случайные числа из хорошей библиотеки, например,
boost::random
и используете ее вdd
.Если вы выберете boost, вы можете использовать этот пример, изменив
experiment
функцию в соответствии с вашими потребностями.источник
/dev/urandom
.boost::random
не предлагает крипто-ГСЧ, не так ли? Если вы собираетесь использовать не крипто-ГСЧ, вы также можете использовать нули: по крайней мере, у вас не будет иллюзии безопасности.boost::random
сказать, насколько быстры генераторы, единственный способ узнать наверняка, это измерить их самый быстрый алгоритм/dev/urandom
Узким местом является не размер блока и не жесткий диск, а медленная генерация псевдослучайных чисел.
/dev/urandom
по величине быстрее по сравнению/dev/random
с тем, что он не блокируется в пуле с низкой энтропией.Вы можете подтвердить это, измерив необработанный вывод ваших псевдослучайных чисел:
Эта скорость будет намного ниже, чем скорость записи вашего жесткого диска. Правильное решение полностью зависит от вашего уровня безопасности. Если вам требуется высокий уровень безопасности, используйте быстрый аппаратный генератор случайных чисел или примите медленную скорость. Если ваши потребности в безопасности не так высоки, вы можете записать несколько десятков МБ данных и многократно записать эту строку на диск. Или, может быть, даже запись нулей из
/dev/zero
- это вариант.Резюме
/dev/random
- безопасный, очень медленный/dev/urandom
-менеебезопасный - медленныйаппаратный ГСЧ - безопасный, быстрый, очень дорогой
(
/dev/zero
- вообще не случайный, очень быстрый)¹ Согласно: Является ли ранд из / dev / urandom безопасным для ключа входа?
/dev/urandom
так же безопасно, как/dev/random
. Спасибо Жилю за указание на это.источник
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
что показывает прогресс). Я не думаю, что качество псевдослучайных чисел такое высокое, но мне достаточно подготовить переносной жесткий диск большой емкости для шифрования.источник