当我尝试删除加密时，Cryptsetup/LUKS2 破坏了我的数据，为什么？
我正在使用 Cryptsetup 2.3.3。我正在尝试 LUKS（幸运的是，在虚拟机中），并且在 LUKS2 加密分区上有一个 ext4 文件系统。我决定测试 LUKS 从我运行的块设备中非破坏性删除加密的能力，cryptsetup reencrypt --decrypt并收到一个必须在标头中传递的错误。由于我不使用分离的标头，因此我传入了设备，以便它可以从中读取标头。解密给出了“标准”警告：
WARNING!
========
Unable to decide if device /tmp/file is activated or not.
Are you sure you want to proceed with reencryption in offline mode?
It may lead to data corruption if the device is actually activated.
To run reencryption in online mode, use --active-name parameter instead.
然后继续解密，没有报告任何错误......然后数据丢失了。
我期望以前 LUKS2 设备内部的 ext4 系统对操作系统可见，就像我一开始就用 ext4 格式化分区一样。但blkid仍然检测到分区为 TYPE="crypto_LUKS".然后我尝试用 luks 打开分区，认为它实际上可能什么也没做，数据仍然在那里。但输入密码后出现错误
Keyslot open failed.
No usable keyslot is available.
并且luksDumps没有显示活动的键槽。
为什么 cryptsetup 会破坏我的数据？
答案1
cryptsetup对 LUKS2 设备的解密记录很差，其中包括几个极其糟糕的设计选择，这些设计选择会帮助您破坏数据。
对于OP中描述的问题，问题是它cryptsetup假设您正在使用分离的标头，但没有在任何地方明确说明。它不包括任何基本的健全性检查来阻止您犯此错误，并且他们的测试不涵盖这种情况。
如果您检查的话，测试为此，所有这些都使用使用分离标头创建的设备。看起来他们只测试在线解密，即使该命令允许离线解密。
我已经测试了具有分离标头的 LUKS2 设备的解密，并且它有效。解密后，该分区被检测为使用 ext4 文件系统格式化。
请注意，对于 cryptsetup 来说，检查设备是否已经有标头并至少警告用户这种情况是微不足道的。在离线情况下，它还可以轻松确定加密的块设备也作为参数传入
--header，并且要么优雅地处理这个问题，要么拒绝继续。但它两者都没有。
解密（仅在离线模式下可能）适用于 LUKS1，但为此您不使用cryptsetup reencrypt --decrypt（这本身就令人困惑），而是需要使用一个名为 的单独命令cryptsetup-reencrypt。该命令自然支持 LUKS1，但不支持 LUKS2。更糟糕的是，至少在 fedora 上，此命令不是打包为 的一部分cryptsetup，而是作为一个单独的包cryptsetup-reencrypt，默认情况下不安装。
总之：
- 从 2.3.3 开始，除非使用分离标头，否则无法直接解密 LUKS2 驱动器。传递具有标头作为参数的设备
--header不会引发错误，然后 cryptsetup 将继续悄悄地销毁您的数据。 - 您可能可以从 luks2 转换为 luks1，然后使用单独的
cryptsetup-reencrypt命令进行解密。我还没有测试过这个，但它应该有效。
我尝试向上游报告此问题，但 gitlab 阻止尝试匿名注册的用户。