"Вечное" выолпнение dd if=/dev/urandom of=/dev/sdX
Решил переформатировать HDD в криптованный диск для бэкапов.
Следуя советам, данным на форуме, для перезаписи данных на диске дал команду:
Сначала думал сделать что-то типа или , но что-то подумалось мне, что это делается на текущую mount point, и – не знаю, прав я или нет, но мне показалось, что дать команду на раздел безопаснее.
И вот уже полсуток продолжается работа dd и нет ей ни конца, ни краю... Причем, sfill по одному разу или по два раза, имхо, давно бы уже прошла вся (обычно на такой же объем уходило неск. часов, но не полсуток, если конечно не делать sfill без аргументов -l или -ll, когда оно будет 30 с гаком раз перезаписывать.
И только сейчас сообразил, что /dev/urandom генерит данные постоянно, это же не клонирование с диска на диск, если его не остановить, то он будет делать это вечно, или пока компьютер/диск не сломаются :)
Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".
Как правильно определить/задать время для данной работы?
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?
Я посмотрел, это разные устройства, а не ссылки одного на другого. Согласно манам, /dev/random генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?
комментариев: 11558 документов: 1036 редакций: 4118
Наоборот.
Второе.
комментариев: 9796 документов: 488 редакций: 5664
Хотелось бы вернуться к обсуждению "Как быстро заполнить раздел/том случайными данными в Unix, чтобы подготовить его к шифрованию?".
И предложить чуть более удобный вариант:
Что это даёт: никаких сигнатур, расшифровывается в любом Linux.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Это не полная инструкция, а частный вопрос, поэтому навязывание LVM и бессигнатурное шифрование решено исключить.
P.S. Есть идея собрать "продвинутые методы использования cryptsetup и пр." в один раздел, по аналогии с Tor.
Пока есть три наработки, при чём это не велосипеды и не костыли, а чуть допиленные стандартные (хотя и малораспространённые) решения:
Все эти варианты:
Если у кого-то уклон больше на сокрытие и бессигнатурное шифрование, то приветствуется публикация своих инструкций для совместного развития.
комментариев: 11558 документов: 1036 редакций: 4118
Это модуль ядра ENCRYPTED_KEYS?
комментариев: 9796 документов: 488 редакций: 5664
Да, оно:
Это всё понятно. Как появится время добразобраться, напишу инструкцию, хотя на уровне proof of concept уже сейчас очевидно, что это будет работать. Ряд извращений с device mapper уже тестировался.
комментариев: 9796 документов: 488 редакций: 5664
Как-то натыкался, что если например в 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 хуже LUKS, кроме как удобства «воткнул диск —
и сразу рути оно автоматически распозналось»? Всё, как всегда, упирается во всё то же:Честному человеку нечего скрывать!
комментариев: 9796 документов: 488 редакций: 5664
Контрольные суммы пакетов, в GnuPG они называются MDC. Если к файлу из /dev/urandom дописать заголовок GnuPG, то GnuPG пишет, что в файле непонятный формат пакетов. Если вернуть заголовок настоящему файлу, то даже при неправильно введённом пароле он напишет, что пакеты MDC есть, но они битые.
Сам шифртекст может и не быть случайным. Поверх шифрования ("снаружи") м.б. слой коррекции ошибок или ещё какая вспомогательная информация. Например, чисто умозрительно, идут рэндомные блоки IV1, IV2, C1 а затем IV3 = Hash( IV1 || IV2 || C1 ), затем IV3, IV4, C2 и т.д. с целью защиты от каких-нибудь ошибок или манипуляций. По отдельности случайно, а вместе — нет. В недисковом шифровании такая избыточность может встречаться.
В том то и дело, что нужно, иначе при отключенном IV один и тот же пароль будет давать всегда одинаковый шифртекст, да и сам пароль в этом методе должен быть стойким. В отличие от метода с cryptsetup, где можно использовать известный противнику пароль
Напугали же. Теперь все боятся полагаться на какую-либо внешнюю программу.
Она, помимо всего прочего, может оказаться ненамного быстрее dd if=/dev/urandom и уж всяко не быстрее шифрования нулей самим cryptsetup.
Просто, использование только самого cryptsetup: