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

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

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

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

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

Источник

2 ответа

Есть много, много документов и справочных страниц для чтения, но один документ, который может вас особенно заинтересовать, - это спецификация формата 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 этих документов изменились:

Источник

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

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

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

  • keycount Опциональная мощность двух чисел ключей для использования с шифром. По умолчанию 1 для всех, кроме lmk 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 кажется наиболее рекомендуемым.
    • null IV всегда ноль. Для тестирования и обратной совместимости вы не должны использовать это.
    • 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 вида "mode"(шифровать)"и запросить это у ядра. Это то, что нужно искать в /proc/crypto как name для skcipher, Пример:

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

type из 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 модуль. Большинство шифров имеют псевдоним модуля "crypto-шифр", который может быть использован для их загрузки, например, modprobe crypto-anubis будет загружать модуль, который обеспечивает шифр Anubis.

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

Источник

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

[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
Источник
Другие вопросы по тегам