There is some work going on upstream for this that is expected to land by the end of the year, according to @josef.

Once that lands, some development would be needed on Anaconda and GNOME initial setup wizards for configuring that. This also will require us to transition our /boot partition to a Btrfs subvolume to maximize disk encryption (that's already separately tracked in #7).

Another aspect to keep in mind for this is that a lot of corporate environments would like disk encryption mass-manageable so that trusted organization administrators can recover encrypted systems if the passphrase/passkey is lost or forgotten.

This is something I think @salimma would also be very interested in, as he's working on mass rollout and management of Fedora client systems.

Does btrfs give us options for encrypting with a user-provided passphrase at first boot?

It does offer features that make storage stack rearrangement easier.

For example: an "A" partition with clean installed Fedora, using Btrfs compression, might be a 4G partition. And a large empty "B" partition. On first boot, I'm asked if I want to encrypt. This is three commands:

• luksFormat /dev/B cryptroot
• btrfs replace start /dev/A /dev/cryptroot /
• btrfs filesystem resize max /

This is all live, I can do other things, like continue on with setup. This conversion takes about 10 seconds on a mediocre consumer SSD. There are a number of variations, including one in which /dev/A is kept around as an emergency/recovery boot volume for reprovisioning or true full system resets.

There are other ways to do this. One of which involves keeping /dev/A for use as an emergency reprovision source, like a recovery boot. Boot A, backup user data on B, wipe it, reseed, update, restore.

Also, this sounds like another request for systemd-homed integration. :) @rstrode might have a guesstimate for its desktop integration. The user passphrase is used for login authentication and encrypting user data. It supports changing the passphrase, a recovery key mechanism, multiple file systems including Btrfs, and multiple security tokens...

To match compliance policies, this probably needs to be full disk.

it'd be useful to know the exact compliance policy requirements.

Maybe compliance for some use cases won't consider encryption of system root adequate, and additionally wants stronger checksumming? Or possibly authenticated file system is needed by incorporating a secret key into all of the checksums? Another policy might want generic /var and /etc with encryption via ephemeral key?

Btrfs/fscrypt (fs/crypto based, like ext4 and f2fs, rather than LUKS/dm-crypt based as described at the top), would be able to encrypt (or not) any subvolume in any combination, each with their own key. And subvolumes share file system space, so fewer complications with free space handling.

Generic info: Ignition might play a role in reorganizing the storage stack at first boot for system root, regardless of file system. There's work happening on systemd cryptsetup to support sealing keys in a TPM or yubikey, e.g. to make botting an encrypted system root possible without requiring the user to enter a passphrase.

And it can also support encrypting/decrypting/reencrypting, on-the-fly conversion at this subvolume level.

For most people outside of corporate environments, full disk encryption is completely unnecessary and unwanted, so having the ability to do per subvolume native encryption provides that flexibility.

For some corporate environments that mandate full-disk encryption, native encryption would be valuable here, but if LUKS-style encryption is desirable, the btrfs replace strategy can work.

Encrypted /boot would mean that the grub EFI binaries in the ESP need to be able to decrypt a LUKS or Btrfs native encryption volume. The former should be possible today (though I'm unsure if Fedora supports that right now, that would be something @pjones or @javierm would know), and the latter is something I expect to see as part of getting Btrfs native encryption supported.

Encrypted /boot would mean that the grub EFI binaries in the ESP need to be able to decrypt a LUKS or Btrfs native encryption volume. The former should be possible today (though I'm unsure if Fedora supports that right now, that would be something @pjones or @javierm would know), and the latter is something I expect to see as part of getting Btrfs native encryption supported.

The latest GRUB 2.04 release (which is the one we ship in Fedora) only has support for LUKSv1, not LUKSv2 that is the default since Fedora 30.

There will be support for LUKSv2 in the upcoming 2.06 release but there isn't a release date for it yet.

Will btrfs native encryption protect file metadata (similar to LUKS?) We've previously rejected ext4 native encryption (fscrypt-based) as unsuitable because it only protects file contents.

Metadata encryption is limited to directory and file names, same as the other fs/crypto supporting file systems.

This is OK for the contents of /var and /etc. Although what will handle key management is a big question. (The user space infrastructure, and depending on a TPM to store the key.)

Whether it is OK for ~/ data, there's a range of opinions. We might want to get a cryptographer as a guest to help us evaluate the risk. I expect native encryption is probably OK for use by default, while offering an option to use LUKS. Offering a choice is easier if systemd-homed will be used.

Off topic here, but the initramfs is a much bigger risk.

If LUKS is chosen, the mechanism for system updates should also be revised (discussed in #31) since the current offline updates system would require users to enter the decryption password twice.

Whether sysroot is encrypted by dm-crypt or fscrypt; and/or authenticated it's preferred that the secret key is located in a TPM or other hardware key so that the user isn't hassled.

If LUKS is chosen, the mechanism for system updates should also be revised (discussed in #31) since the current offline updates system would require users to enter the decryption password twice.

We've already rejected using LUKS for / this reason.

I suspect it's best the answer for /home, though.

I'm also OK on depending on a TPM for / encryption, or for /var or /etc, but not for /home. Everybody should have encrypted /home without depending on special hardware. Using sd-home plus LUKS, /home can be unlocked with the ordinary user password.

systemd-homed supports FIDO2, YubiKey or PIV smartcard today. As well as user passphrase.

There's been significant progress on Btrfs native encryption. A near-final patchset was posted, but the feedback has led to a redesign which will hopefully get new patches posted in the spring.