Есть ли какой-то более быстрый способ, чем /dev/[u]random? Иногда мне нужно делать такие вещи, как:
cat /dev/urandom > /dev/sdb
Случайные устройства «слишком» безопасны и, к сожалению, слишком медленны для этого. Я знаю, что существует wipe и подобные инструменты для безопасного удаления, но я полагаю, что в Linux есть и встроенные средства для этого.
Ответ 1
К сожалению, в Linux плохо реализован urandom. Вы можете использовать aes256-ctr со случайным ключом и получить несколько сотен мегабайт псевдослучайности в секунду, если ваш процессор поддерживает AES-NI (аппаратное ускорение). Я с нетерпением жду, когда urandom перейдет на современный подход.
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 с помощью этого ключа. Это должен быть криптографически безопасный ГПСЧ, но я не буду давать гарантий.
Ответ 2
Во многих ситуациях предполагается, что использование случайных данных не имеет значения. Это практически верно, если вы пытаетесь просто стереть диск, но не совсем верно, если вы стираете его в процессе подготовки к шифрованию диска.
Если заполнить устройство неслучайными данными, а затем поместить на него зашифрованный раздел, можно столкнуться с проблемой. Часть диска, на которой хранятся зашифрованные данные, будет выделяться на фоне остальной части диска, поскольку зашифрованные данные будут выглядеть случайными, а остальные — нет. Это может быть использовано для определения информации о криптодиске, которая затем может быть использована для его взлома.
Ответ 3
Если вы хотите стереть устройство с огромным блоком, то я обнаружил, что более надежным является использование dd и маппера устройств вместо перенаправления случайных данных на выход. Ниже приведено отображение /dev/sdb на /dev/mapper/deviceToBeErased en- и расшифровка прозрачно между ними. Чтобы заполнить устройство на зашифрованном конце, нули копируются на открытую текстовую сторону маппера (/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
/dev/random использует много системной энтропии, и поэтому производит только медленный поток данных. /dev/urandom менее безопасен и более быстр, но он все же ориентирован на небольшие фрагменты данных — он не предназначен для обеспечения непрерывного потока высокоскоростных случайных чисел. Вам следует создать ГПСЧ собственной конструкции и определить его чем-то из /dev/random или /dev/urandom. Если вам нужно немного больше случайных чисел, определяйте их периодически — каждые несколько мегабайт (или любой длины вашего ГПСЧ). Получение 4 байт (32-битное значение) из urandom или random достаточно быстро, чтобы вы могли делать это каждые 1к данных (заново определяя свой prng каждые 1к) и получать случайные результаты, при этом работая очень-очень быстро.
Ответ 5
На практике, вероятно, нет необходимости заполнять диск одним непрерывным случайным потоком. Можно создать скромный по размеру фрагмент случайных данных, а затем просто повторять его снова и снова по всему диску. Только убедитесь, что размер этого куска данных не кратен обычному размеру блока диска, чтобы в итоге не переписать коррелированные блоки данных одним и тем же куском случайных данных. Размер куска, который является простым числом в диапазоне ~1 МБ, должен быть достаточно большим. Для дополнительной безопасности проделайте это еще несколько раз, используя каждый раз разный размер блока.
Ответ 6
Утилита «shred» проста и быстра. Если SMART-атрибуты диска указывают на отсутствие перераспределенных секторов, утилита «shred», скорее всего, достаточно безопасна.
Однако, если на диске есть перераспределенные сектора, данные на поврежденных секторах не будут перезаписаны. Если поврежденные участки содержали конфиденциальные данные до их перераспределения, «shred» может оказаться недостаточно безопасным. «Плохие» сектора можно прочитать, сбросив карту распределения диска и (повторно) прочитав их. Возможность сброса карты распределения «плохих» секторов зависит от производителя и модели диска.
Linux