id: Гость   вход   регистрация
текущее время 22:36 28/03/2024
Автор темы: Гость, тема открыта 05/04/2015 19:27 Печать
Категории: инфобезопасность, защита дисков
создать
просмотр
ссылки

Шифрование дискет


Похоже что для шифрования дискет LUKS не подходит, т.к. его заголовок больше доступного дискового пространства 1.44 МБ. cryptsetup luksFormat работает без предупреждений, но luksOpen выдаёт сообщение о нехватке места. Можно ли уменьшить размер заголовка? Среди штатных опций такой возможности не обнаружил.


Если LUKS не подходит, какие другие варианты лучше соответствуют – EncFS, ecryptfs, loop-aes? В идеале безсигнатурное шифрование, хотя сомневаюсь что существует удобное решение, поэтому такое условие не обязательно.


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Гость (06/04/2015 11:32)   <#>
Называется hashalot

Когда cryptsetup был shell-скриптом, а не C-программой, уже тогда напрямую вызывать hashalot не требовалось, т.к. они с dmsetup автоматически вызывались из скрипта. Современные версии cryptsetup тоже умеют читать пароль с терминала и хешировать.

Возник лишь вопрос – если по умолчанию используется ripemd160 или sha1, как 160-битный хеш дополняется до 256-битного ключа.

Представляется что cryptsetup стал слишком сложным, как минимум с недостатками

1. Невозможность использования заголовка для носителей малой ёмкости. При том что одного 512-байтного сектора более чем достаточно для всей его информации.

2. Отсутствие алгоритма расширения ключа при бессигнатурном шифровании. Кроме PBKDF2 не предусмострено более продвинутых алгоритмов как scrypt, не уязвимых к распараллеливанию.

3. Ключ хранится в хрупком виде, размазанный по мегабайтному заголовку, что увеличивает уязвимость к дефектам диска, повышая вероятность утери ключа. Мастер-ключ вообще дублируется в заголовке?

Про навороты со слотами даже не упоминаю и зачем нужен весь этот enterprise.
Назревает необходимость в лайт-версии, устраняющей эти пункты, более универсальной и надёжной. Включающей также промежуточное решение с шифрованием LUKS заголовка для бессигнатурного применения. Сначала расшифровывается заголовок, а потом уже сам диск. Параметры шифрования заголовка можно жёстко задать в опциях компиляции или заголовочном файле исходника, с возможностью их автоматического определения путём перебора возможных вариантов (их не так много). Пусть промежуточное шифрование заголовка будет слабей, но это лучше чем его полное отсутствие.

300р флешка стоит. 8гб – 500р.

