Можно использовать cryptsetup без LUKS-расширений

где-то в дикой природе кроме армии дискеты ещё встречаются?

Я рабочий дисковод видел последний раз, наверное, лет 15 назад.

[юмор]
Используйте отделяемый заголовок и носите его на флэшке.
[/юмор]

Используйте бессигнатурный cryptsetup без LUKS:
cryptsetup -c aes-xts-plain64 -s 512 -h sha512 --create /dev/mapper[шифрустройство] /dev/fd[дисковод]

Используйте бессигнатурный cryptsetup без LUKS

Она исторически примерно для этого и была и пока ещё есть. Называется hashalot^[link3]. Но PBKDF не умеет, разве что пропатчить.

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

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

Называется hashalot

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

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

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

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

Anti-forensic stripe. Это не бага, это фича.

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

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, каким мы его всегда видим), иначе было бы совсем плохо.

# 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[устройство]

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

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

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

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

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

Работает:

$ sha512sum file1 | echo `cut -d' ' -f1`"  file2" | sha512sum -c
file2: ЦЕЛ
 
$ sha512sum file1 | echo `cut -d' ' -f1`"  file3" | sha512sum -c
file3: ПОВРЕЖДЁН
sha512sum: ПРЕДУПРЕЖДЕНИЕ: НЕ совпала 1 вычисленная контрольная сумма

В соревнование башистов врывается команда Anonymous named pipe's^[link14]:

diff <(cat file1 | sha512sum) <(cat file1.copy | sha512sum) 1>/dev/null ; echo $?
0

diff <(cat file1 | sha512sum) <(cat file2 | sha512sum) 1>/dev/null ; echo $?
1

Можно грабить писать альяс на аргументы $1 и $2 вместо имён файлов.

Дырка от дискеты переходит вам. Можно ещё дырок от перфокарт добавить.

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

Вместо того, чтобы ограничиться бездоказательным:

И успокоиться на этом.

Похоже, что жирно как обычно. Задача данного тролля — развести на трату времени и сил на доказывание чего-либо в как можно более пустых обсуждениях. А раз обсуждения технические, то и придраться не к чему — это же не оффтопик, в тематику ресурса укладывается.

А я и не начну, в этом всё и отличие. Или начну в форме: глупый я, как спрашивающий, by default; если есть время и желание — можете снизойти и популярно объяснить не отправляя читать маны Ааронсона и Нильсена с Чангом, а нет — так нет. Раз Чангов не читал — о чём со мной таким неосилятором вообще говорить то? Кроме как о «делайте по стндартам и не лезьте со своими понятиями».

Форум — не справочник, расписывать каждый пост хотя бы как вики-документ я не умею. И я считаю ресурсы (время, силы) на коммуникацию. Если она неоптимальна и неприоритетна, то и ресурсов тратится минимум. Можете считать это недостатком, могу вообще на всякие неясные и гипотетические темы благоразумно помалкивать, отсылая только к проверенному и известному.

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

1. Отсутствие двойного шифрования.
2. Отсутствие сигнатур.
3. Cменяемость ключа на устройство через LUKS.
4. Возможно быстро удалить данные с устройства, затерев его заголовк.
5. Достаточно помнить всего один стойкий пароль для доступа к устройству.

Минус в том, что

1. Это лишние команды (хотя и немного, и они простые), поэтому понадобится писать скрипт.
2. Если не хочется небезопасно работать с паролем, при подключениии устройства его придётся вводить дважды: на расшифрование заголовка LUKS и, собственно, на расшифрование LUKS-тома.

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

На каком-то уровне протестированный пример:

#!/bin/sh
 
Device=YOUR_DEVICE
 
HeaderSize=4096
FullSize=$(blockdev --getsz $Device)
Size=$(( $FullSize - $HeaderSize ))
 
cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -b $HeaderSize \
  plainOpen $Device header_crypt
cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 --align-payload 0 \
  luksFormat /dev/mapper/header_crypt
 
dmsetup create device_space --table "0 $Size linear $Device $HeaderSize"
cryptsetup --header /dev/mapper/header_crypt --align-payload 0 \
  luksOpen /dev/mapper/device_space device_space_crypt
cryptsetup remove header_crypt
 
mkfs.ext4 /dev/mapper/device_space_crypt
mount /dev/mapper/device_space_crypt /media/mnt

Всему виной, как всегда, баги:

O^[link27]n 12/16/2011 08:14 AM, Arno Wagner wrote:
To my surprise, giving alignment --align-payload=1 (or = 2) results in a data-area staring at 0x101000, while --align-payload=0 gives 2MiB offset. Is this rounded up to multiples of 8? I had a brief look into the sources but did not find the relevant code. The full behaviour should go into the man-page under the explanation for --align-payload.

Align 0 should switch to internal default (4k).

Man page needs rewrite and many grammar and wording fixes...

