I would consider it for my hosted server.

Entering a password on boot is a lot of work, because I need to vpn in, and run a java webstart kvm application (serial over ipmi would work better, but it doesn't work well on the hardware I have).

Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. But I assume I would be able to clear the TPM (if present) when I return the machine. And I could store a recovery key somewhere I think is safe in case of hardware issues (although, last time I had hardware issues, I simply restored from backup to new to me disks)

If a disk is encrypted, you don't have to worry about the contents if you eventually have to RMA or dispose of the disk. For this use case, it makes no difference how the encryption key is input.

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew.

Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). Typos can take a toll too because of all the delays included.

> Entering a password on boot isn't even that much work

It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot.

There has to be a better way.

Passwordless TPM FDE effectively "pairs" your HDD(s) with the TPM module such that the data on the drive(s) is inaccessible without it or a strong LUKS password if added.

Using even a weak pin/password will allow you to both "pair" and "secure" assuming the TPM is configured to destroy the key on multiple failed attempts.

You should also add a strong (high entropy) LUKS password to allow data recovery in case the TPM chip is lost or the keys are destroyed.

Note that the bits of the encryption keys are present somewhere in the TPM and could in theory be extracted with an exploit or with scanning probe microscopy perhaps.

It's always felt like the best way to lock myself out of my own machine. While I don't really keep any important data on it that's not backed up, I also don't build my workstation image from a config file or anything, so some time will be lost. The thing that's always bugged me is that before AMD had a TPM built into the CPU, the TPM was just a poorly-secured dongle hanging off the motherboard (at least with Asus motherboards) and it just seems like something that's going to break randomly. That breaks, then what. Meanwhile, the CPU owning the keys also doesn't feel great. Sometimes you swap your CPU and now there is an 800 step process to disable decryption before you do that, which is certain to be forgotten as you excitedly unpack your new CPU purchase. (Even if you're completely rebuilding the computer, the number of times I've put a new disk into a new build is approximately zero.)

Just typing a passphrase at boot seems like a pretty decent compromise. I've done it for years and it's never caused a problem.

On servers, it protects against someone stealing your disks (or stealing the raw bytes from your disks) and then booting them in a copy of your machine.

You do not even need to enter a password.

Use a randomly generated key. Retrieve it from an USB drive at boot (it does it automagically), which contains everything, giving you full plausible deniability without it. It means literally everything you need to boot up is on the USB drive, and if you so want it, you can use 2 separate USB drives.

This is for computers you have physical access to, of course. You will need to carry the USB disk if it is a laptop, but you choose: you want to enter a password (which by itself gives you no plausible deniability BTW), or you want plausible deniability and/or you don't want to enter a password. And while we are at it, laptops (and even desktops) today have SSD, and encryption and plausible deniability is different for an SSD, but again, you choose. Right tool for the job.

https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti...

> I don't understand why anyone would use passwordless disk encryption

You want to install and operate a device at a remote site with restricted (or no) VPN access and where you don't trust the local staff?

Between consciously encrypting with a user-supplied password, and not encrypting at all, automatic encryption seems more like a nuisance/hazard for recovery than anything else.

Consciously encrypting with a password implies an understanding of the risk of permanent loss. Leaving it unencrypted implies an understanding of the risk of disclosure. Having your drive silently encrypted feels like the worst of both worlds. "I never encrypted or locked it, what do you mean my data is encrypted and gone forever!?"

It's just not practical. How are you going to manually enter the password for let's say 10 servers?

I believe with software-based encryption (LUKS and the like), the decryption key ends up being stored in RAM, which will always present a risk.

And TPM-based solutions don't have this problem. Could be wrong though.

Fully agree, especially for a laptop. A password that combines three unrelated words and a few numbers takes about 3 seconds to type in.

I shut it down every day, so type in the password every day too. Short of a concussion, I'm not going to get locked out.

Imagine a big corporate workplace, where the infosec team wasn't comprised of freewheeling anarchic hacker types who've dedicated their career to mastering the intricacies of the Linux boot process, but instead by compliance folks who've dedicated their career to mastering the intricacies of global privacy laws and passing SOC2 compliance audits.

From their perspective, "Secure Boot" has the word "Secure" right in the name. And they've looked up details about the TPM - Microsoft says the TPM avoids systems being tampered with, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices.

If you don't know the intricacies involved, that stuff all sounds great! So they put a line into the corporate IT policy that TPM use is mandatory.

Try having a chat with a HCI person. Or in a pinch ask a LLM to emulate one for you. It's a useful perspective to have for a lot of stuff.

Some systems need to boot without a (trusted or skilled) user present.

> I don't understand why anyone would use passwordless disk encryption.

I'm using it on my home server that I'm using for self-hosting. This way, if it's stolen, the thief won't be able to easily get to my data. At the same time, I don't have to physically enter the password if my server reboots.

[dead]