Как определить, какие шифры и режимы шифрования я могу использовать в dm-crypt / LUKS?

Я использую систему на основе Ubuntu, и мне сложно определить, какие шифры и режимы шифрования доступны для меня.

Страница руководства cryptsetup гласит:

«См. / Proc / crypto список доступных опций. Вам может понадобиться загрузить дополнительные крипто-модули ядра, чтобы получить больше опций».

В моем / proc / crypto очень мало. Как узнать, какие дополнительные криптомодули ядра доступны для загрузки?

Есть много, много документов и справочных страниц для чтения, но один документ, который может вас особенно заинтересовать - это спецификация формата LUKS на диске (PDF).

Приложение B (которое, естественно, ближе к концу) гласит:

Реестр спецификаций шифров и хэшей

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

Допустимые имена шифров приведены в таблице 1.

Действительные режимы шифрования перечислены в таблице 2. По контракту режимы шифрования с использованием IV и настроек должны начинаться с нуля IV / настройки. Это относится ко всем вызовам примитивов шифрования / дешифрования, особенно при обработке материала ключа. Кроме того, эти режимы шифрования IVs / твиков обычно разделяют поток шифров на независимые блоки путем повторного заполнения твиков / IV на границах секторов. Требование полного / нулевого IV / настройки для первого зашифрованного / дешифрованного блока эквивалентно требованию, чтобы первый блок был определен как находящийся в секторе 0.

В таблице 3 приведены действительные спецификации хеш- функции для поля хэш-спецификации . Совместимая реализация не должна поддерживать все спецификации шифра, режима шифрования или хеширования.

Таблица 1: Действительные имена шифров

• aes - Расширенный стандарт шифрования - FIPS PUB 197
• twofish - Twofish: 128-битный блочный шифр - http://www.schneier.com/paper-twofish-paper.html     (см. ниже)
• змей - http://www.cl.cam.ac.uk/~rja14/serpent.html
• cast5 - RFC 2144
• cast6 - RFC 2612

Таблица 2: Действительные режимы шифрования

• ecb - вывод шифра используется напрямую
• cbc-plain - шифр работает в режиме CBC. Цепочка CBC обрезается в каждом секторе и повторно инициализируется с номером сектора в качестве начального вектора (преобразуется в 32-разрядный и в младший порядок). Этот режим указан в [Fru05b], глава 4.
• cbc-essiv: hash - шифр работает в режиме ESSIV, используя хэш для генерации ключа IV для исходного ключа. Например, при использовании sha256 в качестве хэша спецификацией режима шифрования является «cbcessiv: sha256». ESSIV указан в [Fru05b], глава 4.
• xts-plain64 - http://grouper.ieee.org/groups/1619/email/pdf00086.pdf, plain64 - 64-битная версия простого начального вектора

Таблица 3: Действительные спецификации хеша

• sha1 - RFC 3174 - американский алгоритм безопасного хеширования 1 (SHA1)
• sha256 - вариант SHA согласно FIPS 180-2
• sha512 - вариант SHA в соответствии с FIPS 180-2
• palemd160 - http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html    (см. ниже)

Примечание редактора: вышесказанное скопировано из спецификации. После его написания URL этих документов изменились:

• Twofish: 128-битный блочный шифр    (новый URL)
• Хеш-функция RIPEMD-160    (новый URL)

Вы можете перечислить шифры, поддерживаемые вашими ядрами, с помощью следующей команды:

