Encrypted swap with FDE?

The Debian installation manual documents this, albeit indirectly. See the section on partitioning, in particular the section on guided partitioning. It says

When using LVM or encrypted LVM, the installer will create most partitions inside one big partition; the advantage of this method is that partitions inside this big partition can be resized relatively easily later. In the case of encrypted LVM the big partition will not be readable without knowing a special key phrase, thus providing extra security of your (personal) data.

and further down,

The other partitions, including the swap partition, will be created inside the LVM partition.

Your lsblk output confirms that you’re using LVM and that your swap partition is inside the encrypted LVM partition.

I don’t know how far back your “years ago” goes, but as far as I’m aware the above has always been true when using encrypted LVM.

In the lsblk output you show, partition 3 of NVMe namespace 0 is encrypted. On top of that partition is LVM, which splits the device into a further root device and a swap device. So yes, the swap is encrypted and an attacker would need access to your drive and the ability to break the password to obtain any information stored in it, just as they would for your root drive.

However, because the swap is encrypted with the same key that your root device is encrypted with, an attacker who is able to obtain the drive and key may be able to obtain data that you never would have expected would be stored on disk, such as private browsing data. Unless you use hibernation, you can improve security further by encrypting the swap device with a temporary, ephemeral key. To do this, you will want to remove the swap line from /etc/fstab and replace it with the following:

/dev/mapper/swap swap swap defaults 0 0

Then append the following to /etc/crypttab:

swap /dev/mapper/debian--vg-swap_1 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256,sector-size=4096

After a reboot, your system will be using an additional temporary, ephemeral key and even an attacker who obtains your encryption password will not be able to access your swap as plaintext, since the ephemeral key will have been lost as soon as the system shuts down. Because swap does not need to persist between boots (again, assuming you are not using hibernation, as it does put data in swap that must persist), it is completely acceptable for the key to be temporary.

However, I don't know how reliable ChatGPT is

Sarah Conor smiles.

Is there any risk of swap storing anything in plaintext, such that if my computer was stolen while powered off, an attacker would be able to retrieve a passphrase or key?

Yes.

In "industry" and from guidelines such as https://www.cyber.mil/stigs/ there is a fundamental thing to protect data at rest. Which you can look up that phrase and basically means any data stored on disk when powered off that an attacker could exploit if they got the disk out of your computer to work on at a later date.

You can do full disk encr. (FDE) using an enterprise class self-encrypting-disks (SED's) for which everything partitioned on it would be encrypted and be covered. But your Ubuntu (correction: Debian) apparently is using word FDE loosely at install time to sell you on the idea of security, which is bad, because it's not "full disk". You can't LUKS software encrypt /boot and /boot/efi for example because then it's a chicken & egg problem and you can't boot; but it is acceptable per STIG's to not encrypt these 2 partitions because unless you go out of your way it would not have data at rest in them that is worth exploiting.

For disk SWAP which is disk storage used as reserve memory to hold [inactive?] kernel pages and also act as a buffer when RAM gets full, can contain sensitive data which is why it does and should full under the data at rest thing for data security in the overall sense. And it is said... or believed... that swap data could contain passwords and encryption keys that could be exploited. Which would inherently be in a plain-text format which simply means it can be gotten and readily exploited.

• So yes you would want to encrypt the disk SWAP partition for security
• in industry if disk SWAP is used and not encrypted, it is a finding and you get punished
• easily rectified by using real FDE such as a SED vs a cheated method where the OS sells you on automatic FDE at install time but you have to go out of your way to say encrypt the disk SWAP partition when it does not by default
• more easily rectified by not making a disk SWAP partition in the first place. You don't need it, if you think you do then you simply need more RAM and are living in denial. I do do older systems with RHEL-8 that don't support SED's so Ido LUKS2 at install time but since I have not done a disk SWAP partition in like 15 years I can't honestly tell you if RHEL supports choosing "encrypt partition" specifically for SWAP but pretty sure it does {per chatgpt}.
• how likely is disk SWAP to contain such data like passwords and keys if you never come close to running out of RAM where everything gets swapped in and out of disk... would be the real question. But for running commercial software for which data in general is sensitive then yes that is likely to be in disk SWAP that could be exploited if accessed. The Kernel does not AES-256 encrypt data that it writes to disk swap, so it can be worked with if dd dumped and sifted through.
  • swap_digger.sh script (available on GitHub)