LINUX.ORG.RU
ФорумTalks

rm -rf


0

0

Нужно зачистить 200Gb винт. Запустил dd if=/dev/urandom of=/dev/hdb bs=4096 Пошли третьи сутки зачистки... Попробывал померять скорость выдачи /dev/urandom получается около 400Kb/s. Запустил strace на shred - он то-же /dev/urandom юзает.

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


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

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

// wbr

klalafuda ★☆☆
()

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

о_0

Id ★★
()
Ответ на: комментарий от klalafuda

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

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

xtron
() автор топика
Ответ на: комментарий от birdie

>s/urandom/zero/

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

xtron
() автор топика

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?

generatorglukoff ★★
()
Ответ на: комментарий от xtron

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

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от xtron

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

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

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

generatorglukoff ★★
()

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от klalafuda

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

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

xtron
() автор топика
Ответ на: комментарий от generatorglukoff

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

Угу 3 * 200Gb...

xtron
() автор топика
Ответ на: комментарий от xtron

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

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

DNA_Seq ★★☆☆☆
()

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

lester_dev ★★★★★
()

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

stassats ★★★★
()

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

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

blaster999 ★★
()

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

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

KRoN73 ★★★★★
()

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

anonymous
()

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

Shaman007 ★★★★★
()
Ответ на: комментарий от xtron

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

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

grimp3ur
()

> bs=4096

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

Deleted
()

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

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

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

dilmah ★★★★★
()
Ответ на: комментарий от xtron

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

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

dilmah ★★★★★
()
Ответ на: комментарий от grimp3ur

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

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

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

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

ManJak ★★★★★
()

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

anonymous
()

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

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от xtron

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

xtron
() автор топика
Ответ на: комментарий от vasily_pupkin

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

vasily_pupkin ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

dilmah ★★★★★
()
Ответ на: комментарий от xtron

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

xtron
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.