Есть ли альтернатива / dev / urandom?

21

Есть ли какой-нибудь более быстрый способ, чем / dev / [u] random? Иногда мне нужно делать такие вещи, как

cat / dev / urandom> / dev / sdb

Случайные устройства «слишком» безопасны и, к сожалению, слишком медленны для этого. Я знаю, что существуют wipeи аналогичные инструменты для безопасного удаления, но я полагаю, что есть и некоторые встроенные средства для этого в Linux.

CGP
источник
Эквивалент на StackOverflow: stackoverflow.com/questions/841356/…
Дэвид З
1
Разве dd не лучший способ сделать это .. Возможно, претендент на награду UUoC?
Том О'Коннор

Ответы:

12

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

Как отмечалось в предыдущих постерах, случайные устройства / dev / * предназначены для использования в качестве источника небольших порций случайных данных.

MikeyB
источник
1
Согласно справочной странице, shred использует / dev / urandom. Так что, хотя это хороший ответ для стирания диска, он не даст ускорения по сравнению с любой другой техникой чтения из / dev / urandom. (Еще один совет, если использовать «клочок»: большинство людей, вероятно, будут счастливее с 1-2 проходами, а не с гигантским счетом по умолчанию, так что
стирание
4
На самом деле shred намного быстрее, чем / dev / urandom. Я предполагаю, что он предоставляет свои собственные псевдослучайные данные, используя / dev / urandom или / dev / random в качестве начального числа.
Томасруттер
24

К сожалению, в Linux плохая реализация urandom. Вы можете использовать aes256-ctr со случайным ключом и получать несколько сотен мегабайт псевдослучайности в секунду, если ваш процессор поддерживает AES-NI (аппаратное ускорение). Я с нетерпением жду и случайного перехода на современный подход.

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

Этот щенок использует 1,0 ГБ / с на моем боксе (по сравнению с 14 МБ / с в / dev / urandom). Он использует urandom только для создания случайного пароля, а затем выполняет очень быстрое шифрование / dev / zero с использованием этого ключа. Это должен быть криптографически безопасный PRNG, но я не буду давать гарантий.

Tronic
источник
Спасибо за этот потрясающий ответ, мне удалось подняться с 9,5 МБ / с с / dev / urandom до более 120 МБ / с с openssl.
ГДР
За исключением первого утверждения, что Linux имеет плохую реализацию urandom , я одобряю этот ответ. Достаточно хорош, чтобы стереть (или заполнить?) Жесткий диск перед шифрованием.
Викрант Чаудхари
5
Пройдите pvдля хорошего индикатора прогресса. openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | pv -pterb > /dev/sdb,
Викрант Чаудхари
@VikrantChaudhary urandom, конечно, производит высококачественные псевдослучайные числа, но это не оправдывает медлительность. Режим счетчика AES намного быстрее, и трудно поспорить, насколько он будет менее безопасным, чем / dev / urandom.
Персеиды
1
Просто добавить к pvрекомендации, вы можете направить на , pv -pterb -s $(blockdev --getsize64 /dev/sdb) >/sdbчтобы pvпоказать вам прогресс в деле завершения записи.
Asciiphil
7

В быстром тесте под Ubuntu 8.04 на Thinkpad T60p с процессором T2500, 1 ГБ случайных данных openssl randбыло в 3-4 раза быстрее, чем /dev/urandom. То есть,

time cat /dev/urandom | head -c 1000000000 > /dev/null

... было около 4 минут, пока ...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

... было чуть более 1 минуты.

Не уверен, есть ли разница в случайном качестве, но, возможно, подходит и для HD-очистки.

gojomo
источник
5

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

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

Настройки шифрования жесткого диска Linux

user104021
источник
1
Очень верно. На относительно современных дисках (> 20 ГБ) достаточно однократной перезаписи. Даже АНБ и им подобные были бы в затруднении, чтобы получить какой-либо значительный объем данных с диска. И это очень дорого. Подумайте, 100.000 долларов за мегабайт. Замечание о шифровании очень верно. Вы хотите, чтобы неиспользованные части диска выглядели «столь же случайными», как и используемые части.
Тонни
Разве программное обеспечение для шифрования вашего устройства не рандомизирует весь диск?
Натан Гарабедян
5

Если вам нужно безопасно стереть HD, есть один очень мощный инструмент : DBAN

Arg
источник
5

Если вы хотите стереть огромное блочное устройство, я нашел его более надежным в использовании ddи отображением устройства вместо перенаправления вывода случайных данных. Следующее будет отображаться /dev/sdbдля /dev/mapper/deviceToBeErasedрасшифровки между ними. Чтобы заполнить устройство на зашифрованном конце, нули копируются в текстовую часть карты ( /dev/mapper/deviceToBeErased).

cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

Зашифрованные данные /dev/sdbгарантированно будут неотличимы от случайных данных, если в AES нет серьезных недостатков. Используемый ключ извлекается из /dev/random(не волнуйтесь - он использует только 32 байта).

Персеиды
источник
4

проверять случайность

http://billauer.co.il/frandom.html

по моему тесту это самый быстрый

MA1
источник
1
frandom больше не следует считать криптографически безопасным, поскольку он использует RC4. См. Blog.cryptographyengineering.com/2013/03/… для примера пограничной практической (!) Атаки на TLS при использовании RC4.
Персеиды
2

Чем быстрее ваш инструмент, тем менее безопасным будет результат. Генерация хорошей случайности требует времени.

В любом случае, вы можете использовать что-то вроде dd if = / dev / zero of = / dev / sdb , но очевидно, что это не будет случайным, оно будет просто стираться намного быстрее.

Другим вариантом может быть использование этого метода / sbin / badblocks -c 10240 -s -w -t random -v / dev / sdb, он быстрее, чем urandom, но PRNG для badblocks является менее случайным.

Zoredache
источник
1
и честно - это МНОГО безопасности для диска
Уоррен
Многократная перезапись, как и уничтожение, требует времени и обеспечивает лучшую безопасность, чем одна перезапись «совершенно» случайных данных.
Приостановлено до дальнейшего уведомления.
«Чем быстрее ваш инструмент, тем менее безопасным будет результат. Генерация хорошей случайности требует времени». - Это не правда. Генератор случайных чисел в режиме счетчика AES (псевдо) гораздо лучше анализируется и на несколько порядков быстрее, чем / dev / urandom. (См. Ответ Троника.)
Персеиды
2

/dev/random использует много системной энтропии, и поэтому создает только медленный поток данных.

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

Вы должны сделать PRNG вашего собственного дизайна и посеять что-то из /dev/randomили /dev/urandom. Если вам нужно немного более случайным образом, заполняйте его периодически - каждые несколько МБ (или независимо от длины вашего prng). Получение 4 байтов (32-битного значения) из случайного или случайного числа достаточно быстро, чтобы вы могли делать это через каждые 1 КБ данных (повторная загрузка каждые 1 КБ) и получать очень случайные результаты, причем очень, очень и очень быстро.

-Адам

Адам Дэвис
источник
7
Очень редко кто-то может написать свой собственный генератор случайных чисел, который лучше, чем те, которые уже доступны. Чаще всего результатом является предсказуемая закономерность и ложное чувство безопасности. Я бы порекомендовал использовать shred на диске через его / dev запись или очень полное физическое уничтожение.
Приостановлено до дальнейшего уведомления.
Я согласен. Я бы использовал shred, который по умолчанию использует urandom (который я откровенно не нахожу медленным). Как примечание, можно использовать / dev / random с shred (указав --random-source = / dev / random), если вы очень терпеливы.
Мэтью Флэшен
2

Если вы хотите быстро стереть жесткий диск, запишите на него неслучайные данные. Это не менее безопасно, чем использование случайных данных. В любом случае, при подключении к компьютеру исходные данные не могут быть прочитаны. Перезапись данных на жестком диске: Великая борьба за вытирание показывает, что исходные данные также нельзя прочитать с помощью микроскопа.

Sciurus
источник
2

Отформатируйте с LUKS, и dd по зашифрованному объему. Затем используйте / dev / urandom, чтобы стереть заголовок LUKS.

Если у вас есть аппаратная поддержка AES, это очень быстрое решение.

Кратко:

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX cryptodev
dd if=/dev/zero bs=1M of=/dev/mapper/cryptodev
cryptsetup luksClose cryptodev
# wipe the luks header.  Yes, it uses /dev/urandom but only for 2MB of data:
dd if=/dev/urandom bs=1M count=2 of=/dev/sdX

сделанный!

Смотрите мой блог: быстро заполнить диск случайными битами (без / dev / urandom)

Эрик Уилер
источник
Зачем вам LUKS, если все, что вы хотите сделать, это перезаписать устройство? Обычный dm-crypt («обычный режим» cryptsetup) гораздо проще в этом.
Персеиды
2

Если вы хотите стереть жесткий диск, dd не удаляет содержимое перераспределенных секторов и работает очень медленно, если жесткий диск умирает. Вместо этого вы можете использовать встроенную функцию стирания накопителей, которая уже давно стандартизирована.

В этом примере я стираю механический жесткий диск емкостью 500 ГБ всего за 102 минуты. Даже когда он полон перераспределенных секторов:

root@ubuntu:~# hdparm --security-set-pass Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
root@ubuntu:~# time hdparm --security-erase-enhanced Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_ERASE command, password="Eins", user=user

real    102m22.395s
user    0m0.001s
sys     0m0.010s

root@ubuntu:~# smartctl --all /dev/sdaj | grep Reallocated
  5 Reallocated_Sector_Ct   0x0033   036   036   036    Pre-fail Always   FAILING_NOW 1327 

Вы можете увидеть более подробную информацию на ata.wiki.kernel.org , однако в их примере не используется --security-erase-extended, что необходимо для удаления упомянутых ранее перераспределенных секторов.

Пер Мейдал Расмуссен
источник
1

На практике, вероятно, нет необходимости заполнять весь диск одним непрерывным потоком.

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

Просто убедитесь, что этот фрагмент данных не кратен нормальному размеру блока диска, чтобы не допустить перезаписи коррелированных блоков данных с одинаковым битом случайных данных. Размер чанка, который является простым числом в диапазоне ~ 1 МБ, должен хорошо работать.

Для дополнительной безопасности просто сделайте это несколько раз больше, используя каждый раз другой размер куска.

Альнитак
источник
1

Утилита 'shred' проста и быстра. Если атрибуты SMART накопителя указывают на ноль перераспределенных секторов, вероятно, «клочок» достаточно безопасен.

Однако если на диске есть перераспределенные сектора, данные о поврежденных секторах не будут перезаписаны. Если поврежденные места содержали конфиденциальные данные до того, как они были перераспределены, «клочок» может оказаться недостаточно хорошим. «Плохие» сектора могут быть прочитаны путем сброса карты распределения дисков и (многократного) чтения их.

Возможность сброса карты распределения поврежденных секторов зависит от производителя и модели накопителя.

drok
источник
0

Если все, что вы хотите сделать, это перезаписать диск, то не имеет значения, что вы используете, потому что что-то вообще побьет все, что угодно, чем криминалистическая лаборатория, и я бы не стал доверять ничему, кроме как сломать диск, чтобы остановить этот уровень ресурсов. ,

Просто используйте неслучайный источник, такой как все нули или единицы, или повторяющийся шаблон, как (я думаю, это будет работать)

(head -c 4096 /dev/urandom; cat /dev/sdb/) > /dev/sdb
BCS
источник
Это может иметь место, но иногда вы не можете убедить руководство в том, что безопасность, обеспечиваемая случайной записью, на самом деле не больше, чем использование всех нулей, учитывая, что уровень технологии, необходимый для восстановления данных, одинаков для обоих сценариев. В этом случае часто лучше выполнить требование, создав собственный быстрый генератор случайных чисел.
Адам Дэвис