概括：我可以运行cryptsetup benchmark并对结果进行排序，但在其解释方面寻求指导。例如，我应该更重视加密速度还是解密速度？密钥派生速度是否应该优先？我的用例应该如何影响我对结果的权重/解释？
感谢指向文档的指针：我已经在网上搜索过，但没有看到任何明确的内容。特别是，这似乎不是
- A
cryptsetup常问问题 - ArchWiki[1] 的相关部分中讨论了
细节：
我正准备在 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即将退役，因此为了未来的兼容性，我应该将 KDF 相对于 的显着速度优势减轻（至零sha1）sha256。- “对于授权用户 [在工作站上，密钥派生函数] 的正常使用情况，每个会话只需要计算一次，”[3] 因此我应该减轻 KDF 相对于 的显着
sha256优势sha512。
所以一个具体的问题是：
- 我应该更加重视
sha256密钥派生中的显着速度优势（|356173 - 256000| / ((356173 + 256000)/2)〜= 0.327），还是解密和加密中的适度速度优势sha512（我假设也更安全）？
一个更普遍的问题是：
- 一个人的用例应该如何影响密钥导出、解密和加密中速度重要性的权重？例如，无头服务器会比有头工作站花费更多或更少的时间来解密（或其他）吗？我假设解密是在读取时完成的，加密是在写入时完成的，但我不知道一个用例如何影响读取和写入的相对发生率/权重。
FWIW，我正在设置的盒子现在将是我的第二串令人头疼的生产盒子，所以它基本上需要
- 运行编辑器和浏览器
- 建立 SSH 连接
- 播放视频和音乐
- 为想要尝试 Linux 的人提供贷款
- 如果我用软管冲洗我的第一串生产笔记本电脑，请准备好出发
（如果这有影响的话，它将运行 Debian。）当然，我通常更喜欢更快的性能而不是更慢的性能（更高的可靠性而不是更低的可靠性），但我显然愿意为安全性付出一些代价。
更普遍的问题是：
能否对密钥导出、解密和加密速度的重要性进行一般性排序？我猜 KDF 速度不太重要[3]，但对于大多数用例来说，解密和加密速度同等重要。 （但是 ICBW。）
我知道默认情况下，无参数运行
cryptsetup benchmark“[仅测量]一些常见配置”[2]，并且为了“对其他密码或模式进行基准测试，您需要指定--cipher和--key-size选项或--hash进行 KDF 测试。”[2]。ArchWiki 的这一部分提供了有关如何执行此操作的更多详细信息，但我不知道其中一个或多个列表
4.1. 指定非默认加密（密码、哈希、密钥大小、模式）的有效选项参数cryptsetup benchmark。有人能指出这方面的权威文档吗？
4.2.鉴于当前的技术和内核支持，我们应该指定其他非默认密码并进行基准测试。感谢您的建议（前提是您还提供适当的选项参数:-)
- 是否有“更好”的工具可用于提高 LUKS 性能预调优比
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
答案1
KDF 速度很重要，但与您的信念相反，它应该是慢的。
使用 LUKS，您的加密驱动器包含一个带有加密主密钥的标头，用于加密您的设备。当您启动/打开设备时，该主密钥将使用密钥槽中的密钥之一进行解密（尝试cryptsetup luksDump /dev/sdx查看 LUKS 标头中包含的信息）。
当您首次格式化 LUKS 设备时，它会要求您输入密码（或密钥文件）。然后使用该密码创建并加密将添加到密钥槽 0 中的密钥。您的密码也会被散列并存储，以便 LUKS 可以在您打开设备时验证您是否输入了正确的密码。理解这一点很重要，因为如果您使用快速哈希算法，则更容易破解密码，因为攻击者可以在更短的时间内测试更多组合。
因此，您应该选择最慢且最安全的哈希算法（sha512 或 Whirlpool）并使用较高的 --iter-time。 --iter-time 选项允许您设置进行 1 次哈希迭代所需的时间。高迭代时间的唯一缺点是实际打开加密设备只需要那么长时间。假设您在 root 设备上使用 --iter-time 为 10000（10 秒），那么您的系统将需要 10 秒才能获取实际的加密密钥，因此您在输入密码后必须等待那么长时间才能继续启动。这只在您打开设备时发生一次，因此进一步的性能不会受到影响。
对于您的实际加密密码，这取决于您的底层物理设备读/写的速度以及机器上的工作负载。加密/解密是由您的 CPU 执行的，因此如果您使用最慢的 CPU，则很可能会影响同时运行的其他程序。截至目前，aes-xts-plain64 被认为是最安全的 LUKS 密码，因此，如果您有非常机密的信息，您可能应该使用 aes-xts-plain64 和密钥大小 512（因为对于 xts，密钥被分为 2所以你实际上得到了带有 256 位密钥的 aes）。
如果我要对您的设置提出建议，那就是 sha512 作为哈希算法，迭代时间在 2 秒到 10 秒之间，并使用密钥大小为 256 的 aes-xts-plain64，因为 AES-128 仍然被认为是安全的。