S^[link28]ee explanation in commit. In short, if you want detached header, you can either use data offset 0 (so whole data device is used) or there is always "reserved" space on data device of header size.

A^[link29]llow to use --header option in all LUKS commands. The --header always takes precedence over positional device argument.

D^[link30]isallow explicit small payload offset for detached header.

LUKS detached header has some limitations, one of them is that you cannot run some explicit check for data offsets without providing also data device.

Because luksDump and all key handle commands takes only metadata device (LUKS heaer device), it not easy to properly support data payload offset validation.

So if detached header is present for luksFormat, code now allows data payload 0 (IOW whole data device is used) and explicit offset larger than header+keyslots (the same as the header is on data device – so some space is wasted).

N.B. with detached header the option --align-payload is used directly without any round up caculations.

Fixes Issue#155.

В версии 1.6.6 ненужный оффсет можно удалить таким хаком:

#!/bin/sh
 
Device=YOUR_DEVICE
 
HeaderSize=4096
FullSize=$(blockdev --getsz $Device)
 
cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -b $HeaderSize \
  plainOpen $Device header_crypt
cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 \
  luksFormat /dev/mapper/header_crypt
 
dmsetup create device_space_full --table "0 $FullSize linear $Device 0"
cryptsetup --header /dev/mapper/header_crypt \
  luksOpen /dev/mapper/device_space_full device_space_crypt
cryptsetup remove header_crypt
 
mkfs.ext4 /dev/mapper/device_space_crypt
mount /dev/mapper/device_space_crypt /path/to

Не самый тривиальный момент (и плохо описанный в документации) — то, что аргументом luksFormat является внешнее устройство (или файл) для хидера, а не то целевое блочное устройство, которое мы будем шифровать. Последнее вообще в этом случае не указывается в luksFormat-команде. Т.е. luksFormat создаёт только заголовок LUKS'а на чём-то (по сути — метод выведения мастер-ключа), а потом этот заголовок можно будет применять к любому блочному устройству для его шифрования. Т.е. не нужно писать --header {устройство,файл} в luksFormat-команде. man cryptsetup:

--header <device or file storing the LUKS header>

This option is only relevant for LUKS devices and can be used with the luksFormat...

For luksFormat with a file name as argument to --header, it has to exist...

Первая фраза противоречит второй. Т.е. нет такой опции --header у luksFormat — это будет ошибкой синтаксиса, если указать.

Общие замечания:

P.S. Ещё одна^[link31] полезная заметка на тему внешних хидеров.

Ввиду предыдущего комментария мотивация вполне ясна. Более-менее рабочие оттестированные варианты (применение — на свой страх и риск):

1. Инициализация устройства, скрипт plain_init.sh:

   #!/bin/sh
   # Initialise new plain mode encrypted device on some volume group
    
   DEVICE=$1
   DEVICE_NAME=$(echo $DEVICE |sed 's/^.*\///')
   CRYPT_SLOT_NAME=${DEVICE_NAME}_slot_crypt
   CRYPT_NAME=${DEVICE_NAME}_crypt
   AMOUNT_OF_KEY_SLOTS=8
    
   echo Device name is $DEVICE
   echo Device short name is $DEVICE_NAME
   echo Crypt slot name is $CRYPT_SLOT_NAME
   echo Device crypt name is $CRYPT_NAME
   set -x
    
   # Clean all slots
   dd if=/dev/urandom of=$DEVICE bs=512 count=$AMOUNT_OF_KEY_SLOTS && \
    
   # Initialize the first slot
   cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -b 1 \
     plainOpen $DEVICE $CRYPT_SLOT_NAME && \
    
   ## Initialize the second slot
   #CRYPT_SLOT_NAME_2=${CRYPT_SLOT_NAME}_2
   #cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -b 1 -o 1 -p 1 --shared \
   #  plainOpen $DEVICE $CRYPT_SLOT_NAME_2
   #dd if=/dev/mapper/$CRYPT_SLOT_NAME of=/dev/mapper/$CRYPT_SLOT_NAME_2
   #cryptsetup remove $CRYPT_SLOT_NAME_2
    
   # Open target device
   cryptsetup -c aes-xts-plain64 -s 512 -o $AMOUNT_OF_KEY_SLOTS \
     -d /dev/mapper/$CRYPT_SLOT_NAME --shared \
     plainOpen $DEVICE $CRYPT_NAME && \
   cryptsetup remove $CRYPT_SLOT_NAME && \
    
   mkfs.ext4 /dev/mapper/$CRYPT_NAME

   Применение:

   # /path/to/plain_init.sh /dev/VG_name/LV_name

