rm -rf

> Есть идеи как это все ускорить ? :)

ну он видимо не сплошной поток 1:1 из urand берет а лишь кусочками.

// wbr

>>Пошли третьи сутки зачистки...

о_0

>ну он видимо не сплошной поток 1:1 из urand берет а лишь кусочками.

Об этом я не подумал... Попробую тогда сейчас прервать dd и посмотреть за сколько справится shred -n1 /dev/hdb потому как это не серьезно мне потом еще два винта по 200Gb зачищать :)

удалить диск, создать диск

s/urandom/zero/

>удалить диск, создать диск
Это не серьезно. Таблицу mbr даже я руками реконструирую.

>s/urandom/zero/

Дык вроде на lor же рассказывали страшные истории что все равно дескать остается намагниченность которую с помощью страшных и секретных комплексов можно прочитать и что нужно не в коем случае забивать не нулями а rnd.

andrey@silverblood (~)$ time dd if=/dev/urandom of=test bs=4096 count=1024
1024+0 входных записей
1024+0 выходных записей

real    0m1.180s
user    0m0.011s
sys     0m1.059s
andrey@silverblood (~)$ time dd if=/dev/zero of=test bs=4096 count=1024   
1024+0 входных записей
1024+0 выходных записей

real    0m0.035s
user    0m0.009s
sys     0m0.020s
andrey@silverblood (~)$ 

а зачем для очистки urandom?

>> удалить диск, создать диск
> Это не серьезно. Таблицу mbr даже я руками реконструирую.

по всей видимости, имелось ввиду физическое удаление диска в астрал.

// wbr

>Дык вроде на lor же рассказывали страшные истории что все равно дескать остается намагниченность которую с помощью страшных и секретных комплексов можно прочитать и что нужно не в коем случае забивать не нулями а rnd.

а еще на лоре доказывали существование торсионных полей....

ЗЫ у тя там шо - деццкое порно?

>Есть идеи как это все ускорить ? :)

равноускоренный бросок винта в сторону апстенки

>по всей видимости, имелось ввиду физическое удаление диска в астрал.

а потом создать его ? из пыли и пены ?

>у тя там шо - деццкое порно?

Угу 3 * 200Gb...

>и что нужно не в коем случае забивать не нулями а rnd.

а если забивать ff? Прочесть можно будет только с помощью сканирующего электронного микроскопа

что-то мне подсказывает отсутсвие DMA

По американским стандртам безоспасности вообще надо по несколько раз затирать.

Шесть раз.

а зачем bs=4096?

это ж кусками его трет, т.е. на 4 килобайта идет операция i/o + sync

Паранойя, паранойя - интересная игра.

Не майся дурью, используй /dev/zero

>Есть идеи как это все ускорить ? :)

Тормозит, очевидно, urandom. Так что создаём сектор или блок со случайным содержимым и массово размножаем его. Если всё будет правильно, 200Гб перезапишется часа за полтора. Потом можно повторить с иным набором случайных данных.

отформатируй под dm-crypt

А что мешает создать файл размером в 100 метров с шумом и размножить его до полной забивки ФС? Ну не так надежно, конечно, но вообще сойдет.

>это ж кусками его трет, т.е. на 4 килобайта идет операция i/o + sync

Может потому что http://www.gnuplanet.ru/main/topic.php?topic_id=1521 но вроде таких винтов еще нет или есть ?

>Дык вроде на lor же рассказывали страшные истории что все равно дескать остается намагниченность которую с помощью страшных и секретных комплексов можно прочитать и что нужно не в коем случае забивать не нулями а rnd.

если у вас такая ситуация, что возможно использование этих комлексов, то заодно
необходимо приобретать резистанс к термо*ым методам криптоанализа)

> bs=4096

А что ж ты хотел с таким bs? :) Надо примерно в 10 раз больше ставить для дисков.

сделать cat /dev/zero и зашифровать поток симметричным шифром через openssl. Будут случайные биты со скоростью сравнимой со скоростью диска

ну или kernel-space аналог -- сделать шифрованный блочный девайс (cryptoloop в линукс или cgd в netbsd) и забить нулями -- на диске будут случайные биты

> Дык вроде на lor же рассказывали страшные истории что все равно дескать остается намагниченность которую с помощью страшных и секретных комплексов можно прочитат

вообще нельзя допускать чтобы секретная информация касалась диска в нешифрованном виде

>>Дык вроде на lor же рассказывали страшные истории что все равно дескать остается намагниченность которую с помощью страшных и секретных комплексов можно прочитать и что нужно не в коем случае забивать не нулями а rnd.

>если у вас такая ситуация, что возможно использование этих комлексов, то заодно необходимо приобретать резистанс к термо*ым методам криптоанализа)

Не стоит путать структуры.

Те, что с нагревателем - не владеют этими комплексами, верно и обратное =)

Может пора прекращать принимать такие вещества?

Смотря что на винте. Если какойнить конфидент конторный, то залить один раз из /dev/zero, сункнуть и забить нахрен. Ибо восстановление по остаточной намагниченности дело дорогое.

Если там проекты 0-портала и бомбы на антивеществе, то лучше спалить, или обратится к соответвтующим вашей местности стандартам )

В кратце - пишем нулями, считвыаем, что записалось корректно, пишем единицами, считываем что записалось корректно, пишем предварительно сформированную случайную последовательность, с текущей проверкой , а пишем инверсию той случайной последовательности, опять же с проверкой.

А вообще надо писать конфидент в шифрованные разделы, и йузать шифрованный свап. И желательно в виртуалке. Тогда можно будет просто делать dd if=/dev/zero of=/раздел/с/конфидентом и все дела )

Вообщем shred -n1 /dev/hdb отработал за несколько часов (не более 4), точнее не скажу ибо не запускал time.

>А вообще надо писать конфидент в шифрованные разделы, и йузать шифрованный свап. И желательно в виртуалке. Тогда можно будет просто делать dd if=/dev/zero of=/раздел/с/конфидентом и все дела )

В чём разница? Если есть мега-способ читать несколько предыдущих значений байта, то его и тут применят. Шифрование, понятно, поможет, но однократное затирание никак не спасёт.

Ну так шифрование и поможет :)
Будет утрачена всякая мыслимая возможность восстановления. Ибо произвести какой либо криптоанализ над остаточными данными будет ~невозможно даже теоретически.

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

Если же вообще забить, и йузать только rm -rf, то остается шанс, что остатки информации выйдут за пределы разделов предназначенных для работы с защищенной информацией, или же по некоторым причинам останутся в "свободных" инодах фс. Тогда возможен вменяемый софтовый способ извлечения инфы.

Можно ускорить, гоня в urandom энтропию с какого-то аппаратного датчика. В зависимости от секретности, соответственно, вид датчика варьируется от пердящего микрофона, пишущего шумы с радио до специальных дорогих железок.

Примеры: http://www.vanheusden.com/aed/ и там по ссылкам

> Можно ускорить, гоня в urandom энтропию с какого-то аппаратного датчика.

ты не понял сути проблемы. Топикстартер использует urandom (а не random). urandom невозможно ускорить гоня энтропию. urandom всегда работает с максимальной скоростью. Просто urandom пытается генерировать слишком качественные случайные биты

Проверил еще раз. На 200Gb shred -n1 /dev/hdb отрабатывает за 160 минут те 2 часа 40 минут.