Скриптомесево №3

#!/bin/sh
set -x 
 
# Шифруемый файл (могут быть проблемы с именами файлов,
# содержащими пробелы и спецсимволы):
File=$1
# Его размер в байтах:
FileByteSize=`cat "$File" |wc -c`
# Его размер в секторах (будет на один сектор
# больше, если его размер равен целому числу
# секторов -- неохота это фиксить):
FileSectSize=$(( $FileByteSize / 512 + 1 ))
 
# Именем зашифрованного файла будет:
FileEnc="$1.enc"
# Размер файла в байтах дополним размером заголовка LUKS.
# Расшифрованное устройство будет обрезано до целого числа
# секторов. Мы фиксим это и закладываем лишний сектор
# для записи размера файла:
FileEncSectSize=$(( 4096 + $FileSectSize + 1 ))
 
# Создадим файл нужного размера (для больших файлов
# лучше покурить способ с sparse, чтобы файл писался
# лишь единожды, а не 2 раза как сейчас: заполняясь нулями
# и потом шифрованными данными):
dd if=/dev/zero of="$FileEnc" count=$FileEncSectSize
 
cryptsetup_options="-q -c aes-xts-plain64 -s 512 -h sha512"
 
# Открываем LUKS-контейнер на зашифровываемом файле:
cryptsetup $cryptsetup_options luksFormat "$FileEnc"
# Имя временного устройства делаем случайным:
DeviceName=`tr -dc "[:alpha:]" < /dev/urandom | head -c 6`
cryptsetup luksOpen "$FileEnc" $DeviceName
 
# Затираем нулями тот сектор, который будет содержать
# размер файла:
dd if=/dev/zero of=/dev/mapper/$DeviceName count=1
# Записываем в него сам размер файла:
echo $FileByteSize | dd of=/dev/mapper/$DeviceName 
 
# Записываем шифруемый файл в LUKS-контейнер:
dd if="$File" of=/dev/mapper/$DeviceName seek=1
 
cryptsetup luksClose $DeviceName
 
sync

#!/bin/sh
set -x 
 
# Расшифровываемый файл:
File=$1
# Именем расшифрованного файла будет:
FileDec="$1.out"
 
# Имя временного устройства делаем случайным:
DeviceName=`tr -dc "[:alpha:]" < /dev/urandom | head -c 6`
 
cryptsetup luksOpen $File $DeviceName
 
# Считываем размер файла в байтах
FileByteSize=`dd if=/dev/mapper/$DeviceName count=1 2>/dev/null | strings`
 
# Записываем расшифровываемый файл (способ очень медленный и плохо
# работает на больших файлах; я не раскурил, как сделать то же самое
# более оптимальными опциями dd, чем с побайтовой записью):
dd if=/dev/mapper/$DeviceName of=$FileDec bs=1 skip=512 count=$FileByteSize
 
cryptsetup luksClose $DeviceName
 
sync

Как это работает

# ./luks_encrypt.sh filename

# ./luks_decrypt.sh filename

dd if=/dev/mapper/$DeviceName of=$FileDec bs=1 skip=512 count=$FileByteSize

--skip, -p <number of 512 byte sectors>

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.

Hence, if --offset n, and --skip s, sector n (the first sector of encrypted device) will get a sector number of s for the IV calculation.

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

Статическая псевдорэндомизация, синтетический IV: IV = Hash(номер сектора ║ ключ ║ содержимое предыдущего сектора ║ что-то ещё, могут быть варианты). Это примерно так в ESSIV. Любителям придираться: формула от балды, пироги с сапогами и всё-такое. Использовать только для иллюстрации принципа. В XTS всё ещё сложнее.

Обратите внимание, что для бессигнатурности там используются трюки

Если запись таким образом идёт в середину файла, всё до середины будет оставлено, как есть, после середины добавлен контент, а оставшаяся часть будет (сюрприз!) обрезана.

Откуда в норме берётся IV в plain mode?

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

Ещё одна тонкость — извраты с 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.

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

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

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

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

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

И openssl и mcrypt?

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

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

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

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

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

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

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

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

>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 это написано?

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

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.

Так подробно же про 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.

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

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

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

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

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

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.

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

offset эквивалентен dmsetup linear. Это можно проверить экспериментально:

# cryptsetup <опции> -o оффсет create zz /dev/sda

# dmsetup create yy --table '0 размер linear /dev/sda оффсет'
# cryptsetup <опции> create zz /dev/mapper/yy

--skip, как я понял, нужен при создании «частичных» крипторазделов. Допустим, нужно адресовать часть криптораздела, отступив от его начала на 8 секторов. Пусть сам криптораздел расположен по оффсету S. Если сделаем --offset S+8, у нас будет неправильный IV, поэтому надо делать --offset S+8 --skip 8. Т.е.

# сryptsetup <опции> --offset S --skip P create zz /dev/sda

# dmsetup create yy --table '0 размер linear /dev/sda S-P'
# cryptsetup <опции> create xx /dev/mapper/yy
# dmsetup create zz --table '0 размер linear /dev/mapper/xx P'

Таким образом, в plain mode не указывать --skip равносильно указанию --skip 0. Можно указывать, если есть сомнения. Задание опции --offset никак не влияет на IV.

UPD: Когда мы skip не задаём (P=0), IV равен «исходному» для сектора S. Смысл указания skip в том, что мы читаем те же самые сектора, что и без skip (это самое нетривиальное!), но с другим IV. Следовательно, нужно сначала сместиться на P секторов «назад» относительно оффсета, образовать криптомаппинг с «исходным» IV, а затем сместиться вперед на те же P секторов. Отсюда сначала S-P, затем P. В итоге получается, что при указании --offset S --skip P криптомаппинг охватывает сектора начиная с S (!), однако, IV устроен так, как будто мы «пропустили» с начала P секторов (отсюда и название «skip»).

Пожалуйста. Если соотнести эти факты с тем, что unknown писал на предыдущих двух страницах, вырисовывается примерно такая картина:

1. IV для первого сектора всегда нулевой, это нормально, и так должно быть.
2. IV для последующих секторов вычисляется из IV (и данных?) предыдущих секторов по некоторому правилу.
3. В plain mode cryptsetup по умолчанию каждый раз думает, что первый сектор открываемого/расшифровываемого устройства есть первый сектор всего имеющегося зашифрованного устройства, поэтому ставит ему IV=0. В общем-то, по умолчанию почти всегда так и есть, и это правильное поведение (см. пункт 1).
4. В случае частичного расшифрования уже шифрованного устройства, когда от его начала надо отступить несколько секторов, нужно использовать иной IV, ненулевой (тут не в безопасности проблема, а в том, что иначе расшифруете содержимое диска неправильно). Указание skip (числа пропускаемых секторов от начала шифрованного устройства) даёт возможность cryptsetup'у правильно вычислить IV для первого расшифровываемого сектора (он не первый на устройства, но первый расшифровываемый), а, следовательно (см. пункт 2), и для всех последующих.

Всё это выглядит так, что IV, в любом случае, вычисляется автоматически по заданным правилам, а опция skip лишь корректирует параметры. Судя по man cryptsetup, сам юзер непосредственно вмешаться в выбор IV (к примеру, задать руками) не может вообще (опция skip — это как выбор значения счётчика для заранее предпопределённого правила вычисления IV).

UPD: Когда --skip не указывается, он по умолчанию равен нулю для plain mode. Да, при этом IV получается, как если бы не было никакого оффсета (это легко проверяется экспериментом с dmsetup linear). Вообще, есть некий базовый режим cryptsetup plain, а offset и skip на него накладываются линейными сдвигами до и после. Опция --skip не меняет адресацию секторов, а исключительно расчет IV. Поэтому в LUKS его вообще нет, о чем ман и говорит нам:

This option is only relevant with plain or loop-aes device types.

Вместо тысячи слов, которые всё равно будет едва ли возможно понять, весь смысл одной картинкой:

.
          S
|<----------------->|
 
                   Та часть криптораздела,
                  которую мы хотим отмаппить
                        (расшифровать)
                      ________/\______
|                    /                \           |
|-------------------------------------------------|
|           \______________  _______________/     |
                           \/ 
               Бессигнатурный криптораздел
                      на /dev/sda
 
           |<------>|
                P
 
 \______________________  _______________________/
                        \/
          Всё блочное устройство /dev/sda