[root@arif]# ls /lib/modules/[your kernel version]/kernel/crypto/
algif_rng.ko.xz   blowfish_common.ko.xz   cmac.ko.xz               cts.ko.xz          gf128mul.ko.xz           michael_mic.ko.xz  rsa_generic.ko.xz      tgr192.ko.xz           xts.ko.xz
ansi_cprng.ko.xz  blowfish_generic.ko.xz  crc32_generic.ko.xz      deflate.ko.xz      ghash-generic.ko.xz      pcbc.ko.xz         salsa20_generic.ko.xz  twofish_common.ko.xz   zlib.ko.xz
anubis.ko.xz      camellia_generic.ko.xz  crct10dif_common.ko.xz   des_generic.ko.xz  jitterentropy_rng.ko.xz  pcrypt.ko.xz       seed.ko.xz             twofish_generic.ko.xz
arc4.ko.xz        cast5_generic.ko.xz     crct10dif_generic.ko.xz  dh_generic.ko.xz   khazad.ko.xz             rmd128.ko.xz       serpent_generic.ko.xz  vmac.ko.xz
async_tx          cast6_generic.ko.xz     cryptd.ko.xz             drbg.ko.xz         lrw.ko.xz                rmd160.ko.xz       sha512_generic.ko.xz   wp512.ko.xz
authencesn.ko.xz  cast_common.ko.xz       crypto_null.ko.xz        fcrypt.ko.xz       mcryptd.ko.xz            rmd256.ko.xz       tcrypt.ko.xz           xcbc.ko.xz
authenc.ko.xz     ccm.ko.xz               crypto_user.ko.xz        gcm.ko.xz          md4.ko.xz                rmd320.ko.xz       tea.ko.xz              xor.ko.xz

Вы можете перечислить шифры и хэши, которые вы можете использовать, и их сравнение ввода / вывода с luksпомощью следующей команды:

[root@arif arif]# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       289342 iterations per second for 256-bit key
PBKDF2-sha256     353293 iterations per second for 256-bit key
PBKDF2-sha512     227555 iterations per second for 256-bit key
PBKDF2-ripemd160  233224 iterations per second for 256-bit key
PBKDF2-whirlpool  236165 iterations per second for 256-bit key
argon2i       4 iterations, 917485 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 951672 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       642.2 MiB/s      2495.8 MiB/s
    serpent-cbc        128b        89.3 MiB/s       542.6 MiB/s
    twofish-cbc        128b       100.4 MiB/s       343.1 MiB/s
        aes-cbc        256b       477.2 MiB/s      1979.2 MiB/s
    serpent-cbc        256b        89.3 MiB/s       538.9 MiB/s
    twofish-cbc        256b       173.3 MiB/s       343.1 MiB/s
        aes-xts        256b      1668.0 MiB/s      1664.1 MiB/s
    serpent-xts        256b       535.7 MiB/s       523.4 MiB/s
    twofish-xts        256b       332.6 MiB/s       339.8 MiB/s
        aes-xts        512b      1384.5 MiB/s      1380.7 MiB/s
    serpent-xts        512b       539.3 MiB/s       524.4 MiB/s
    twofish-xts        512b       335.0 MiB/s       340.1 MiB/s

Вы можете сравнить конкретные шифры с помощью следующей команды:

[root@arif]# ciphers="aes-xts serpent-xts anubis-xts"

[root@arif]# echo "#     Algorithm |       Key |      Encryption |      Decryption";for i in $ciphers ; do cryptsetup benchmark --cipher $i|tail -n 1; done

#     Algorithm |       Key |      Encryption |      Decryption
        aes-xts        256b      1613.9 MiB/s      1642.8 MiB/s
    serpent-xts        256b       538.9 MiB/s       521.9 MiB/s
     anubis-xts        256b       182.0 MiB/s       182.1 MiB/s

Ядро 5.1, действующее в то время, когда я пишу это, имеет два разных формата: строку шифра, «старый» формат и «новый» формат. Пока что все в этом вопросе и, очевидно, во всех документах, имеет дело со «старым» форматом, поэтому я опишу его здесь. Это только для шифрования. Если используется целостность с dm-crypt, то нужно учитывать шифры AEAD, и это становится еще сложнее.

Анализируемый ядром формат - это « шифр [ :keycount ] -режим -ivmode [ :ivopts ]». Примеры: aes-xts-plain64, blowfish-cbc-essiv:sha256, aes:64-cbc-lmk.

• шифровать шифр для использования, примерыaes,anubis,twofish,arc4и т.д. дй-крипты драйвер ядра не имеет список шифров. Это передается в Linux Crypto API, поэтому можно использовать любой подходящий шифр, поддерживаемый ядром.

• keycount Опциональная мощность двух чисел ключей для использования с шифром. По умолчанию это значениеlmkравно1 для всего, кромеivmode, где оно по умолчанию равно 64. Это действительно относится только к LMK, и значения, отличные от 1, не будут работать должным образом с другими режимами.

• mode Режим цепочки блоков для использования с шифром. Примерами являютсяecb,cbc,xts. Помимо знания, что неecbиспользует IV, драйвер md-crypt передает это через Linux Crypto API и может использовать любой режим цепочки, поддерживаемый ядром.

• ivmode Алгоритм, используемый для генерации вектора инициализации (IV) для каждого сектора. В типичном шифровании с симметричным ключом, в отличие от dm-crypt, IV - это еще один бит данных, передаваемый в шифр вместе с ключом при шифровании или дешифровании. На всю операцию передан только один IV. Поскольку dm-crypt должен уметь читать и записывать каждый сектор отдельно, он не шифрует весь диск как одну операцию. Вместо этого есть IV для каждого сектора. Вместо того, чтобы передавать IV в качестве данных, здесь описан алгоритм создания IV. Это не является частью Linux Crypto API, поскольку шифрование IV не производится, а допустимыезначения ivmode определяются драйвером dm-crypt. Они есть:

  • plain, plain64, plain64be, benbi Они просто использовать номер сектора, в различных форматах, как IV. Предназначен для блочных режимов, таких как XTS, которые разработаны, чтобы противостоять атакам, например водяным знакам, при использовании простого и предсказуемого IV. plain64кажется наиболее рекомендуемым.
  • nullIV всегда ноль. Для тестирования и обратной совместимости вы не должны использовать это.
  • lmk Совместим со схемой шифрования Loop-AES.
  • tcw Совместим с TrueCrypt.
  • essivИспользует номер сектора, зашифрованный с помощью хэша ключа. Предназначен для таких режимов, как CBC, которые не устойчивы к различным атакам при использовании простого IV plain64.

• ivopts Хеш для использования сessiv ivmode , игнорируется для всех других режимов.

В особом случае « шифр-plain » или просто « шифр » интерпретируются как « шифр-cbc-plain ». Другим частным случаем является то, что ecbрежим не должен указывать ivmode .

Как это относится к /proc/crypto

Что касается /proc/crypto, только шифр и режим актуальны. dm-crypt с созданием спецификации Crypto API в форме " шифра режима " и запросом этого у ядра. Это то , что нужно искать в качестве для . Пример:()/proc/cryptonameskcipher

name         : xts(aes)
driver       : xts-aes-aesni
module       : kernel
priority     : 401
refcnt       : 1
selftest     : passed
internal     : no
type         : skcipher
async        : yes
blocksize    : 16
min keysize  : 32
max keysize  : 64
ivsize       : 16
chunksize    : 16
walksize     : 16

Значение typeof skcipherуказывает на этот симметричный ключ шифра, который использует dm-crypt, и имя xts(aes)будет записано, aes-xtsесли указано с помощью dm-crypt. В keysizeполях также говорят нам , какие ключевых размеры могут быть использованы с этим шифром.

Если это из модуля, имя модуля может отображаться в moduleстроке. Тем не менее, многие шифры (как правило, те в программном обеспечении, которые не имеют какого-либо аппаратного кода) реализованы как универсальный шифр, который комбинируется с универсальным кодом цепочки блоков для создания окончательного skcipher. Например:

name         : xts(anubis)
driver       : xts(ecb(anubis-generic))
module       : kernel
type         : skcipher

name         : anubis
driver       : anubis-generic
module       : anubis
type         : cipher

В этом случае анубисный шифр объединяется с кодом режима цепочки блоков XTS ядра для получения окончательного шифра xts(anbuis), которому был назначен модуль kernel. Но для того, чтобы это было доступно, нам нужен общий шифр anubis, который взят из anubisмодуля. Большинство шифров имеют псевдоним модуля « crypto-шифр », который можно использовать для их загрузки, например modprobe crypto-anubis, загружал бы модуль, который предоставляет шифр анубиса.

При использовании cryptsetup benchmarkкоманды важны только шифр и режим , так как это все, что проверяется. Если режим не указан, по умолчанию используется CBC. Ivmode полностью игнорируется. Таким образом, для сравнительного анализа, aes, aes-cbcи aes-cbc-foobarвсе эквивалентны.