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 apparently is using 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)

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)