Давно не видел в продаже флешек на 1 ГБ. В основном продаются 16 ГБ за 1-1.5 т.р. Даже если бы были, всё равно стоили бы в десять раз дороже дискет и без гарантии затирания данных.
— unknown (06/04/2015 12:00, исправлен 06/04/2015 12:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Историческая справка: hashalot остался с тех времён, когда для дискового шифрования ещё не было создано cryptsetup/dmcrypt, а был только losetup с непродвинутой реализацией криптографии.



  1. Оно делалось под LVM/RAID и прочее. Возможность шифровать простые устройства оставлена. В особо тяжёлых случаях можно использовать без LUKS.
  2. Бессигнатурку авторы не хотят. Scrypt и прочие замены PBKDF2 планируются, но не в приоритете и можно прождать n лет.
  3. Anti-forensic stripe. Это не бага, это фича.


Пишите форк для себя, под эти свои узкие потребности, сами его поддерживайте. Маловероятно, что вам удасться убедить разработчиков в штатной необходимости всего этого.

— Гость (06/04/2015 21:18)   <#>
Anti-forensic stripe. Это не бага, это фича.

Могли бы оставить возможность отключить её когда не нужна.
— SATtva (06/04/2015 22:33)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Опции тоже не нужны. "There is only one mode and it secure". ©
— unknown (06/04/2015 22:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

По идее — да. Если бы там зафиксировали на данный момент, как самый оптимальный из безопасных вариантов -c aes-xts-plain64 -s 512 -h sha512. Но даже то, что там стоит дефолтное и не самое актуальное — вполне секьюрно.
— Гость (07/04/2015 02:26)   <#>

Запоминать, запоминать. Заодно отпадает необходимость использовать KDF.


Выше уже написали, но всё-таки добавлю: почитайте man cryptsetup на предмет того, как там организована plain mode, и обратите внимание на опцию -h. Если -h указано, то ключ будет хэшем пароля.


Я бы не был столь категоричен, но с основной мыслью согласен: дискета дешёвая и уничтожается легко (например, выбрасыванием в печь). Я не знаю, как с надёжностью записи на дискеты. По-моему, слишком не очень, даже если дискета чистая или писали на неё мало. Сколько было проблем, когда дискета не читается вообще или на каком-то конкретном дисководе — не счесть.


Unknown, как всегда, палится на мелочах. «--create /dev/mapper[шифрустройство]» работать не будет. Во-первых, create — команда, а не опция, поэтому пишется без двойного минуса. Во-вторых, аргументом create выступает имя нового устройства, а не имя вместе с полным путём к нему, поэтому я сомневаюсь, что полный путь будет принят и правильно понят. В конце комментария есть правильные команды.


Всё-таки 39, а не 43.


Если пароль сам по себе достаточно стойкий, то хэширования достаточно. В plain mode cryptsetup'а оно есть.


Абсолютно несущественно. KDF запускается лишь один раз перед открытием контейнера, чтобы получить мастер-ключ из пароля. Отработает этот KDF за секунду или за доли секунды — разницы нет. Вот если бы вы брутер писали к контейнеру с забытым паролем, было бы другое дело.


Как быстро уничтожить пластмасску с влитой в неё электроникой? Вспомнилось:

Можно консервативно считать, что MicroSD-карта разжевывается за одну минуту (попробуйте надосуге), но SD-карту вы уже не разжуёте.


В организациях, где технику не списывают и вовремя весь парк компьютеров не обновляют, дисководы будут существовать ещё 15 лет.


+1


Эти вопросы тут обсуждались ранее, готового ответа у меня нет. Возможно, если режим требует строго 256 бит ключа, а в качестве хэша указан тот, который даёт меньше, cryptsetup будет выдавать ошибку (но это всё надо проверять). В мануале есть тумманный намёк

If "plain" is used as argument to --hash, the input data will not be hashed. Instead, it will be zero padded (if shorter than the key size) or truncated (if longer than the key size) and used directly as the binary key. This is useful for directly specifying a binary key. No warning will be given if the amount of data read from stdin is less than the key size.

но он касается случая, когда хэширование не используется вообще. Может быть, и при хэшировании недостаток просто заполняется нулями. У меня у самого был вопрос на подобную тему, который так и остался неотвеченным:

Когда мы подаем файл с параметром -d в режиме plain, его первые S бит (S — длина ключа, заданная нами с помощью -s) используются в качестве ключа без каких-либо преобразований, поэтому указание хэш-функции просто игнорируется. (Поэтому требования к качеству ключевого файла для plain mode очень высоки; если хочется использовать большой файл с низкой энтропией, нужно использовать stdin.)

Правильное замечание. Мои примеры изначально были с stdin, и там хэширование может быть использовано (как и для ввода с терминала). Вообще, если вспомнить про применение бессигнатурного шифрования (plain mode), нужно отметить, что хэширования вы не избежите хотя бы по той простой причине, что вы не можете (быстро и легко без промежуточных шагов) ввести в качестве пароля бинарный мастер-ключ — попросту не все символы в случайном мастер-ключе печатные. Тут будет естественный выход — помнить достаточное (по энтропии) количество печатных символов, которые потом будут сконвертированы в хэш и отданы на вход в LUKS. Надеюсь, когда в man cryptsetup пишут про хэширование, имеется в виду, что хэш может быть бинарным (а не только base64, каким мы его всегда видим), иначе было бы совсем плохо.

Я так и не понял, как printable-хэши превращаются в бинарные ключи. Для хэшей предусмотрена перекодировка в бинарный вывод с алфавитом длиной 256 символов? Не все из них печатные ASCII-символы.


Заголовок можно руками сделать. В plain mode указываете первые сколько-то байт блочного устройства как отображаемые шифрованием в нечто иное. Вроде это должно делаться добавлением одной-единственной опции: отобразить расшифрованием только первые 512 байт — это -b 1, судя по man cryptsetup. Далее отображённое расшифрованное устройство можно использовать как ключ для расшифрования остальной его части. Мне лень тщательно это обдумывать и перепроверять, поэтому могут быть ошибки. Команды примерно такие:
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 \
  -b 1 create MY_HEADER /dev/fd[устройство]
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 \
  -o 1 -d /dev/mapper/MY_HEADER create MY_DEVICE /dev/fd[устройство]
Возможно, надо сделать ещё тоньше и учесть опцию -p, выделив под IV отдельный сектор (например, второй), таким образом отведя под заголовок первые два сектора, а основное устройство использовать начиная с третьего сектора. Мне необходимость игр с -p плохо понятна.


Как зачем? Чтобы менять пассфразы на криптотом без его перешифровки, а также безопасно и быстро удалять с него информацию, затирая шифрованный мастер-ключ (luksKillSlot).


У меня есть подозрение, что это легко делается простейшим скриптом, используя некоторые опции cryptsetup (наподобие того, как я написал это выше). Это не будет в полной мере отрицаемым шифрованием в том смысле, в каком оно могло бы быть, но, тем не менее. Если вас интересуют эти вопросы, читайте разбор полётов с предложением в конце, которое было признано даже unknown'ом.
— Гость (08/04/2015 22:05)   <#>
Запоминать, запоминать. Заодно отпадает необходимость использовать KDF.

Ради дополнительных нескольких символов пароля усложнять действительно не стоит. Но KDF всё-равно была бы полезной.

Я не знаю, как с надёжностью записи на дискеты.

Приемлемо, зависит ещё от качества и производителя дискеты. Хранить данные на дискетах нужно хотя бы в двух экземплярах.

Возможно, если режим требует строго 256 бит ключа, а в качестве хэша указан тот, который даёт меньше, cryptsetup будет выдавать ошибку

Ошибку не выдаёт, а дополняет хеш чем-то до нужной длины, и это не нули. Например, в случае sha1 первые 20 символов ключа совпадают с выводом sha1sum пароля, но происхождение оставшихся 12 симоволов неясно.

как printable-хэши превращаются в бинарные ключи

Насколько понял, хеш при выводе раскаповывает двоичную строку в hex-код, cryptsetup заполняет им соответствующее поле таблицы, составляемой для dmsetup, а последний обратно упаковывает в двоичный код при передаче модулю ядра.

Чтобы менять пассфразы на криптотом без его перешифровки

Для этого достаточно одного слота.
— Гость (09/04/2015 02:04)   <#>

В припципе, да, такое поведение было бы логичным. Благодаря вашему пояснению до меня только сейчас дошло, почему вывод хэша именно в шестнадцатеричном формате идёт — это же по сути и есть побайтовый вывод вида «два символа на байт». В связи с тем, что новые хэши очень длинные, было бы удобно конвертировать этот вывод в алфавит из печатных ASCII-символов, чтобы он стал покороче, и сравнивать было проще.


Да, но это смотря как менять. В том случае, который описан по ссылке, нужно минимум 2 слота: тот, который хранит старый пароль и тот, который хранит новый. Когда новый надёжно запомнился, старый можно уничтожать.
— unknown (09/04/2015 09:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Обычно вручную это никто не сравнивает:
— Гость (09/04/2015 12:14)   <#>

Если у меня на диске откуда-то взялись (возможно) одинаковые файлы, которые я хочу проверить на предмет идентичности, как это правильно делать? Можно вручную не сравнивать, но это опять грозит скриптомесевом же.
— Гость (09/04/2015 12:16)   <#>
Впрочем, возможно, вот этого достаточно:
$ sha512sum file1 file2 > file.sha512
$ sha512sum -c file.sha512
— SATtva (09/04/2015 12:22)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
sha1sum test1 | echo `cut -d' ' -f1`"  test2" | sha1sum -c
— Гость (09/04/2015 12:38)   <#>

Дискета-то точно с гарантией.. даже тогда когда это не нужно.
— Гость (09/04/2015 12:46)   <#>

Не работает:
$ sha1sum test1 | echo `cut -d' ' -f1`"  test2" | sha1sum -c
cut: -: Input/output error
sha1sum: standard input: no properly formatted SHA1 checksum lines found
Можно как-то так:
$ (sha1sum test1 && sha1sum test2) | sed 's/ .*$//' | uniq -c
      2 ce3af7760f1289d02bf6a7ad19f3214c4e5c7c2e
$ (sha1sum test1 && sha1sum test2) | sed 's/ .*$//' | uniq -c
      1 ce3af7760f1289d02bf6a7ad19f3214c4e5c7c2e
      1 d2e2cbd035bb5d677ce8eec983ac04a168bfad3f
В первом случае файлы одинаковые, во втором — нет. Вместо uniq -c можно просто число строк считать через wc -l. Вместо sed можно писать cut -f 1 -d ' '.


Выше по треду автору именно это и хотели тактично сказать, но он ответил, что двух дискет (с одной копией т.е.) достаточно.
— Гость (09/04/2015 12:52)   <#>

Недостаточно. Оно было бы так, если б файл file.sha512 формировался откуда-то извне. А в этом случае ответ будет всегда ОК, и это тривиально.


Хотелось бы проверять как-то удобно типа
$ ./checkifthesame file1 file2
чтобы не набирать каждый раз это всё (визуально быстрее сверишь, чем наберёшь все эти команды). В общем, по-любому придётся скрипт писать. В случае коротких файлов проще пользоваться diff'ом, но вот для гигабайтных...
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3