2. Открытие устройства, скрипт plain_open.sh:

   #!/bin/sh
   # Open plain mode encrypted device on some volume group using slot 1
    
   DEVICE=$1
   DIR=$2
   DEVICE_NAME=$(echo $DEVICE |sed 's/^.*\///')
   CRYPT_SLOT_NAME=${DEVICE_NAME}_slot_crypt
   CRYPT_NAME=${DEVICE_NAME}_crypt
   AMOUNT_OF_KEY_SLOTS=8
    
   set -x
   # Open the first slot
   cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -b 1 \
     plainOpen $DEVICE $CRYPT_SLOT_NAME && \
    
   # Open target device
   cryptsetup -c aes-xts-plain64 -s 512 -o $AMOUNT_OF_KEY_SLOTS \
     -d /dev/mapper/$CRYPT_SLOT_NAME --shared \
     plainOpen $DEVICE $CRYPT_NAME && \
   cryptsetup remove $CRYPT_SLOT_NAME && \
    
   mount /dev/mapper/$CRYPT_NAME $DIR

   Применение:

   # /path/to/plain_open.sh /dev/VG_name/LV_name /path/to

3. Отключение устройства, скрипт plain_close.sh:

   #!/bin/sh
   # Close plain mode encrypted device on some volume group
    
   DEVICE=$1
   DEVICE_NAME=$(echo $DEVICE |sed 's/^.*\///')
   CRYPT_NAME=${DEVICE_NAME}_crypt
    
   set -x
   umount /dev/mapper/$CRYPT_NAME && \
   cryptsetup remove $CRYPT_NAME

   Применение:

   # /path/to/plain_close.sh /dev/VG_name/LV_name

Количество слотов «кустарного LUKS'а» сейчас 8, это заголовок размером 4KB (у аутентичного LUKS — 4k секторов, т.е. 2 MB), но можно поставить один или два, тогда оверхед будет, соответственно, 0.5KB или 1KB. Правда, при этом mkfs.ext4 будет ругаться на выравнивание и грозиться проблемами со скоростью работы:

/dev/mapper/$CRYPT_NAME alignment is offset by 3584 bytes.
This may result in very poor performance, (re)-partitioning suggested.

чего нет при 8-ми слотах.

Открытие устройства — по сути, три команды, не требующие каких-то вычисляемых переменных, как в примере с LUKS, т.е. их легко ввести без скрипта вручную. Что ещё хорошо — для plain mode поддерживается --shared, которым не воспользоваться c LUKS (поэтому там понадобилась дополнительная команда — хак с отображением пространства с помощью dmsetup).

Для удобной смены пассфразы^[link11] нужно минимум 2 слота. Пример с добавлением второго слота выше приведён (смысл понятен), но закомменчен. Т.е. расшированное содержимое всех использованных слотов-секторов одинаково (оно и есть мастер-ключ), но они зашифрованы разными пассфразами. Может возникнуть ошибка, когда в разных слотах используется одинаковая пассфраза (к примеру, в первом и во втором), тогда шифрованное содержимое у них будет одинаковым, что разрушит бессигнатурность/отрицаемость. Для этого применён трюк -o 1 -p 1 вместо просто -o 1 для второго слота. В этом случае даже при одинаковых пассфразах шифртексты будут разными. Это соответствует^[link33] в точности тому, как если бы сразу расшифровали два первых слота-сектора одной пассфразой (-b 2 -o 0 -p 0) и увидели совпадение содержимого первого расшифрованного сектора со вторым на открывшемся (крипто)устройстве. Т.е. «бессигнатурный криптораздел» для второго слота-сектора состоит не из него самого, а из него + первый сектор, поэтому мы делаем отступ (-p 1) — пропускаем первый сектор, чтобы расшифровать только второй.

Возможно, есть ещё какие-то нетривиальные уязвимости схемы, но пока их не вижу. Непосредственное хранение мастер-ключа на диске (пусть и шифрованное) тоже немного смущает:

1. Это повышает риск утечки мастер-ключа по сравнению со случаем, когда используется LUKS.
2. Можно ли шифровать мастер-ключом мастер-ключ? Но даже если он будет где-то записан на основном шифрованном устройстве, где он используется, вряд ли это случится в первом секторе, т.е. IV всё равно будет каким-то нетривиальным.

UPD: Поскольку мастер-ключи разных криптоустройств генерятся случайным образом и всегда будут разными, plain-текст, зашифрованный в «слотах», тоже всегда будет разным (т.е. два разных криптоустройства с одинаковым мастер-ключом недопустимы). Следовательно, можно использовать одинаковые пассфразы для разных криптоустройств — ключами, выводимыми из этих пассфраз, всегда будут шифроваться разные мастер-ключи. Т.е. это^[link34] предупреждение^* неактуально для слотов в силу специфики их содержимого.

Кстати, в варианте с LUKS'ом^[link35] какое-то частичное совпадение plain-текстов в слотах всё равно будет (хотя бы из-за общих метаданных и сигнатур), поэтому там предупреждение^[link34] остаётся в силе, т.е. нельзя использовать одинаковые пассфразы для бессигнатурного слоя разных устройств.

^* В plain mode одинаковые пассфразы ведут к одинаковым ключам, а одинаковые ключи на одинаковых plain-текстах дадут одинаковые шифртексты.