如何确定可以在dm-crypt / LUKS中使用的密码和密码模式?


14

我使用的是基于Ubuntu的系统,因此我很难确定我可以使用哪些密码和密码模式。

cryptsetup手册页显示:

“请参阅/ proc / crypto以获取可用选项的列表。您可能需要加载其他内核加密模块才能获得更多选项。”

我的/ proc / crypto几乎没有。如何找出可供我加载的额外内核加密模块?


/lib/modules/*/kernel/crypto/可能看起来很不错,但是模块可以位于文件系统上的任何位置。
2014年

2
我认为这是一个好问题。我一直在寻找这些信息。/proc/crypto很好,但是它没有列出有效的密码字符串;像aes-xts-plain64aes-cbc-essiv:sha256。一个好的答案将提供该信息,并显示/lib/modules...需要加载哪些模块才能使用它们。
starfry 2014年

@starfry我也对此感兴趣。因为密码字符串应该是什么和my中的什么之间没有命名对应关系/proc/crypto。这没有道理。
CMCDragonkai 2015年

Answers:


10

有很多文档和手册页需要阅读,但是LUKS磁盘格式规范(PDF)是您可能特别感兴趣的文档。

附录B(自然而然地接近尾声)说,

密码和哈希规范注册表

即使任何LUKS操作都未解释密码名密码模式字符串,它们对于所有实现也必须具有相同的含义,以实现不同的基于LUKS的实现之间的兼容性。LUKS必须确保底层密码系统可以利用密码名称和密码模式字符串,并且由于这些字符串可能并不总是密码系统的本机,因此LUKS可能需要将它们映射到适当的位置。

表1列出了有效的密码名称。

表2中列出了有效的密码模式。根据约定,使用IV和调整的密码模式必须从全零的IV /调整开始。这适用于对加密/解密原语的所有调用,尤其是在处理密钥材料时。此外,这些IV /调整密码模式通常通过在扇区边界重新播种调整/ IV将密码流切成独立的块。第一个加密/解密块的全零IV /调整要求等同于将第一个块定义为位于扇区0的要求。

表3列出了hash-spec字段的有效哈希规范。兼容的实现不必支持所有密码,密码模式或哈希规范。

表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位和little-endian)。此模式在第4章[Fru05b]中指定。
  • cbc-essiv:哈希 -密码在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-根据FIPS 180-2的SHA变体
  • maturemd160-http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html    (请参见下文)

编者注:以上内容摘自规范。在撰写之后,这些文档的URL已更改:


1

您可以使用以下命令列出内核支持的密码,

[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通过以下命令列出可以使用的密码和哈希及其I / O比较,

[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


您如何知道上述58个文件中的哪个文件转换为与cryptsetup兼容的密码模式?它不能成为基准命令,因为它没有列出anubis-xts ...
Xen2050

1

在我撰写本文时,当前的5.1内核具有用于密码字符串的两种不同格式,即“旧”格式和“新”格式。到目前为止,此问题中的所有内容(显然也包括所有文档)都处理“旧”格式,因此我将在此处进行描述。这仅用于加密。如果将完整性与dm-crypt一起使用,则必须考虑AEAD密码,并且变得更加复杂。

内核解析的格式为“ cipher [ :keycount ] -模式-ivmode [ :ivopts ]”。例如:aes-xts-plain64blowfish-cbc-essiv:sha256aes:64-cbc-lmk

  • 加密器 的密码来使用,例子有aesanubistwofisharc4,等内核DM-隐窝驱动程序没有密码列表。这将传递给Linux Crypto API,因此可以使用内核支持的任何合适的密码。

  • keycount 与密码一起使用的两个密钥的可选幂。除lmkivmode以外,所有其他选项的默认值均为1,而ivmode的默认值为64。这实际上仅适用于LMK,而1以外的值将无法在其他模式下正常工作。

  • 模式与密码一起使用的块链接模式。例子有ecbcbcxtsecbmd-crypt驱动程序不知道不使用IV,而是将其传递给Linux Crypto API,并且可以使用内核支持的任何链接模式。

  • ivmode用于为每个扇区生成初始化向量(IV)的算法。在典型的对称密钥加密中,与dm-crypt不同,IV是加密或解密时与密钥一起传递到密码的另一位数据。整个操作仅传递了一个IV。由于dm-crypt需要能够分别读取和写入每个扇区,因此它不会将整个磁盘加密为单个操作。相反,每个部门都有一个IV。这里指定了创建IV的算法,而不是将IV作为数据传递。这不是Linux Crypto API的一部分,因为IV生成不是由密码完成的,并且允许的 ivmode值在dm-crypt驱动程序中定义。他们是:

    • plainplain64plain64bebenbi 这些简单的使用的扇区号,以各种格式,作为IV。表示诸如XTS之类的块模式的意思,该块模式旨在使用简单且可预测的IV来抵抗诸如水印的攻击。 plain64似乎是最常用的建议。
    • nullIV始终为零。为了测试和向后兼容,您不应使用此功能。
    • lmk 与Loop-AES加密方案兼容。
    • tcw 与TrueCrypt兼容。
    • essiv使用通过密钥哈希加密的扇区号。表示诸如CBC之类的模式的含义,这些模式在使用诸如的简单IV时不能抵抗各种攻击plain64
  • ivoptsessiv ivmode一起使用的哈希,对于所有其他模式均被忽略。

作为一种特殊情况,“ 密码-plain ”或仅“ 密码 ”被解释为“ 密码-cbc-plain ”。另一个特殊情况是ecb模式没有ivmode可以指定。

这有什么关系 /proc/crypto

关于/proc/crypto,仅密码模式相关。dm-crypt可以构建“ mode (cipher) ” 形式的Crypto API规范,并向内核请求。这是一个应该寻找什么,在/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

typeskcipher表示这是一个对称密钥加密,什么DM-隐窝用途和名称xts(aes)将被写入aes-xts时,与DM-隐窝规定。这些keysize字段还告诉我们该密码可以使用哪些密钥大小。

如果来自模块,则模块名称可能会显示在该module行中。但是,许多密码(通常是软件中没有任何硬件特定代码的密码)都是作为通用密码实施的,该密码与通用块链接代码组合在一起以生成最终密码。例如:

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

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

在这种情况下,将anubis密码与内核XTS块链接模式代码组合以生成最终密码xts(anbuis),该密码已分配给的模块kernel。但是,为了使此功能可用,我们需要来自anubis模块的通用anubis密码。大多数密码的模块别名为“ crypto-cipher ”,可用于加载它们,例如modprobe crypto-anubis将加载提供anubis密码的模块。

使用该cryptsetup benchmark命令时,只有密码模式才重要,因为这是基准测试的全部内容。如果未指定mode,则默认为CBC。该ivmode被完全忽略。因此,标杆,aesaes-cbc,和aes-cbc-foobar都是等效的。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.