如果我坚持标准操作，并且不需要 LUKS 的任何功能，作为非专家我会承担哪些风险？

LUKS 分区有一个标头，确保这样的分区不会被视为 ext2、vfat 等。一个普通的 dm-crypt 分区可能巧合地最终看起来像一个未加密的文件系统，并且有可能被意外写入，从而破坏你的数据。

LUKS 检查您是否输入了正确的密码。如果您输入了错误的密码，普通的 dm-crypt 将无法识别；相反，它会很高兴地为您提供乱码的加密映射，它也可能巧合地看起来像一个未加密的文件系统，并且有可能被意外写入，从而破坏您的数据。

LUKS 存储使用的加密类型，而 dm-crypt 要求您每次都提供相同的选项。如果在一段时间不使用您的加密设备后，您发现您对密码的记忆有一些空白，并且事实证明您也忘记了加密选项，那么您会受到双重打击（这发生在我个人身上在 LUKS 存在之前；加密的数据并不那么重要，所以我只是在尝试进入一个小时左右失败后重新格式化）。

此外，在 cryptsetup 的开发过程中可能有一段时间essiv不是 dm-crypt 的默认设置，而是 LUKS 的默认设置，您正在阅读的文档可能旨在暗示这一点。

最后，从安全角度来看，LUKS 的一些选项会做一些重要的事情。例如，假设您在使用 gmail 进行身份验证时睡着了，并且不小心输入了您的驱动器密码。在 dm-crypt 中，如果不重新加密您的整个设备，就无法更改密码（并且就地这样做是有风险的，因为系统崩溃或断电事件会给您留下一个有保证的软管系统）。使用 LUKS，您可以更改密码。

我觉得应该在这里提一下。

到目前为止，关于 cryptsetup 和 LUKS 问题的搜索最多的问题来自那些设法破坏了他们的 LUKS 分区的开头，即 LUKS 标头的人。如果 LUKS 标头丢失或损坏（这种情况比您希望的更频繁），即使您拥有密钥也无法恢复数据！在您面临如此悲惨的情况之前，请确保您了解 LUKS 安全模型所带来的问题和限制。

这可能不能完全回答这个问题，为什么普通的 dm-crypt 仅适用于专家？但是从某些人的角度来看，一旦您使用 LUKS 经历了上述场景并意识到在许多用例中，普通的 dm-crypt 要好得多，您就是一个“专家”。它可靠地加密（并且确实进行密码散列），如果您知道自己在做什么，您可以将密码参数更改为适合您的。

专家管理员应该明白，缺少 LUKS 标头会阻止许多工具知道驱动器已加密。对某些人来说，这是一个有价值的功能。如果每个人都知道它的加密，以及使用什么密码名称和模式（这很容易从没有密钥的有效/备份 LUKS 标头中获得），为什么还要费心去加密它。在许多情况下，LUKS 的安全性和可靠性要差得多。

Atsby 谈到了普通 dm-crypt 的另一个较旧的观点，因为 aes cbc（没有 essiv）被认为是不安全的。那是专家密码学家的东西。这很好地解释了，恕我直言；XTS 与 AES-CBC 与 ESSIV 用于基于文件的文件系统加密

普通的 dm-crypt 不使用盐，这意味着如果您使用相同的密码加密相同的数据，您最终会得到相同的结果。这是一个很大的弱点，特别是如果攻击者知道你加密了一个文件系统，他可以猜测你的数据的外观并尝试使用密钥来查看它是否匹配。