LUKS — это просто чёрный ящик, на входе которого пассфраза, а на выходе — мастер-ключ. Ничего более в нём нет. Метод, как шифровать блочное устройство, определяется задаваемым шифром и режимом, а откуда взялся мастер-ключ — вывели с LUKS'а, задали вручную или получили в plain mode — не играет никакой роли. По крайней мере, на самом шифртексте это не скажется никак. Показываю PoC — подключение LUKS-тома в plain mode:

Создание LUKS-тома

1. Форматируем устройство под LUKS:

   # cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 luksFormat /dev/VG_name/LV_name
   Enter passphrase:

   Ставим паролем qwerty.

2. Открываем устройство и нарезаем внутри ФС:

   # cryptsetup luksOpen /dev/VG_name/LV_name LV_name_crypt
   Enter passphrase for /dev/VG_name/LV_name:
   # mkfs.ext4 /dev/mapper/LV_name_crypt

3. Дампим мастер-ключ LUKS'а в файл и закрываем LUKS-устройство:

   # cryptsetup -q --dump-master-key luksDump /dev/VG_name/LV_name > /tmp/luks_dump.txt
   Enter passphrase: 
   # cat /tmp/luks_dump.txt 
   LUKS header information for /dev/VG_name/LV_name
   Cipher name:    aes
   Cipher mode:    xts-plain64
   Payload offset: 4096
   UUID:           xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
   MK bits:        512
   MK dump:        8f 39 52 7b af 9f 08 68 aa ea 1f b0 9e 3e 27 a2 
                   d8 60 89 5a f0 69 75 92 88 98 4e 9c 0c 74 b9 89 
                   5a c9 87 6e ed 84 37 52 d9 51 14 d4 d8 ba 0c 2e 
                   4c 0c ab dd 2b 18 44 0b c7 8c a8 23 3e b9 6f ab
   # cryptsetup luksClose LV_name_crypt

Подключение LUKS-тома в plain mode

1. Отредактируем /tmp/luks_dump.txt так, чтоб там был только мастер-ключ в следующем формате:

   # cat /tmp/luks_dump.txt 
   8f 39 52 7b af 9f 08 68 aa ea 1f b0 9e 3e 27 a2
   d8 60 89 5a f0 69 75 92 88 98 4e 9c 0c 74 b9 89
   5a c9 87 6e ed 84 37 52 d9 51 14 d4 d8 ba 0c 2e
   4c 0c ab dd 2b 18 44 0b c7 8c a8 23 3e b9 6f ab

2. Восстновим бинарный мастер ключ по его hex-дампу и проверим результат:

   # cat /tmp/luks_dump.txt |xxd -r -p > /tmp/master_key
   # cat master_key |hexdump -Cv
   00000000  8f 39 52 7b af 9f 08 68  aa ea 1f b0 9e 3e 27 a2  |.9R{...h.....>'.|
   00000010  d8 60 89 5a f0 69 75 92  88 98 4e 9c 0c 74 b9 89  |.`.Z.iu...N..t..|
   00000020  5a c9 87 6e ed 84 37 52  d9 51 14 d4 d8 ba 0c 2e  |Z..n..7R.Q......|
   00000030  4c 0c ab dd 2b 18 44 0b  c7 8c a8 23 3e b9 6f ab  |L...+.D....#>.o.|
   00000040

   Результат, как видим, правильный.

3. Подключим LUKS-том с помощью бинарного мастер-ключа, указав тот же режим шифрования и размер ключа и не забыв сделать отступ на LUKS-томе, чтобы убрать LUKS-заголовок:

   # cryptsetup -c aes-xts-plain64 -s 512 -d /tmp/master_key \
     -o 4096 plainOpen /dev/VG_name/LV_name LV_name_crypt

4. Наступает момент истины:

   # mount /dev/mapper/LV_name_crypt /media/mnt

   Вуаля, всё работает, что и требовалось доказать. Понятно, что аналогичным образом можно выборочно расшифровать и любую часть этого LUKS-тома, указав нужный размер -b и оффсеты (-o и -p).

Мораль: