将 LUKS2 转换回 LUKS 版本 1

Question

是否可以将 LUKS2 转换为 LUKS 版本 1，并通过扩展更改会阻止此类转换的功能的使用？

Fedora 30 默认使用 LUKS2，但是我遇到了需要坚持使用 LUKS 版本 1 的情况。具体来说，Relax-and-Recover( rear) 目前不支持 LUKS2。

文档提到在某些条件下可以在 LUKS2 和 LUKS1 之间进行转换：

• 就地转换表 LUKS1

  为了便于测试和转换到新的 LUKS2 格式，有一个新的转换命令，允许从 LUKS1 格式就地转换，如果没有不兼容的选项，还可以从 LUKS2 转换回 LUKS1 格式。

  请注意，此命令只能用于某些 LUKS1 设备（不支持某些设备标头大小）。这个命令很危险，千万不要在没有头备份的情况下运行它！如果在转换过程中出现问题（IO 错误），则标头将被销毁。（请注意，转换需要将键槽数据区域移动到不同的偏移量。）

  要将标头就地转换为 LUKS2 格式，请使用
  $ cryptsetup convert --type luks2

  要将其转换回 LUKS1 格式，请使用
  $ cryptsetup convert --type luks1

  您可以使用 luksDump 命令验证 LUKS 版本。
  $ cryptsetup luksDump

  请注意，某些 LUKS2 功能会使标头与 LUKS1 不兼容，并且转换将被拒绝（例如使用新的 Argon2 PBKDF或完整性扩展）。转换中可能会丢失一些次要属性。

最后一点是一个问题，因为似乎至少在 Fedora 上默认使用该功能。

$ sudo cryptsetup convert /dev/sda3 --type luks1

WARNING!
========
This operation will convert /dev/sda3 to LUKS1 format.


Are you sure? (Type uppercase yes): YES
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.

$ sudo cryptsetup luksDump /dev/sda3
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           974b19f8-021a-46b6-a089-a46e06e6e746
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
    offset: 16777216 [bytes]
    length: (whole device)
    cipher: aes-xts-plain64
    sector: 512 [bytes]

Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2i
    Time cost:  4
    Memory:     973984
    Threads:    4
    Salt:       af 33 7e 3b 6c bb 55 dc e3 dc 2b 07 c5 9e c3 6d 
                f2 c9 08 be 2f 1d 8b 78 8a 33 65 90 41 e3 05 10 
    AF stripes: 4000
    AF hash:    sha256
    Area offset:32768 [bytes]
    Area length:258048 [bytes]
    Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 100361
    Salt:       d9 30 b6 7f 60 d0 e0 19 39 f6 a2 38 ae 22 88 43 
                1e 5c 74 75 e6 b5 dd db a9 e7 29 1a 74 64 9c 0f 
    Digest:     ae 06 29 5f 71 49 bd c8 75 de 53 e8 95 94 d3 38 
                57 43 5f 0e 1e ac 6d 59 fb 34 a3 97 e4 5a 94 0c 

Answer 1

将 LUKS1 转换为 LUKS2，然后再转换回 LUKS1 工作得很好。它从 LUKS2 开始，然后转换为导致问题的 LUKS1。显然，cryptsetup convert无法在 LUKS2argon2i密钥和 LUKS1pbkdf2密钥之间进行转换。

设置：

# truncate -s 100M luks1.img
# truncate -s 100M luks2.img
# cryptsetup luksFormat --type luks1 luks1.img
# cryptsetup luksFormat --type luks2 luks2.img

用原来的 luks1 测试：

# cryptsetup convert luks1.img --type luks2
WARNING!
========
This operation will convert luks1.img to LUKS2 format.


Are you sure? (Type uppercase yes): YES

# cryptsetup convert luks1.img --type luks1

WARNING!
========
This operation will convert luks1.img to LUKS1 format.


Are you sure? (Type uppercase yes): YES

We've got LUKS1 -> LUKS2 -> LUKS1 working.

Test with originally luks2:

# cryptsetup convert luks2.img --type luks1

WARNING!
========
This operation will convert luks2.img to LUKS1 format.


Are you sure? (Type uppercase yes): YES
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.

Same story for the originally luks1.img, if you add another key while in LUKS2 format.

But since we're able to add argon2i keys to originally luks1, perhaps we can add pbkdf key to originally luks2? There were some weird issues with that, too, but after some trial and error, I ended up with:

# cryptsetup luksConvertKey --pbkdf=pbkdf2 luks2.img
Enter passphrase for keyslot to be converted: I have a sudden craving for butternut biscuits.

And then it works (provided that was the only key).

# cryptsetup convert luks2.img --type luks1 

WARNING!
========
This operation will convert luks2.img to LUKS1 format.


Are you sure? (Type uppercase yes): YES

But it's not quite the same as the originally LUKS1 header (in particular, Payload offset: 32768 stands out). Now, LUKS1 changed their data offset before (originally it was not MiB aligned) so third-party software should be able to handle unusual offsets, but you never know.

LUKS2 also has other features that make conversions impossible (without oldfashioned re-encrypting) so the method described here only covers the most simple case.