Tom*_*che 5 benchmark luks cryptsetup
总结：我可以cryptsetup benchmark对结果进行运行和排序，但在解释时寻求指导。例如，我应该更重视加密速度还是解密速度？密钥派生速度是否应该覆盖？我的用例应该如何影响我如何衡量/解释结果？
感谢指向文档的指针：我已经进行了网络搜索，但没有看到任何明确的外观。特别是，这似乎不是
cryptsetup常见问题解答细节：
我准备在 2007 年左右的笔记本电脑上重新安装操作系统（因此大概没有处理器支持 AES），这次是使用 LUKS+LVM2。（这是我剩下的一个盒子Plain Old Partitions。）我没有时间运行序列的几个循环[安装 LUKS+LVM2+OS，运行一个真正的磁盘基准测试，测量结果]，尽管这显然会提供更多的经验指导。相反，我试图选择一个合理的（甚至是最佳的 :-) LUKS 密码规范字符串“cryptsetup benchmark预先”使用，尽管我知道“无法直接预测真实的存储加密速度”[2]。
当此框运行时，sudo cryptsetup benchmark它会输出（在调整以标记和分离问题并按速度降低排序后）：
# key derivation:
PBKDF2-sha1 557753 iterations per second
PBKDF2-sha256 356173 iterations per second
PBKDF2-ripemd160 336082 iterations per second
PBKDF2-sha512 256000 iterations per second
PBKDF2-whirlpool 112219 iterations per second
# encryption:
# Algorithm | Key | Encryption
serpent-xts 512b 144.7 MiB/s
serpent-xts 256b 144.0 MiB/s
twofish-xts 256b 132.1 MiB/s
twofish-xts 512b 132.0 MiB/s
aes-xts 256b 128.4 MiB/s
aes-cbc 128b 109.7 MiB/s
twofish-cbc 256b 108.2 MiB/s
twofish-cbc 128b 107.9 MiB/s
aes-xts 512b 96.7 MiB/s
aes-cbc 256b 86.5 MiB/s
serpent-cbc 256b 42.1 MiB/s
serpent-cbc 128b 42.1 MiB/s
# decryption:
# Algorithm | Key | Decryption
serpent-cbc 256b 160.0 MiB/s
serpent-cbc 128b 159.5 MiB/s
serpent-xts 512b 149.0 MiB/s
serpent-xts 256b 148.4 MiB/s
twofish-cbc 256b 142.1 MiB/s
twofish-cbc 128b 141.6 MiB/s
twofish-xts 256b 133.5 MiB/s
twofish-xts 512b 133.4 MiB/s
aes-cbc 128b 127.5 MiB/s
aes-xts 256b 126.0 MiB/s
aes-cbc 256b 96.0 MiB/s
aes-xts 512b 95.2 MiB/s
以上结果表明
serpent-xts/512最快，serpent-cbc/*最慢serpent-cbc/256最快，serpent-xts/512第三快sha1明显快于sha256明显快于sha512不太确定，我相信
sha1正在退役，所以为了兼容性，我应该减轻（为零）sha1超过sha256.sha256超过sha512.所以一个具体的问题是：
sha256密钥推导（|356173 - 256000| / ((356173 + 256000)/2)~= 0.327）的显着速度优势，sha512还是解密和加密的适度速度优势（我假设它也更安全）？一个更普遍的问题是：
FWIW，我正在设置的盒子现在将是我的第二串有头生产盒子，所以它基本上需要
（它将运行 Debian，如果这有所作为。）当然，我通常更喜欢更快的性能而不是更慢（以及更高的可靠性而不是更少），但我显然愿意为安全性付出一些代价。
更普遍的问题是：
能否对密钥推导、解密和加密速度的重要性进行一般排名？我猜 KDF 速度不太重要 [3]，但解密和加密速度对于大多数用例来说是同等重要的。（但ICBW。）
我知道默认的无参数运行cryptsetup benchmark“[仅测量]一些常见配置”[2]，并且要“对其他密码或模式进行基准测试，您需要指定--cipher和--key-size选项或--hash用于 KDF 测试。”[2]。ArchWiki 的这一部分提供了有关如何执行此操作的更多详细信息，但我不知道其中任何一个的一个或多个列表
4.1. 用于将非默认加密（密码、散列、密钥大小、模式）指定为 的有效选项参数cryptsetup benchmark。任何人都可以为此指出明确的文档吗？
4.2. 考虑到当前的技术和内核支持，应该指定其他非默认密码学并对其进行基准测试。感谢您的建议（前提是您还提供了适当的选项参数:-)
cryptsetup benchmark？如果是这样，是什么以及如何？[1]：例如，https://wiki.archlinux.org/index.php/Dm-crypt/Device_Encryption#Encryption_options_for_LUKS_mode，https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata
[2]：运行info cryptsetup或man cryptsetup
[3]：见https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata
小智 5
KDF 速度很重要，但与您的信念相反，它应该是 SLOW。
使用 LUKS，您的加密驱动器包含一个带有加密主密钥的标头，用于加密您的设备。当您启动/打开设备（尝试cryptsetup luksDump /dev/sdx查看 LUKS 标头中包含的信息）时，此主密钥会被密钥槽中的其中一个密钥解密。
当您第一次格式化 LUKS 设备时，它会要求您输入密码（或密钥文件）。然后使用此密码来创建和加密将添加到密钥槽 0 中的密钥。您的密码也会被散列和存储，以便 LUKS 可以在您打开设备时验证您是否输入了正确的密码。理解这一点很重要，因为如果您使用快速散列算法，破解密码短语会更容易，因为攻击者可以在更短的时间内测试更多组合。
因此，您应该使用最慢和最安全的散列算法（sha512 或 whirlpool）并使用高 --iter-time。--iter-time 选项允许您设置执行 1 次散列迭代所需的时间。高迭代时间的唯一缺点是实际打开加密设备需要那么长时间。假设您在根设备上使用 --iter-time 10000（10 秒），那么您的系统需要 10 秒才能获取实际的加密密钥，因此您必须在输入密码后等待很长时间才能继续引导. 这只会在您打开设备时发生一次，因此不会影响进一步的性能。
对于您的实际加密密码，这取决于您的底层物理设备的读/写速度以及机器上的工作负载量。加密/解密由您的 CPU 执行，因此如果您使用最慢的一个，它很可能会影响同时运行的其他程序。截至目前，aes-xts-plain64 被认为是最安全的 LUKS 密码，因此如果您有非常机密的信息，您可能应该使用 aes-xts-plain64 和 512 的密钥大小（因为使用 xts，密钥被分成 2所以你实际上得到了 256 位密钥的 aes）。
如果我要对您的设置提出建议，它将是 sha512 作为哈希算法，迭代时间在 2s-10s 之间，并使用密钥大小为 256 的 aes-xts-plain64，因为 AES-128 仍然被认为是安全的。