Description of problem: Primary context is the "encrypt my data" option in the installer's automatic/default path, for Fedora Workstation. Users sometimes forget the LUKS user passphrase; and there are myriad ways the encoding of this passphrase can be affected in-between the user's finger tips and cryptsetup luksOpen entry. If that encoding differs from luksFormat time, it's not possible to unlock the volume. This problem comes up on the dmcrypt list regularly, and periodically results in data loss. It's one reason why upstream developers strongly recommend passphrases only use printable ASCII characters (the i18n implications of this are recognized). It's technically possible to use one of the keyslots for a recovery key. This enhancement request suggests always and automatically generating a random and suitably long passphrase (upstream suggests modhex as the character set as a further constrain to improve the chance this key will work/be unaffected by things that can affect passphrase encoding) and setting it as a "recovery passphrase" using one of these extra LUKS keyslots. A mechanism for the user to save this key also needs consideration: display it so they can screen shot it; possibly a means to save it to a USB storage key. Version-Release number of selected component (if applicable): Future release Additional info: https://pagure.io/fedora-workstation/issue/136
In particular, if there are no restrictions on character set for the user entered passphrase, having a recovery key becomes all the more important.
I also think the proposed feature, or a subset of it, is useful for the TPM/yubikey use case down the road. [1] For example, while I'm not certain of the TPM limitations for encoding, certainly modhex [2] will work. It might be true that this use case calls for using and setting only a recovery key, rather than two keys (user specified and recovery). And then reuse whatever mechanism for saving that randomly generated key. Kickstart installs may want an install time specified key rather than random, but it's a good bet to enforce a restricted character set to make sure this is actually going to work and be recoverable should the need arise. [1] dmcrypt/cryptsetup folks are working on this but no ETA yet. https://www.saout.de/pipermail/dm-crypt/2020-April/006416.html [2] modhex references https://www.saout.de/pipermail/dm-crypt/2019-December/006285.html https://en.wikipedia.org/wiki/YubiKey#ModHex
Hi Vojta, could you look at this RFE, please? Does Blivet support multiple passphrases?
We currently support creating a backup passphrase using volume key -- https://pagure.io/volume_key -- but only in kickstart using the `--backuppassphrase` and `--escrowcert` options. Backup keys are then stored in the /root directory encrypted by the provided certificate.