Длина и состав ключа dm-crypt/Luks

Нагуглил наконец немного информации. Отвечаю себе на третий вопрос.

Режим работы xts-aes - это такой хитрый алгоритм шифрования для всяких накопителей. В качестве функции шифрования в нем используется AES. Применяется два ключа: при задании опции cryptsetup -s 256 алгоритмом будет использовано два ключа по 128 бит. С помощью aes на обоих этих ключах будет производиться шифрование. То есть, это будет aes-128.

Описание XTS:

Ci = EK1(Pi ^ (EK2(n) Multiplication ai)) ^ (EK2(n) Multiplication ai)

Where:

Multiplication - denotes multiplication of two polynomials over the binary field GF(2) modulo x128+x7+x2+x+1

K1 - is the encryption key (256-bit for each supported cipher; i.e, AES, Serpent, and Twofish)

K2 - is the secondary key (256-bit for each supported cipher; i.e, AES, Serpent, and Twofish)

i - is the cipher block index within a data unit; for the first cipher block within a data unit, i = 0

n - is the data unit index within the scope of K1; for the first data unit, n = 0

a - is a primitive element of Galois Field (2128) that corresponds to polynomial x (i.e., 2)

The size of each data unit is always 512 bytes (regardless of the sector size).

Описалово взято из доки по трукрипту, но в моем случае алгоритмы одинаковые. Вроде бы. Форматирование поехало, так что для достоверности нужно использовать первоисточник.

Остается непонятно, откуда и как берутся K1 и K2.

Из всего вышесказанного делаю вывод, что криптостойкость всего этого xts-aes базируется именно на алгоритме шифрования, т.е. aes. Всякие эти xts-преобразования врят ли улучшат стойкость, да и тестов xts я не нашел, а вот aes - много=) Таким образом, xts-aes-256 стоек так же, как и aes-128.

Ну и наконец, ссылки:
http://www.truecrypt.org/docs/modes-of-operation
http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf
http://axelkenzo.ru/downloads/1619-2007-NIST-Submission.pdf

По-моему, проще просто взять Counter mode: aes-ctr64-plain или как-то так. Можно больше одного раза в криптоконтейнер обернуть для верности, с разными ключами. Выйдет не хуже XTS.

По поводу LUKS - оно вам реально пригодится только если вы везде ходите со своим винтом и втыкаете куда попало, да ещё вводите пароль в чужую систему. Для истинного параноика это неприемлемо. Как минимум нужна ещё своя железка (одноплатник в кармане или ноут), чтобы передавать файло уже по сети/эмулировать флэшдрайв или что-то такое. А на вашей доверенной железке LUKS - лишняя сущность, только срёт в начало криптоконтейнера своим бесполезным заголовком, затрудняя восстановление в случае повреждений данных. Практичнее использовать голый cryptsetup и самописные автоматизирующие скрипты, ключи в файлах на разрушимом носителе.

А чем не устроил aes-cbc-essiv?

Ошибся, выйдет несколько хуже чем XTS. Все данные эксорятся, можно заметить переключения битов при перезаписи и узнать, что в данном блоке (но не ключи, это только потом). Для обфускации достаточно обернуть в дополнительный слой aes-ecb-plain, вот тогда уже не хуже.

Пользуясь моментом, спрошу: как посредством dmcrypt делать XOR двух разделов/файлов одинаковой величины?

> посредством dmcrypt делать XOR двух разделов/файлов одинаковой величины?

За 5-10 минут пишется на Си прога, которая «ксорит» 2 файла (разделы тоже файлы). Если с ассемблером - уйдет до 30 минут.

Как и для чего к этому всему пристроить dmcrypt - без понятия.

> Для обфускации достаточно обернуть в дополнительный слой aes-ecb-plain, вот тогда уже не хуже.

Но и не лучше.

Автору же ответ:

1) Разумно брать 128. В случае с 256 комп будет страдать лишней фигней сомнительного назанчения (см п.3)

2) tweakable ключ (как я понял) - это ключ для тех самых xts

3) В режиме 256 бит он почему-то использует не AES-256, а два AES-128. Видимо, разрабы посчитали эквивалентным. Хотя в реале в подаляющем большинстве случаев применение нескольких шифров с одинаковой длиной ключа (особенно одинаковых) эквивалентно применению одного некого шифра с такой же длиной ключа.

> для чего к этому всему пристроить dmcrypt

Ксорить надо в реальном времени, потому что живая файловая система. Потому и dmcrypt, что через ядро.

Т.е. хотите монтировать ФС, зашифрованную по Вераму? dmcrypt ничего такого не поддерживает. Все равно придется самому дописывать.

а) cryptosetup на вход дается НЕ размер ключа, а размер passphrase. Если фраза берется из /dev/random, то разницы между 32 и 4096 хеша sha256 не будет, т.е. ее можно сгенерить: head -c 32 /dev/random > disk.key и это будет нормально. Размер ключа фиксирован типами хеш-функций. Наибольшие из используемых это sha256 и sha512, имеет смысл ограничиться размером 256.

б) 128+128 ~= 129 (грубо).

в) подробное описание схемы шифрования, и использование в ней алгоритма AES и хеш-функции SHA256 смотри в англ. википедии по «cbc».

1. aes-xts-essiv:sha256 по моим тестам почти в два раза медленнее чем aes-cbc-essiv:sha256, т.к. выполняются там две операции шифрования c двумя разными ключами, но он в теории безопасней.

2. Если паранойя действительно мучает, то не стоит использовать aes-cbc-plain[64] из-за его достаточной слабости.

3. Из 1 и 2 делаем вывод что aes-cbc-essiv:sha256 это самое то. Ну еще и процессор с AES-NI будет как раз кстати, ускорение в несколько раз по скорости. И последние ядра (.38?) умеют немного распараллеливать потоки шифрования на несколько ядер, особенно ощутимо почему-то при записи.