"Вечное" выолпнение dd if=/dev/urandom of=/dev/sdX
Решил переформатировать HDD в криптованный диск для бэкапов.
Следуя советам, данным на форуме, для перезаписи данных на диске дал команду:
[code]dd if=/dev/urandom of=/dev/sdX[/code]
Сначала думал сделать что-то типа [code]sfill -vl[/code] или [code]sfill -vll[/code], но что-то подумалось мне, что это делается на текущую mount point, и – не знаю, прав я или нет, но мне показалось, что дать команду на раздел безопаснее.
И вот уже полсуток продолжается работа dd и нет ей ни конца, ни краю... Причем, sfill по одному разу или по два раза, имхо, давно бы уже прошла вся (обычно на такой же объем уходило неск. часов, но не полсуток, если конечно не делать sfill без аргументов -l или -ll, когда оно будет 30 с гаком раз перезаписывать.
И только сейчас сообразил, что /dev/urandom генерит данные постоянно, это же не клонирование с диска на диск, если его не остановить, то он будет делать это вечно, или пока компьютер/диск не сломаются :)
Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".
Как правильно определить/задать время для данной работы?
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?
Я посмотрел, это разные устройства, а не ссылки одного на другого. Согласно манам, /dev/random генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?
Ссылки
[link1] https://www.pgpru.com/faq/zaschitadiska#h42-15
[link2] https://www.pgpru.com/comment39692
[link3] https://www.pgpru.com/comment45000
[link4] https://www.pgpru.com/comment44983
[link5] https://www.pgpru.com/comment39520
[link6] https://www.pgpru.com/comment44127
[link7] https://www.pgpru.com/biblioteka/rukovodstva/setevajaanonimnostj/prodvinutoeispoljzovanietorvunix
[link8] https://www.pgpru.com/comment37398
[link9] https://www.pgpru.com/comment57499
[link10] https://en.wikipedia.org/wiki/Internet_exchange_point
[link11] https://www.pgpru.com/comment57746
Блин, прервал его, написало, что скопировано только 93 Гб, пришлось снова начать, ппц почему так долго? и видимо начнет по новой писать с первых секторов?
Размер буфера /dev/random фиксирован, его можно посмотреть в /proc/sys/kernel/random. Если он не слинкован с аппаратным генератором энтропии, то по исчерпании этой энтропии, он ждёт наполнения её из буфера. Предположим, что для этого нужно в течении минуты непрерывно печатать на клавиатуре, а размер буфера — 4096 байт. Тогда для заполнения 300 Гигабайт уйдёт (300 * 230 )/ (2 12) = 78643200 заполнений буфера. В году 365 * 24 * 60 = 525600 минут.
78643200 / 525600 ~ 150 лет. Печатать надо непрерывно.
Потому что, в отличие от /dev/zero, это ГПСЧ. Смотрите нагрузку процессора.
Можно начать писать с нужного оффсета: man dd, параметр seek.
А если вот так kill -USR1 `pidof dd`, то можно посмотреть сколько там, но не прерывать.
Есть конечно опция skeep.SATtva уже поправил: offsetСамый быстрый способ такой. Поднять шифрованный раздел, пароль ввести. Файловую систему не создавать. Сделать dd if=/dev/zero bs=1M of=/шифрованный_раздел
Можете bs указать побольше.
Если считать используемый шифр идеальным, то знание противником наличия на разделе в открытом тексте большого числа нулей не поможет в криптоанализе. А с нулями всё пойдёт быстрее.
На случай криптопаранойи после того, как отработается заполнение нулями, можно сменить пароль диска, стерев старый. Можно даже заголовок стереть тем же dd и заново его создать с новым паролем. Получится контейнер, снаружи заполненный случайными числами, внутри которого когда-то были нули на неизвестном пароле. Стойкость такого генератора равна по криптостойкости использованному шифру на неизвестном пароле (ключе), в режиме шифрования нулей.
Отличная идея. Если ещё и процессор имеет инструкции AES-NI, то скорость затирки будет ограничена только скоростью записи физического носителя.
SATtva, unknow
Большущее спасибо за ответы/советы.
А вот еще такой вопрос, этот hdd изначально был размечен как имеющий физический раздел /dev/sdb1, аналогичный по размеру /dev/sdb, на нем, как обычно, была ntfs.
Когда я сделал dd if=/dev/urandom of=/dev/sdb (а не dd if=/dev/urandom of=/dev/sdb1), он, конечно, уконтропупил sdb1.
Если не размечать устройство по разделам типа /dev/sdbX, создавать криптораздел непосредственно в /dev/sdb, а не в /dev/sdbX, это может как-то негативно сказаться на HDD или еще в каком-то отношении?
Или все-таки лучше поиграться с fdisk и создать /dev/sdb1? (Я не собираюсь на устройстве делать несколько разделов, мне нужен собственно только один раздел).
И второй вопрос. Очень хочется скинуть туда бэкапы и спокойно делать другие дела.
Если я сейчас (после такого завершения перезаписи данных) смонтирую криптораздел, запишу туда все, что надо, а потом натравляю на точку монтирования этого раздела sfill -vl, это разве не тот же результат будет?! Понятно, что создавать большой файл, наполняемый всяким shit, она будет на смонтированной ФС, но физически будут те же блоки юзаться, где все остальное лежит, и оно должно будет затереть все старые данные вне криптораздела, не?
А почему dd не прерывается так и показывает, что сделалось? А когда такое же делаешь,например, на tar, прерывается?
P.S. Вообще можно и скриптик написать, чтобы остановилось, когда все пройдет, видимо.
Потому что каждая программа вольна по-своему трактовать специальные сигналы. Иногда они описаны в мане.
Для dd? Он сам остановится, когда либо а) дойдёт до конца дискового раздела, либо б) запишет заданное число байт (параметры count, bs и др.).
Кстати, затирать ещё можно используя shred.
Нет, во всяком случае не при "затирке".
В данном случае это будет зависеть ещё и от самой ФС. Если ФС журналируемая, то на это полагаться 100% не стоит.
Мой штатный телепат предполагет, что скорость записи у этого диска около 80-90 Мб/сек, поэтому однократное затирание должно быть сделано примерно за час.
Да, название программы kill сбивает очень многих :)
То есть, а) касается не только устройства которое if, но и то, которое of? Значит, это я зря испугался, что будет писаться постоянно, пока /dev/urandom генерит псевдослучайные числа.
Затираемые старые данные были под nffs, которую я снес и на место которой я ставлю ext3 под крипторазделом.
Как я понимаю, криптораздел в процессе эксплуатации затирать нет особой необходимости, так как он создается для того, чтобы противник изначально не имел к нему доступа.
Файлы или разделы? Если shred на раздел натравить, разве он просто не удалит файл устройства /dev/sdX?!
Я имел ввиду, при функционировании устройства?
Почему-то почти за 12 часов затерлось из /dev/urandom только треть диска...
Вот сейчас по методике unknown из /dev/zero – скорость всего 2 Мб/с.
(Тут надо иметь ввиду, что это внешний HDD, подключенный через USB).
Ааа, просто я дебил! Я забыл задать bs=1M. Сейчас с bs=1M скорость правда не 80 – 90 Мб/с, но половину от этого.
А если сделать bs=1G? Или чем больше блок, тем хуже затираются старые данные?
И еще такой вопрос, согласно man dd
Если же задано просто bs, то seek берет за основу bs, поскольку согласно мануалу "данная опция перекрывает опции ibs и obs? Или нет?
По умолчанию shred просто затирает указанный файл, который может быть и блочным устройством. Для удаления нужно ещё ключ -u указать, но я не знаю, что он сделает в случае, если затираемый файл – болчное устройство.
sfill работает с примонтированными ФС и не затрёт блоки, которые ext3 отвела "под себя". В лучшем случае они будут затёрты однократно при форматировании раздела в ext3, в худшем – не перезаписаны ни разу.
Здесь проблем не будет.
Тогда больше 30 Мб/сек не получить никак. По крайней мере, не на USB 2.0. Промерьте скорость чтения/записи тем же dd, если она сильно ниже, то для начала попробуйте заменить usb-кабель.
А, ну вот всё и выяснилось.
dd сохраняет весь блок в памяти, а потом сбрасывает его на диск, т.е. это просто такой самопальный кэш. Больше десятка мегабайт ставить никакого смысла нет, скорость уже не вырастет. А уж если вы ещё и превысите объем доступной памяти, то это блок будет вообще в своп сбрасываться :)
Вообще давно назрело[link1].
А почему флешки и внешние HDD всегда выглядят как минимум как устройства sdX с как минимум одним разделом sdX1?
Или это чисто виндовые "примочки", которые мы так видим под линуксом?!
В смысле вновь приобретенные, неформатированные пользователем.
Их обычно форматируют на заводе.
Не понял, это я ступил не прочитал (вроде ночью этого не было,если я не слепой и не тупой), или это ты дополнил после сегодняшнего моего постинга?
Я это понимаю. Я имею ввиду, какую цель они преследуют, создавая раздел типа /dev/sdX1, равный размеру диска/флешки? Если можно просто /dev/sdX юзать в этих случаях?
После. Иначе сразу бы дал ссылку.
Какие-то версии винды вроде-бы от такого тупили и не могли увидеть флэшак. А юзерам приходилось набирать страшные команды в страшной виндовой консоли со страшным виндовым fdisk'ом. И они от такого тоже тупили. Поэтому производители решили, что лучше форматить по стандарту.
Большущее пасибо! А я почему-то думал, что такой раздел есть, и вчера ночью его усиленно искал, и не нашел.
Значит, все-таки <a href="http://www.pgpru.com/forum/sod.....Comment44113">ресурс не загибается</a> :-)
Я же говорю, назрело :-)
Да, старые версии Windows иначе их не опознавали.
Кстати, обсуждалось отсюда[link2] и ниже по треду.
Терабайтовый диск. Полевые условия. Затирать его долго, приходиться отключаться.
Как правильно начать с того места, с которого еще не записано, при каждом очередном включении затирки?
?
А counts_of_blocks соответствует "записей написано" из вывода:
полученного с помощью ?
Ну в man dd же написано как offset задавать. Можете для пущей убедительности записать фиксированные байты в нужное место, а потом считать их, чтобы проверить, что всё работает правильно.
Что-то не могу найти в man dd опцию offset
Debian Squeeze
Никто не говорил про опцию offset. Смещение задаётся следующими параметрами (для входного и выходного файлов):
Так надо использовать, как я понимаю, skip, а не seek – какой прок давать seek для /dev/urandom или /dev/zero? Или все-таки обе?
И, соответственно, надо явно определять параметры ibs и obs или, при их равенстве, достаточно определить bs?
Наоборот.
Второе.
Хотелось бы вернуться к обсуждению "Как быстро заполнить раздел/том случайными данными в Unix, чтобы подготовить его к шифрованию?[link1]".
И предложить чуть более удобный вариант:
Вариант имеет ряд сущностных ограничений.
Что это даёт: никаких сигнатур, расшифровывается в любом Linux.
В огороде бузина, в Киеве — дядька.
Не, ну если таблица разделов не смущает, то вперёд. А если смущает, то прийдётся дядьке бузину поесть.
Точнее, если в Linux можно работать непосредственно с /dev/sda вместо /dev/sda{N}, то для зачистки диска методика unknown'а работать будет. Для шифрования я бы предпочёл иное, а не дефолтный метод.
Это не полная инструкция, а частный вопрос, поэтому навязывание LVM и бессигнатурное шифрование решено исключить.
P.S. Есть идея собрать "продвинутые методы использования cryptsetup и пр." в один раздел, по аналогии с Tor[link7].
Пока есть три наработки, при чём это не велосипеды и не костыли, а чуть допиленные стандартные (хотя и малораспространённые) решения:
Все эти варианты:
Если у кого-то уклон больше на сокрытие и бессигнатурное шифрование, то приветствуется публикация своих инструкций для совместного развития.
Это модуль ядра ENCRYPTED_KEYS?
Да, оно:
Не думаю. Ряд программ шифрования в UNIX сигнатур не имеют, но в LUKS это не так, потому что, как всегда, "удобство" (возможность определить что на разделе) и "незачем скрывать наличие шифрованных данных". действительно, как юзерофильные рюшечки в гноме будут определять, что раздел шифрован, если у него нет сигнатур? А тут всё юзерофильненько: всунул диск, всплыло окошко с вводом пассфразы.
Это всё понятно. Как появится время добразобраться, напишу инструкцию, хотя на уровне proof of concept уже сейчас очевидно, что это будет работать. Ряд извращений с device mapper уже тестировался.
Как-то натыкался, что если например в gnupg отрезать все заголовочные байты в самом простом симметричном шифровании, то посредством дописывания этих байтов при помощи самого gnupg можно различать такой файл от полученного из /dev/urandom. Где гарантия, что другие программы при "бессигнатурном" шифровании не сохраняют специфический формат пакетов?
Опционально могли бы сделать, как в Truecrypt. Проблемы в надёжности при смене форматов, при долговременном хранении с целью прочитать на всех последующих версиях системы, при необходимости обеспечить равнозначную стойкость к перебору по словарю, при условии, что от противника не скрыли таки факт шифрования и он заведомо знает, что это не белый шум, а контейнер и в каком он формате, проблема с управлением ключами в слотах и др.
Самый короткий способ заполнения устройства случайными данными
ABCDEF – ключ и пароль в 16-ричном виде, можно использовать $(hexdump -e '1/1 "%02x"' /dev/urandom). Для избежания несущественной ошибки в конце записи можно заменить
Вместо openssl можно использовать любую другую программу шифрующую stdin на stdout. Например gpg с отключением сжатия (хотя в начале будет двоичная pgp-сигнатура). Поточный шифр наверное будет быстрее работать.
Для отображения прогресса в более распространённом способе, описанном unknown-ом, удобна также команда mbuffer
В новых версиях cryptsetup заголовок luks вроде бы можно вынести в файл на другом устройстве (об этом писал разработчик в рассылке), поэтому в хитростях связанных с использованием dmsetup больше нет необходимости. Хотя возможно удобнее использовать cryptsetup без расширения luks с явно заданным ключом (или dmsetup с целью crypt). Ключ поместить на другой носитель и защитить паролем с помощью самописного скрипта. Тогда есть возможность самому выбрать и настроить алгоритм расширения пароля – pbkdf2, scrypt и т.п.
Если вся система на одном диске то в использовании lvm нет особого смысла, только лишнее усложнение. Таблицу разделов не создавать, всю систему зашифровать на /dev/sda, а swap, если нужен, разместить в файле (предварительно заполненном до нужного размера, например нулями), а не создавать под него раздел. Учитывая что при современных объёмах оперативной памяти он почти не используется, на производительности это не сказывается, swap нужен только для подстраховки. Если и использовать lvm для объединения дисков, то поверх их шифрования.
Всюду советуется разбивать дисковое пространство на разделы, чтобы на разных разделах были разные ФС. Это для устойчивости к сбоям ФС. Если на диске будет крутиться несколько гостевых ОС, то и файловые системы для них должны быть разными. Ну, и про стратегическое удобство на будущее не забываем.
Да, это интересно. Не помню, чтобы вы об этом писали ранее (в отличие от пунктов 1 и 2).
Потненциально в смысле «а вдруг мы что-то не учли»?
За счёт чего так получается? Информация об имеющихся сигнатурах и форматах является внешней по отношению к предложенным методам бессигнатурного шифрования. Да, такую информацию надо откуда-то брать и тщательно проверять. Или вы намекаете, что там отличие чисто криптографическое? Сам криптотекст должен быть неотличим от /dev/urandom, иначе это ненадёжное шифрование. Потенциально можно иметь формат с сигнатурами во многих местах, т.к. пространство может шифроваться кусками, каждое начало/конец которых каким-то образом отмечены (но я про такое не слышал); хотя для современных файловых систем это действительно так: при форматировании диска определённые данные записываются не только в заголовок, но и в ряд мест на файловой системе.
Обратная совместимость — фича программного функционала, а не интерфейса. Все претензии к разработчикам.
Пусть заголовок шифруется каким-то универсальным стандартным образом. Спрашиваем у пользователя пароль, расшифровываем в память этим паролем бессигнатурный заголовок (он будет неотличим от случайных данных, когда записан на диск), а далее, раз заголовок есть, делаем всё то, что и сейчас: смену ключей, алгоритмов, слоты, перешифрование ФС на лету... да всё, что угодно. Всё упирается в волевое решение разработчиков и в
Нормальное шифрование под винду с хорошими фичами тоже было "невозможно", но потом пришёл ntldr и всё сделал. Linux же пока так и не нашёл своего ntldr'а.
P.S: Вроде бы у OpenBSD'шного vnconfig и NetBSD'шного cgd сигнатур нет. Т.е. отродясь не было. Никогда. Про FreeBSD'шный geli не знаю (т.е., возможно, также). У cgd ключевой файл всегда есть и всегда внешний по отношению к ФС, хранит salt. У LUKS ограниченное количество слотов, а у cgd из одного можно нагенерить хоть миллион разных salt-файлов, где каждый будет замапплен на свою пассфразу для одного и того же криптораздела. Мастер-ключ при этом не меняется, как и в LUKS. Чем интерфейс к cgd[link8] хуже LUKS, кроме как удобства «воткнул диск —
и сразу рути оно автоматически распозналось»? Всё, как всегда, упирается во всё то же:Честному человеку нечего скрывать!
Контрольные суммы пакетов, в GnuPG они называются MDC. Если к файлу из /dev/urandom дописать заголовок GnuPG, то GnuPG пишет, что в файле непонятный формат пакетов. Если вернуть заголовок настоящему файлу, то даже при неправильно введённом пароле он напишет, что пакеты MDC есть, но они битые.
Сам шифртекст может и не быть случайным. Поверх шифрования ("снаружи") м.б. слой коррекции ошибок или ещё какая вспомогательная информация. Например, чисто умозрительно, идут рэндомные блоки IV1, IV2, C1 а затем IV3 = Hash( IV1 || IV2 || C1 ), затем IV3, IV4, C2 и т.д. с целью защиты от каких-нибудь ошибок или манипуляций. По отдельности случайно, а вместе — нет. В недисковом шифровании такая избыточность может встречаться.
В том то и дело, что нужно, иначе при отключенном IV один и тот же пароль будет давать всегда одинаковый шифртекст, да и сам пароль в этом методе должен быть стойким. В отличие от метода с cryptsetup, где можно использовать известный противнику пароль
Напугали же[link2]. Теперь все боятся полагаться на какую-либо внешнюю программу.
Она, помимо всего прочего, может оказаться ненамного быстрее dd if=/dev/urandom и уж всяко не быстрее шифрования нулей самим cryptsetup.
Просто, использование только самого cryptsetup:
В смысле, если разбить систему на пять разделов, то фс будет в пять раз устойчивей? Не производит сильного впечатления. Для устранения сбоев фс ежедневное резервное копирование намного надёжней (которое в любом случае необходимо). Если есть несколько физических дисков, тогда действительно размещение разных каталогов (/home, /var и т.д.) на разных дисках может дать заметную прибавку к скорости и надёжности. Это обычно используют на серверах, а не домашнем ПК. Про гостевые системы на виртуальной машине может вы и правы, я в них не разбираюсь.
ABCDEF – это был пример, понятно что нужно использовать произвольное число. А в чём смысл стойкости ключа при шифровании нулей – то что их расшифруют и смогут отделить используемые блоки от неиспользуемых? Это можно применить только как косвенное доказательства наличия осмысленных (ненулевых) шифрованных данных.
На моём компьютере: urandom 4.9 MB/s, openssl 51 MB/s, dmcrypt 65 MB/s. Скорость ненамного ниже, а команд вводить намного меньше. С вашими аргументами в пользу dmcrypt согласен, сам пользуюсь только им.
А в дисковом нет? Мало ли в каком проекте как реализовано...
Почему? По ссылке рассмотрен OpenSSL, про другие программы молчок.
Слом одной файловой системы не повелечёт за собой (по крайней мере, автоматически) слом других файловых систем. При инсталляции всегда советовалось использовать для /var, /tmp, /home и т.д. разные разделы и разные файловые системы (тип файловых систем может быть один — например, ext3). К примеру, у меня однажды грохнулся диск, я его понёс в сервис и там восстановили, что могли. Итог: файловая система на /usr не монтировалась, но я на неё забил, а все остальные ФС смонтировались на ура. Была бы одна ФС на весь диск — потерял бы кучу данных. Про резервное копирование согласен, но тем не менее.
Можно почти с полной уверенностью сказать, что нет. Потому что в дисковом шифровании есть жёсткое требование на необходимость равенства размеров открытого текста шифртексту. Лишние служебные заголовки внутрь самого шифртекста там уже не впихнуть.
И ещё так балансируют нагрузку у высокопроизводительных серверов, предусматривают возможность более удобного изменения разделов и др.
Если только затирать данные, которые лежали на носителе раньше, то конечно без разницы. А так, всё верно, чтобы не различали испольуемые и неиспользуемые блоки. Не только для доказательства факта шифрования, но и затруднения косвенного анализа содержимого (насколько заполнен контейнер?).
Служебные заголовки всё равно есть (хидеры того же LUKS, к примеру) вопрос лишь куда их писать. Наверно, про существование отличимости данных от случайных надо всё равно в каждом случае уточнять у авторов шифровальной программы или внимательно читать официальную полную спецификацию на неё. «Требование на необходимость равенства размеров открытого текста шифртексту» — не концептуальное, а скорее техническое. Потенциально можно как угодно реализовать, даже так, что равными не будут (встроить ту же коррекцию ошибок поверх шифротекста, например...).
Почему OpenSSL'евский ГПСЧ настолько быстрее?
Гость выше предложил[link9] вариант с mbuffers, он чем-то хуже? Там dd с обоих сторон, можно второму dd задать оффсет.
Что конкретно имелось в виду? Можно поподробнее? От cold boot attack это всё равно не спасёт, впрочем.
unknown, по вашей ссылке только список файлов на скачку, а цитаты этой нет.
В начале записи, всё ж таки(?), т.е.
Нужный скрипт можно поместить в любое свободное место на диске на том же носителе, извлекать его по dd в память и расшифровывать с помощью openssl (команду прийдётся выучить наизусть). Извлечение/подключение всего остального с диска можно запихнуть в этот скрипт и запоминать не надо.
Хоть здесь и критикуется шифрование загрузчика в grub, но там идеологически сделали как-то так, да. Пусть это не идеальная защита, но выносить загрузчик на внешний носитель после этого стало, полагаю, проще, особенно по сравнению с выносом туда ядра, корневой файловой системы, init-скриптов...
MDC можно считать частью заголовка файла? Или они принципиально по всему PGP-файлу разбросаны? Если кто-то недоизучил формат и обрезал половину заголовка, дело в обрезальщике, а не в подходе.
Как называются объекты IVk и Ck? Вектор инициализации и ещё что-то? Что означает индекс k?
Смешно признаться, но только сейчас понял, что вектор инициализации обозначают как IV, потому что Initialization Vector. Раньше я думал, что его почему-то решили обозначать римской четвёркой. Начинаю подозревать, что точки обмена интернет-трафиком (IX) — это тоже не девятки...
Действительно ли шифрование нулей с рандомно выбранным IV намного хуже того, как сейчас генерируется urandom? Если нет, то почему для генерации urandom используется не шифрование нулей, а что-то иное? Была бы скорость повыше...
Потому что он не полноценный ГПСЧ, а в приведённом примере блочный шифр AES в режиме CBC, шифрующий нули. В отличие от /dev/urandom, который на хэшах и который полноценный ГПСЧ, с непредсказуемостью влево за счёт перетирания внутренних состояний и с непредсказуемостью вправо при условии подкачки энтропии — наперёд заданной секретностью. AES-CBC с фиксированным IV, ключом и шифртекстом не имеет непредсказуемости влево или вправо, стоит только один раз восстановить ключ и вся сгенерированная им гамма восстанавливается. Но для затирания носителя или контейнера такие свойства по стойкости не нужны, поскольку атаки с утечками внутреннего состояния исключаются моделью угрозы. В отличие от /dev/urandom, к выходу которого (и отчасти входу) одновременно может иметь доступ масса пользователей, в т.ч. и недоверяемых.
См. выше про непредсказуемость влево-вправо и атаки недоверяемых пользователей, пытающихся восстановить внутренние состояния. Плюс реализация /dev/urandom исторически сложилась задолго до появления AES. Плюс для такой непредсказуемости нужно большее внутреннее состояние, чем может обеспечить AES за один проход, если всё-таки попытаться переделывать на него. Вот внедрят SHA3/Keccak и всё ускорится и упростится. И доказуемость безопасности улучшится. Или везде (кроме виртуалок?) будет быстрый аппаратный ГСЧ, как в последних версиях процов. Но в нём извечный вопрос о доверяемости к железке, хотя для затирания места подойдёт.
Хороший вариант, что-то протупил и не додумался на счёт такого очевидного решения — использовать дважды dd вместо cat, а посредине неважно что, pv или mbuffers.
Это не от этого. Хотя эти эти утилиты, кажется, могут работать и с TPM. Вообще, это самое спорное решение, потенциально снижающее безопасность в обмен на удобство, когда нужно управлять очень большим количеством шифрованных разделов (например, на RAID-массивах, подключаемых носителях). Может произойти утечка пароля в своп (маловероятно, плюс он шифрованный) или лишний процесс с правами рута может подсмотреть пароль (это всё равно компрометация системы, dmsetup --showkeys table и так покажет все ключи).
Если любопытно, откуда взялись идеи по "продвинутому" использованию cryptsetup/dmcrypt, то в Debian (в других дистрах этого может не быть) с пакетом cryptsetup, в каталоге /lib/cryptsetup/scripts ставится набор скриптов decrypt_derived, decrypt_gnupg, decrypt_keyctl, decrypt_openct, decrypt_opensc, decrypt_ssl. Их можно запихать в /etc/crypttab и/или в initrd или позаимствовать оттуда кое-какие идеи. В доках описаны примеры использования.
Из описания пакета keyutils в системе.
Ключ.
Они самые[link10], Internet EXchange Points.
Не понял зачем грузить скрипт в память. Его дело – получить из пароля ключ и передать его dmcrypt. Создаётся виртуальное шифрованное устройство и соответствующий ему ключ хранится в памяти. Скрипт может храниться где угодно, защита ключа обеспечивается стойкостью алгоритмов, а не сокрытием скрипта. Основной секрет – это пароль и он хранится в голове.
Подумалось: фишеры через n лет: «откройте терминал, сделайте
su -l rootsudo bash, введите dmsetup --showkeys table, скажите получившиеся цифры...»Мы о разных задачах с вами говорим. Я — про бессигнатурное шифрование. Цель скрипта — подмонтировать всё, что нужно (а там прийдётся область секторов на диске явно указывать и т.д.) с нужными режимами, заголовками, выводом ключей, возможностью интерактивного выбора, что подключать и т.д. Но сам скрипт надо откуда-то брать, вот его и можно записать на диск так, как я выше написал. Кроме того, один из секретов при выводе ключа — файл с солью (salt). Чтобы salt отрицаемо скрывать, лучше использовать бессигнатурное шифрование на том же (или другом) носителе, куда эта salt будет отрицаемо записана. Метод извлечения salt с диска тот же: dd в файл в память, расшифровать openssl'ем.
Чтобы было понятно, такого рода нестандартные решения нужно публиковать со списком требований: что хотим получить + зачем это нужно, достоинства. недостатки и др.
А то, те, кто с этим не сталкивался или не задумывался, не понимают, о чём речь, зачем это нужно или понимают неправильно, или относятся предвзято.
Когда будет исчерпывающий пост на тему, там будет всё: и мотивация, и список требований, и пошаговые команды. Сейчас же времени писать на эту тему развёрнутый пост нет, как и времени экспериментировать с такими методиками, из-за чего приходится ограничиваться плохо структурированными постами в тематические топики. Опытным пользователям этих обрывочных указаний, впрочем, уже достаточно, чтобы довести идею до исчерпывающего поста на тему или начать использовать метод для себя.
Прекрасно понимаю. У самого до многого руки не доходят.
2 /comment57499[link9]:
Подумалось ещё на счёт этого:
Чтобы не вспоминать тонкости режимов шифрования можно использовать только openssl enc -aes-256-cbc и задать неслучайный пароль. Вектор инициализации при этом будет случайный, а при использовании в аналогичных целях gnupg, ещё и случайный ключ, зашифрованный на пароль. После окончания можно просто затереть из /dev/urandom начало диска, куда попал заголовок.
Ещё надёжнее вообще не записывать заголовок на диск, отрезав его вторым dd:
Да, вашим способом наверное проще обеспечить стойкость шифрования.
Оказалось, что skip на STDIN не работает.
Приведённый вами пример у меня работает
«Команда выполняется без сообщений об ошибках» ≠ «работает», если что.
Вы проверяли, что skip корректно отработал?
Если бы не проверял, то не написал бы. Правда опцию skip без буквы M использовал (подумал что опечатка), может в этом загвоздка? На петлевом устройстве /dev/loop0 удобно тестировать.
Сначала у меня не сработало из-за того, что в первом dd задал ещё и count. При этом, какой бы большой count не задавать, получалось
А теперь, сравните без skip:
и со skip:
Со skip не работает второй dd и ничего не выдаёт на выход, в то время как из первого dd всё проходит через openssl и pv (или mbuffer), вот только куда?
В сообщении comment57746[link11] я уже привёл причину: вы используете букву M после количества пропускаемых блоков stdin задаваемого в skip. Это множитель 1024*1024=1048576, поэтому при bs=1M skip=4M соответствует сдвигу равному 4 терабайтам (1M x 4M = 4T). Это также объясняет вывод ошибки при задании числа блоков в 1-м dd (cannot skip to specified offset), поскольку смещение skip превышает размер stdin.
Попробуйте
Хотя мне кажется что достаточно пропустить один блок: skip=1.
Кстати, таким же способом можно очищать CD
Но только перед каждым циклом очистки нужно готовить CD для перезаписи.
На первый взгляд это работает:
Но только если не использовать count, даже со множителем.
И опять же, просто при таком выводе маскируется ошибка dd: `standard input': cannot skip to specified offset:
Можно перенаправить её в файл даже из "работающей" команды:
Похоже что эта ошибка связана с проходом потока через команду (openssl, mbuffer или др.) между двумя dd. Появляется начиная с определённого размера блока. При bs=1k и менее ошибка не появляется. Если первый dd передаёт поток напрямую второму (между ними нет команды), то ошибка отсутствует при любом размере блока, в том числе 1M и 1G. На случайность генерируемой последовательности данная ошибка видимо не влияет, может быть даже результат не искажает.
С gpg -c возникает такая же ошибка на dd, он ещё и заметно медленнее.
С другой стороны, ещё один повод задуматься, стоит ли доверять внешним командам в нестандартных вариантах использования, когда дело касается не наглядных результатов, а безопасности. Как бы такой, доведённый до абсурда Unix-way, не вышел боком. Может надёжнее всё-таки нулями в сам LUKS-контейнер? Все команды LUKS легко запомнить.
По моему в данном случае дело не в самих командах, а в наличии посредника между двумя dd, на которого реагирует опция skip. Если хотите видеть прогресс с помощью pv или mbuffer будет та же самая ошибка при задании skip, независимо от того чем будете шифровать – dmcrypt, openssl или gpg. Просто при бессигнатурном шифровании опция skip не нужна и дефект программного канала себя не проявляет.
А можно ли через dd забить рандомом неиспользуемое дисковое пространство на ext4 после обычного удаления чувствительных файлов без применения shred? И эффективно ли будет такое затирание?
С учётом современной плотности записи на диски... наверное, однократной перезаписи достаточно. Я иногда тру как dd if=/dev/zero of=/path/to/file count=999999999999999, где file — файл на файловой системе, которую надо зачистить. Не знаю, насколько это безопасно. Обычно жду, когда dd вылетит с ошибокой, жалуясь на недостаток места, и считаю, что относительно безопасно всё затёрто.
Но тут есть тонкости, типа имён вложенных директорий, которые, возможно, могут как-то остаться. Например, обычная директория занимает 4.0K при вызове как ls -lad /path/to/dir, но у меня есть директория на ext3, в которой содержалось очень много мелких файлов. После того, как я зашреддил те файлы, размер директории так и остался большим — 1.3M, хотя внутри неё пусто. В общем, чудеса. Для серьёзного затирания информации вряд ли стоит полагаться на такой метод, но, если вы отдаёте себе отчёт во всех подводных камнях, то можно.
Если файл модифицируется и размеры меняются, то его содержимое может оставаться в блоках, которые уже не связаны с данным файлом. Затирание файла с помощью dd, srm, shred и т.п. ненадёжно.
Для себя определил наиболее безопасный способ уничтожения информации с сохранением работоспособности диска:
1. Встроенная ATA-команда Secure Erase (заполняет нулями всё доступное место, а не только LBA)
2. Тройной проход dd с заполнением устройства случайными битами.
В общем-то первого пункта достаточно, второй скорее по традиции, для перестраховки. Это относится к hdd. С флешем и CD/DVD могут быть свои тонкости.
Правильный метод — не создавать на основном разделе такие файлы, которые потом позарез захочется стереть. Т.е. для таких файлов нужна отдельная файловая система, к которой будут более строгие требования безопасности — например, почти всегда держать её отмонтированной, а ключ шифрования — удалённым из оперативной памяти.