Шифрование дискет
Похоже что для шифрования дискет LUKS не подходит, т.к. его заголовок больше доступного дискового пространства 1.44 МБ. cryptsetup luksFormat работает без предупреждений, но luksOpen выдаёт сообщение о нехватке места. Можно ли уменьшить размер заголовка? Среди штатных опций такой возможности не обнаружил.
Если LUKS не подходит, какие другие варианты лучше соответствуют – EncFS, ecryptfs, loop-aes? В идеале безсигнатурное шифрование, хотя сомневаюсь что существует удобное решение, поэтому такое условие не обязательно.
Когда cryptsetup был shell-скриптом, а не C-программой, уже тогда напрямую вызывать hashalot не требовалось, т.к. они с dmsetup автоматически вызывались из скрипта. Современные версии cryptsetup тоже умеют читать пароль с терминала и хешировать.
Возник лишь вопрос – если по умолчанию используется ripemd160 или sha1, как 160-битный хеш дополняется до 256-битного ключа.
Представляется что cryptsetup стал слишком сложным, как минимум с недостатками
1. Невозможность использования заголовка для носителей малой ёмкости. При том что одного 512-байтного сектора более чем достаточно для всей его информации.
2. Отсутствие алгоритма расширения ключа при бессигнатурном шифровании. Кроме PBKDF2 не предусмострено более продвинутых алгоритмов как scrypt, не уязвимых к распараллеливанию.
3. Ключ хранится в хрупком виде, размазанный по мегабайтному заголовку, что увеличивает уязвимость к дефектам диска, повышая вероятность утери ключа. Мастер-ключ вообще дублируется в заголовке?
Про навороты со слотами даже не упоминаю и зачем нужен весь этот enterprise.
Назревает необходимость в лайт-версии, устраняющей эти пункты, более универсальной и надёжной. Включающей также промежуточное решение с шифрованием LUKS заголовка для бессигнатурного применения. Сначала расшифровывается заголовок, а потом уже сам диск. Параметры шифрования заголовка можно жёстко задать в опциях компиляции или заголовочном файле исходника, с возможностью их автоматического определения путём перебора возможных вариантов (их не так много). Пусть промежуточное шифрование заголовка будет слабей, но это лучше чем его полное отсутствие.
Давно не видел в продаже флешек на 1 ГБ. В основном продаются 16 ГБ за 1-1.5 т.р. Даже если бы были, всё равно стоили бы в десять раз дороже дискет и без гарантии затирания данных.
комментариев: 9796 документов: 488 редакций: 5664
Историческая справка: hashalot остался с тех времён, когда для дискового шифрования ещё не было создано cryptsetup/dmcrypt, а был только losetup с непродвинутой реализацией криптографии.
Пишите форк для себя, под эти свои узкие потребности, сами его поддерживайте. Маловероятно, что вам удасться убедить разработчиков в штатной необходимости всего этого.
Могли бы оставить возможность отключить её когда не нужна.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
По идее — да. Если бы там зафиксировали на данный момент, как самый оптимальный из безопасных вариантов -c aes-xts-plain64 -s 512 -h sha512. Но даже то, что там стоит дефолтное и не самое актуальное — вполне секьюрно.
Запоминать, запоминать. Заодно отпадает необходимость использовать KDF.
Выше уже написали, но всё-таки добавлю: почитайте man cryptsetup на предмет того, как там организована plain mode, и обратите внимание на опцию -h. Если -h указано, то ключ будет хэшем пароля.
Я бы не был столь категоричен, но с основной мыслью согласен: дискета дешёвая и уничтожается легко (например, выбрасыванием в печь). Я не знаю, как с надёжностью записи на дискеты. По-моему, слишком не очень, даже если дискета чистая или писали на неё мало. Сколько было проблем, когда дискета не читается вообще или на каком-то конкретном дисководе — не счесть.
Unknown, как всегда, палится на мелочах. «--create /dev/mapper[шифрустройство]» работать не будет. Во-первых, create — команда, а не опция, поэтому пишется без двойного минуса. Во-вторых, аргументом create выступает имя нового устройства, а не имя вместе с полным путём к нему, поэтому я сомневаюсь, что полный путь будет принят и правильно понят. В конце комментария есть правильные команды.
Всё-таки 39, а не 43.
Если пароль сам по себе достаточно стойкий, то хэширования достаточно. В plain mode cryptsetup'а оно есть.
Абсолютно несущественно. KDF запускается лишь один раз перед открытием контейнера, чтобы получить мастер-ключ из пароля. Отработает этот KDF за секунду или за доли секунды — разницы нет. Вот если бы вы брутер писали к контейнеру с забытым паролем, было бы другое дело.
Как быстро уничтожить пластмасску с влитой в неё электроникой? Вспомнилось:
В организациях, где технику не списывают и вовремя весь парк компьютеров не обновляют, дисководы будут существовать ещё 15 лет.
+1
Эти вопросы тут обсуждались ранее, готового ответа у меня нет. Возможно, если режим требует строго 256 бит ключа, а в качестве хэша указан тот, который даёт меньше, cryptsetup будет выдавать ошибку (но это всё надо проверять). В мануале есть тумманный намёк
но он касается случая, когда хэширование не используется вообще. Может быть, и при хэшировании недостаток просто заполняется нулями. У меня у самого был вопрос на подобную тему, который так и остался неотвеченным:
Я так и не понял, как printable-хэши превращаются в бинарные ключи. Для хэшей предусмотрена перекодировка в бинарный вывод с алфавитом длиной 256 символов? Не все из них печатные ASCII-символы.
Заголовок можно руками сделать. В plain mode указываете первые сколько-то байт блочного устройства как отображаемые шифрованием в нечто иное. Вроде это должно делаться добавлением одной-единственной опции: отобразить расшифрованием только первые 512 байт — это -b 1, судя по man cryptsetup. Далее отображённое расшифрованное устройство можно использовать как ключ для расшифрования остальной его части. Мне лень тщательно это обдумывать и перепроверять, поэтому могут быть ошибки. Команды примерно такие:
Как зачем? Чтобы менять пассфразы на криптотом без его перешифровки, а также безопасно и быстро удалять с него информацию, затирая шифрованный мастер-ключ (luksKillSlot).
У меня есть подозрение, что это легко делается простейшим скриптом, используя некоторые опции cryptsetup (наподобие того, как я написал это выше). Это не будет в полной мере отрицаемым шифрованием в том смысле, в каком оно могло бы быть, но, тем не менее. Если вас интересуют эти вопросы, читайте разбор полётов с предложением в конце, которое было признано даже unknown'ом.
Ради дополнительных нескольких символов пароля усложнять действительно не стоит. Но KDF всё-равно была бы полезной.
Приемлемо, зависит ещё от качества и производителя дискеты. Хранить данные на дискетах нужно хотя бы в двух экземплярах.
Ошибку не выдаёт, а дополняет хеш чем-то до нужной длины, и это не нули. Например, в случае sha1 первые 20 символов ключа совпадают с выводом sha1sum пароля, но происхождение оставшихся 12 симоволов неясно.
Насколько понял, хеш при выводе раскаповывает двоичную строку в hex-код, cryptsetup заполняет им соответствующее поле таблицы, составляемой для dmsetup, а последний обратно упаковывает в двоичный код при передаче модулю ядра.
Для этого достаточно одного слота.
В припципе, да, такое поведение было бы логичным. Благодаря вашему пояснению до меня только сейчас дошло, почему вывод хэша именно в шестнадцатеричном формате идёт — это же по сути и есть побайтовый вывод вида «два символа на байт». В связи с тем, что новые хэши очень длинные, было бы удобно конвертировать этот вывод в алфавит из печатных ASCII-символов, чтобы он стал покороче, и сравнивать было проще.
Да, но это смотря как менять. В том случае, который описан по ссылке, нужно минимум 2 слота: тот, который хранит старый пароль и тот, который хранит новый. Когда новый надёжно запомнился, старый можно уничтожать.
комментариев: 9796 документов: 488 редакций: 5664
Обычно вручную это никто не сравнивает:
Если у меня на диске откуда-то взялись (возможно) одинаковые файлы, которые я хочу проверить на предмет идентичности, как это правильно делать? Можно вручную не сравнивать, но это опять грозит скриптомесевом же.
комментариев: 11558 документов: 1036 редакций: 4118
Дискета-то точно с гарантией.. даже тогда когда это не нужно.
Не работает:
Выше по треду автору именно это и хотели тактично сказать, но он ответил, что двух дискет (с одной копией т.е.) достаточно.
Недостаточно. Оно было бы так, если б файл file.sha512 формировался откуда-то извне. А в этом случае ответ будет всегда ОК, и это тривиально.
Хотелось бы проверять как-то удобно типа