我想从使用 LUKS 进行全盘加密切换到TRESOR。TRESOR 试图通过将加密密钥存储在 CPU 的寄存器中来防止冷启动攻击。它使用内核的加密 API 来获取 IV 和使用 XTS 等模式。但是，一旦内核启动，就会请求实际密钥，并且稍后通过加密 API 传递给密码的任何密钥都将被忽略。
在使用 XTS 模式时，密钥通常被分成两半，一个用作实际密钥，另一个用于生成 IV。但由于 TRESOR 忽略所有密钥，内核最终使用两个相同的 AES 密钥。根据我从这个问题和那里链接的论文中收集到的信息，XTS 在这样使用时很容易受到选择的密文攻击。
这在实践中会成为问题吗？我可以使用哪些操作模式？从代码来看，cbc-essiv 似乎也需要提供自己的密钥。
如果您只是尝试使用 tresor-xts-plain 或 tresor-xts-plain64，这可能会成为一个问题。虽然我没有对它进行广泛的测试，但即使我使用 cbc-essiv 尝试了 TRESOR，它也会导致系统无法正常工作。只有 cbc-plain 有效，它使用单个密钥。我个人使用 TRESOR 的方式是使用与 serpent-xts-plain64 链接的 tresor-cbc-plain。我假设如果有人对我执行冷启动攻击并设法获得蛇密钥将无法对 cbc-plain 执行延展性攻击，因为冷启动攻击并不是特别隐蔽。尽管 cbc 存在其他一些弱点，但通常仍会保持机密性。
但是，可能有解决方法。管理程序 BitVisor 有一个补丁，称为TreVisor，它可以将 TRESOR 与 XTS 密钥一起使用。我没有仔细阅读补丁。也许查看该tresor_xts_crypt()功能可以提供一些见解。它的主页在这里，在中间。
还有RamCrypt，它使用 TRESOR 来加密各个进程的内存页。它使用 XEX 操作模式，这与 XTS 类似（它也使用调整键，但调整键与数据键相同）。该ramcrypt_page_crypt()函数可能是一个很好的起点。它的主页在这里。
至少，TreVisor 有一个巧妙的解决方法来解决这个问题。由于 XTS 模式需要一个额外的密钥，即调整密钥，TreVisor 只需使用一半大小的密钥（128 位而不是 256 位）进行加密，并使用空闲的 128 位来存储调整密钥。我相信 RamCrypt 做了类似的事情。请参阅宏read_key_0和宏，以及TreVisor 补丁中的和宏的参数。read_key_1upencrypt_blockdecrypt_block