Шифрование отдельных файлов с помощью cryptsetup/LUKS

А там по ссылке трюки как раз для того и используются, что и соль есть, и помнить ничего не надо. Более того, ваш пример, судя по комментарию unknown'а крайне не рекомендуется к использованию (также см. /comment39340). Там же объяснено, почему вот так:

Тоже убирается опцией noiv, тогда будет создаваться из пароля, как в openssl.

делать не надо. И, кстати, вот ещё комментарий в тему этого обсуждения.


openssl вообще не умеет AES-256? Тут aes-256-cbc указано опцией.


Вот именно поэтому там сказана оговорка:

Ещё одна тонкость — извраты с dd. Здесь они не так сильно вылазят, потому что идёт запись в блочное устройство, размер которого не может быть изменён, но вот если бы запись делалась в файл, всё было бы тоньше.

Я поначалу ошибочно подумал, что шифрованный файл надо собирать из кусков. В этом случае эта проблема бы вылезла.


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

Start offset used in IV calculation in 512-byte sectors (how many sectors of the encrypted data to skip at the beginning). This option is only relevant for the open action with plain or loopaes device types.

Тогда зачем (см. эту цитату выше) в man cryptsetup это написано?

Плюсы и минусы mcrypt

Помимо замечания в /comment91478 у меня сложилось впечатление, что с mcrypt всё не очень хорошо, не очень надёжно, а его использование не очень рекомендуется. Возможно, всё эти представления ошибочны, когда идёт речь именно о бессигнатурном шифровании, но всё же. Сейчас прогуглил все его упоминания за время существования форума, и вот такая картина получается:

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

Это касается любого симметричного пофайлового шифрования? И openssl и mcrypt? Если так, в чём концептуальное отличие, приводящее к нераспознаваемости контейнеров TC? Non-malleability? Кто мешает таким же образом шифровать и файлы? Это было бы менее безопасным? Почему файлы шифруются не точно так же?

Это касается любого симметричного пофайлового шифрования?

Нет, только особенностей его реализаций.

И openssl и mcrypt?

Я не знаю, что они пихают в шифртекст, кроме простых заголовков.

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

Ой! А я его для серьёзных вещей юзаю с опциями типа m(de)crypt -b... unknown советовал. Разве это ещё "экспериментальный" продукт?!

Об этом речи нет. Это программа для тех, что знает, что делает. Ближе к криптобиблиотеке. То есть определённо не для среднестатистического пользователя средств шифрования.

Собственно в качестве криптобиблиотеки в некоторых программах и применяется libmcrypt.

Хотя это не такой стандарт де-факто, как openssl, который при разработке приложений стараются использовать в первую очередь.

В mcrypt опция bare по крайней мере что-то гарантирует хотя бы со слов документации. И всё равно, нужно разбираться, прежде чем например это куда-то встраивать

Т.е. вопрос в том, что лучше для бессигнатурности: создать контейнер в plain mode или использовать mcrypt? Мне первый вариант интуитивно кажется более доверяемым, т.к. это всё-таки стандартный и всюду используемый cryptsetup, написанный со знанием дела.

AES != Rijndael. У первого размер блока (не ключа) строго равен 128 битам, у второго есть вариант со 128- и 256-битовым блоком.

openssl вообще не умеет AES-256? Тут aes-256-cbc указано опцией

В AES-256 размер блока 128 бит, как тут уже ответили.

>Start offset used in IV calculation in 512-byte sectors (how many sectors of the encrypted data to skip at the beginning). This option is only relevant for the open action with plain or loopaes device types.

Тогда зачем (см. эту цитату выше) в man cryptsetup это написано?

Наверно для именения нумерации блоков, используемой ESSIV при генерации IV. В plain mode (без заголовка) пароль не шифруется, поэтому соль не нужна.

Т.е. вопрос в том, что лучше для бессигнатурности: создать контейнер в plain mode или использовать mcrypt?

На мой взгляд для шифрования одного файла лучше mcrypt, чем велосипеды с cryptsetup. Лично для меня проще стандартное действие – скачать и скомпилировать программу, чем возиться со скриптами. Если шифруется бэкап c ФС, тогда удобнее cryptsetup. По большому счёту особой разницы нет.

Так зачем пользователям cryptsetup лезть в эти тонкости криптографии? Где и зачем это может быть нужно? Может быть, Unknown опцию --skip прокомментирует? В man'е я вижу только это:

If the original device used an offset and but did not use it in IV sector calculations, you have to explicitly use --skip 0 in addition to the offset parameter.

Когда реализуется случай «did not use it in IV sector calculations»?

Так подробно же про skip написано:

--skip, -p
how many sectors of the encrypted data to skip at the beginning. This is different from the --offset options with respect to IV calculations. Using --offset will shift the IV calculation by the same negative amount. Hence, if --offset n, sector n will be the first sector on the mapping with IV 0. Using -""-skip would have resulted in sector n being the first sector also, but with IV n. This option is only relevant for create action.

В моей версии cryptsetup'а это пояснение уже убрали.

Для начала, я не знаю, что такое вектор инициализации, и чему равен его размер. Для меня, как для простого юзера, это просто внутренний параметр для шифра, который всегда как-то вычисляется автоматически и правильно. Почему вдруг в какой-то момент я должен выяснять, как он вычисляется — уже само по себе большой вопрос.


Почему negative-то? Если речь о сдвиге сектора, который будет использоваться для вычисления IV, то сдвиг как раз positive. И как из содержимого сектора вычисляется IV?


Нетривиально. Ключ вычисляется из пассфразы. Offset — это просто начиная с какого сектор блочного устройства его отмаппить в шифрованное. Как отсюда следует, что IV оказывается равным нулю?

Вроде IV=0 — это плохо. И как тогда надо делать, когда шифрование происходит не с начала устройства? Надо каждый раз писать --offset n --skip n? А когда эти параметры стоит делать разными? Или лучше делать --offset $((n+1)) --skip n? Я ничего не понял.

Это параметр режима шифрования, а не шифра.

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

Смотря для чего.

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

Бессигнатурное шифрование достигается добавлением пары опций, ничего сильно нестандартного тут нет. То, что вы лично и для себя считаете это ненужным — это ваши личные проблемы.


Для cryptsetup, где устройство шифруется не с первого сектора. Здесь в четвёртом и седьмом пунктах оффсет указан, а скип нет. Это правильно или надо фиксить?

Всецело с этим согласен.


Так это надо подумать над тем, что я считаю ненужным. И много чего написать, где это может вылезти. Попытка эмулировать скрытые разделы со смещение — первое, что приходит в голову. Я ограничиваюсь только недоказанным предупреждением, что здесь может возникнуть проблема.

Будьте добры, что означает "эмулировать стрытый раздел со смещением"? Понятен смысл выражения "создать", но не понятен "эмулировать".

Попытка эмулировать фичи скрытых разделов, которые были в truecrypt, путём манипулирования оффсетами cryptsetup при неаккуратном обращении с векторами инициализации могут (?) привести к фэйлам. Утверждение бездоказательное, подробно не разбирал.

Спасибо

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

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

1. Уметь установить программу (mcrypt или cryptsetup)
2. Помнить режим шифрования (для бессигнатурного варианта).
3. Помнить пароль

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

Насчёт mcrypt не скажу, а для cryptsetup скачиваете любой инсталляционный образ любого Linux'a, в котором можно что-то запускать с флэшки в rescue-режиме, криптсетапите и монтируете, что нужно. Cryptsetup и GnupG — штуки штатные, на них столько всего завязано, что они уже никуда не денутся.


На данный момент оптимальнее так:
cryptsetup -c aes-xts-plain64 -s 512 -h sha512 create /dev/mapper/raw_device /dev/devicename
Кстати, не такой уж и большой оверхед при двойном шифровании с разными паролями: слой без LUKS, а внутри слой с LUKS.

Use --offset to specify device offset. Note that the units need to be specified in number of 512 byte sectors.

Use --skip to specify the IV offset. If the original device used an offset and but did not use it in IV sector calculations, you have to explicitly use -""-skip 0 in addition to the offset parameter.

Как-то стрёмно использовать cryptsetup c офсетами после таких пояснений. Я не удивлюсь, если там внутри критично напортачили, а в случае обнаружения баги скажут, что это опции неприоритетные, за них никто не ручался.

Разве эта опция — не такая простая вещь для владеющих темой?


А в обычном plain mode без смещения (-c aes-xts-plain64 -s 512 -h sha512) не может возникнуть? Чем это отличается от:

1. С помощью dmsetup отмаппливаем сектора с n'ого до последнего.
2. К отмаппленному устройству применяем обычный cryptsetup (plain mode) без всяких смещений, т.е. без --skip и без --offset

Ы? По-моему, это совершенно эквивалентно. Если всё так плохо и непросто, как вы описываете, то поидее проблема должна в любом plain mode вылезать.


Наверно, не предыдущие, а последующие.


Вы проверяли? Это работает? Я вам уже написал, что здесь /dev/mapper лишнее.


(проблема выеденого яйца не стоит)


(вообще непонятно, что они там хотели этим сказать)

Простите, на какую из этих двух ваших реплик теперь ориентироваться?