Hacker News Reader

Comment by wat10000 | Hacker News Reader

I can’t understand this design. You should derive the disk’s encryption key from the user’s login password. You have a small, secure program that presents a login screen on boot. It takes the password you input and uses it to unlock the disk. It passes the username and password along to the OS so that it can take you right into your account after it boots.

As long as your encryption is decent, this makes it fundamentally impossible to read the drive from a turned-off state without knowing or cracking the password.

View on HN

Yours is not a good design.

First, passwords are terrible sources of entropy. Second, users want to change passwords without needing to re-encrypt every single block on their disk.

The correct approach, generally, is to generate a completely random encryption key (in a TPM) and encrypt it with the password.

The encryption key itself will have plenty of entropy, it can be changed trivially, you can set up multiple users to unlock the disk if desired, etc.

Further, what about systems with multiple users? Only one person should be unable to unlock the disk? No, you probably want the OS volume to be unlockable at boot without user intervention. When one of the users logs in, their password is used to unencrypt their volume’s encryption key.

Or in other words, you should derive the disk’s encryption key from the user’s login password?

The user’s password would protect the disk’s key, but would not necessarily derive it, I think.

Generally the way you solve that is by having the low entropy key give access to a hardware-based key store, like TPM. Those can be made tamper proof and throttled. I.e. the key is destroyed if you try to access the store by probing it, and it is locked (temporarily) after n failed attempts.

This also allows people changing their password as you do not change the actual (strong) key used for the disk but the key used to access it.

No, it should not be possible to compute encryption key from the password. Or, to phrase differently, you derive the key from the password and the data held by the secure element.

Right, it's not only derived from the password, but it derived from the password. You can't decrypt the disk without the password.

> but it derived from the password.

No, it's not. I use a book to generate a string of numbers and I can write them on a sheet of paper. If I put that paper in a room and lock the room with a key, I need the key to access the paper, but the numbers on the paper are in no way derived from the door key.

You are incorrect in your understanding of the word derived.

What are the analogies here? If you can find the door in the book you just need the key.

In cryptographic contexts (as opposed to English in general) "X is derived from Y" usually means that Y is the only information you need.

No. If you derive, then you can't change it without full re-encryption of potentially terabytes of data.

Yes, I’m simplifying slightly. You want the lowest level key to be random as you say. In addition to the benefits you mention, it also supports a recovery key, and means you can securely “erase” the disk in an instant by just forgetting the encrypted key.

His design is perhaps not 'good' if you were to implement it with the explanation as-is, but his description is hardly an implementation guide.

The concept as described is used worldwide (by macOS and iOS) and works very well. In contrast to things like BitLocker, OPAL TCG and SED where it's such an "everything is optional"-free for all, there is no real way to be sure.

In the FOSS world, most of this can also be done (combination of self-enrolled secure boot and dm-verity for a heads loader and them LUKS for a OS-stage loader), but the issue is that you can subvert the root of trust and get infinite tries to attack the encrypted data, including when a TPM or SED is involved.

Disclaimer: am not a cryptographer.

> First, passwords are terrible sources of entropy.

Use a KDF.

> users want to change passwords without needing to re-encrypt every single block

You've gone into a little more detail than OP, but I don't think it was necessary to disagree. The overall idea (even if simplified) is solid.

I've recently argued for the same solution for Linux: https://news.ycombinator.com/item?id=42739214

>First, passwords are terrible sources of entropy

>generate a completely random encryption key (in a TPM) and encrypt it with the password.

I don’t see how this approach solves the problem. If the password has bad entropy then using it to encrypt anything seems wrong.

The TPM is a computer running code that says "after 3 bad password guesses, forget the underlying key forever". That's the value it adds here. It's assumed that typing the password is the only way to get the actual encryption key out of the device, so the only attack is to guess the underlying encryption key, which is much harder than guessing a user's password (that they probably typed into totally-legit-blog.example.com to post a comment once).

In the real world, it's not clear that this is strictly better than using a slow password-based key derivation function. With a key derivation function, the attacker gets unlimited tries for all of time, so it is technically slightly less secure than "the key blows up in a ball of fire after 3 guesses". I don't have data on whether or not passwords are successfully guessable on average in 3 attempts, but they probably are for certain users. (You look at data breaches and if they use the same password on all of them, it's probably their TPM unlock password too.)

How secure TPMs are is also up for debate. I think I had an early one that was just a standard 8 bit microcontroller speaking the protocol the right way, without any actual security. That loophole is likely plugged for DRM reasons (software can ask the TPM to certify itself), but assuming that a computer running code you've never read has 0 bugs is unwise.

A theoretically perfect TPM is way better. The strength of your KDF is limited by the user experience. If you want to limit an attacker to trying one password per minute, then you have to make the user wait one minute to log in, if you assume the attacker only has the same amount of computing power you do. A TPM can just say “you have ten tries and that’s it.”

Of course, a real TPM won’t be perfect. But there’s no reason you can’t do both. Have the TPM use a good KDF and then an attacker has to break both.

When will come the day a TPM deletes itself after n wrong passwords, we will feel a great disturbance in the force, as if millions of IT support voices suddenly cry out in terror, and are suddenly hit with "my cat walked on my keyboard".

> The correct approach, generally, is to generate a completely random encryption key (in a TPM) and encrypt it with the password.

But they said:

> You should derive the disk’s encryption key from the user’s login password.

How is this not that?

It’s like using ssh-keygen to generate an SSH key, and entering your chosen password when prompted. This encrypts the private key, which is otherwise completely independent from the password. Not derived from it, just used to lock it.

I think that's just how you can implement it and not something that is incompatible with the commenter's post. They use a different meaning of "key" than you do, but that doesn't make it incorrect.

All of these problems are solved by implementations that have been around for ~15 years.

Eg: LUKS. It doesn’t use the passphrase to derive the key, but rather encrypts the key using the passphrase. This allows users to change their password and allows having multiple users with different passwords.

It is indeed a failed design. What you describe is how FV2 in Apple devices work. You have a native always-on DEK (Data Encryption Key) in the SEP (Secure Enclave Processor) that itself is encrypted with a KEK (Key Encryption Key) which in turn can have multiple encrypted versions for different end-users, which each has their password to decrypt the KEK, or better, authenticate to the SEP and it will decrypt the KEK. This is not exactly how it works, but a simplified story.

On top of that, there is indeed a small secure pre-boot stage where the user (any local user) logs in, which does both the OS login as well as the disk decryption (well, KEK decryption but that's a detail). It is of course also using a KDF so it's not just the end-user's password plainly applied to a cryptography function. This too is a simplified story (the pre-boot isn't actually a preboot, the OS is on a read-only signed volume since it's not secret/confidential, it's only important to prevent tampering).

This works, it works well, and has not had any real durable attacks that work against it so far.

Yep. I’m a Mac user and the FDE is basically transparent. The only thing you notice in normal use is that you get a login prompt immediately when (re)booting, and the actual OS boot happens after that, as opposed to booting and then logging in.

>It is indeed a failed design. What you describe is how FV2 in Apple devices work. You have a native always-on DEK (Data Encryption Key) in the SEP (Secure Enclave Processor)

That's what TPM 2.0 is supposed to do on PC and why Microsoft is demanding it for Windows 11 yet people don't seem to see the need for it for some reason, then whine about the security implementation.

Cause literally millions of devices will end up in landfills. Not figuratevelly, literally.

What happened to the MACs that had no secure enclave?

That’s whataboutism — Apple slowly has been precluding all of those from getting the latest updates officially (I think the iMac Pro is the last supported Mac without a T2 chip), and they’re ostensibly supposed to go into the landfill too, and that’s also bad!

It's not whataboutism, it was a very relevant question and possibly a precedent, no need to react aggressively.

For one, you can't implement blanket security features on an OS unless all devices have TPM 2.0, so all users who want the better security will have to have TPM 2.0 devices. Those who don't can stay on current hardware and use it till it falls apart.

Secondly, if Microsoft is bad for deprecating SW support for devices without HW security features why isn't the same uproar against Apple for doing the same?

I may not be hanging out in the right places, but the uproar seems to be about the same to me. I.e. for both of them, it’s a few angry comments online.

And which user would you put in charge of decrypting the drive?

I vote for Bob from QA, he's always around.

hardware key and physical attestation mechanism -> fde via key -> hosted encrypted userland or per-user virtualization.

it's not perfect and it's a lanky chain to keep maintaining, but it's not un-doable.

If you have multiple users then you make it so any of their passwords can decrypt the drive. It’s pretty simple to do this securely. Encrypt the drive with a random key. Derive keys from all the passwords. Use each of those keys to encrypt the drive key and store those encrypted keys. On boot, the user enters their password and then this is used to decrypt the disk key.

This also allows you to set up other keys, so that for example a company IT department can have a recovery key for the computer without needing to know your password.

This means your disk encryption security is now the limited by the worst password of any user, but that’s still a million times better than having the key be available to the system with no password at all.

> I can’t understand this design. You should derive the disk’s encryption key from the user’s login password.

In practice, this is not a good idea at all because no matter what you do, people will forget their passwords all the goddamn time. Back when I was doing freelance IT support, 90% of calls were "help, I forgot my password" - easy money lol, boot it up with MSDaRT or cmd+r on Macs, but nowadays... impossible to recover from if you don't have the recovery key.

Macs have the option to store an emergency unlock key in your iCloud account: https://support.apple.com/en-gb/guide/mac-help/mh11785/mac

The trade-off for recovery key custody remains a user choice, but you cannot turn on encryption without setting up recovery.

I've never dealt with a Mac enrolled in MDM, but I figure this is also a solved problem for companies.

> The trade-off for recovery key custody remains a user choice, but you cannot turn on encryption without setting up recovery.

Yeah but just how many cases do you know where people just store the recovery key file on their desktop, lose the printout or whatever... or they only have one iDevice that they use for 2FA so they can't log in to their Apple account...

Any widespread way of encryption must take the most braindead user into account or whoever rolls it out will be inundated by utterly stupid and preventable complaints.

> Yeah but just how many cases do you know where people just store the recovery key file on their desktop, lose the printout or whatever...

You are asked to make a choice of who gets the custody of the recovery key: you or Apple. If you 1. choose to keep it safe yourself, 2. can't remember the password, and 3. lose the key, well... you've cooked yourself.

> or they only have one iDevice that they use for 2FA so they can't log in to their Apple account...

I don't use iCloud for recovery, but my understanding is that you can just log in to iCloud from the Mac in question (I do get 2FA prompts on my Mac). I might be wrong.

In case you also lose access to iCloud, go to an Apple Store - they will reset it for you (bring your ID/passport/driver license/etc, it's an involved process).

> Any widespread way of encryption must take the most braindead user into account or whoever rolls it out will be inundated by utterly stupid and preventable complaints.

Yeah, Apple is pretty good at that. Not perfect, but miles ahead of the competition.

Apppe has deployed FDE properly tied to the user’s passcode/word to a billion+ consumer devices. They have high customer satisfaction and many repeat buyers. The idea that this can’t be done is blatantly at odds with reality.

You can achieve the same with bitlocker by enabling PIN and autologin

Having a separate PIN isn’t the same thing. Unlocking the disk with your login password means it’s just as convenient to have an encrypted drive as not (for the typical user who doesn’t need the thing to be able to boot by itself) and it can be the default configuration.

Yes I agree. It should be OOB like it is with MacOS. But you can set the PIN (they call it PIN, but you can enter any password) the same as your PW.

Ah hah, terrible naming strikes again.

I’m guessing that means you now have to change your password in two places if you ever change it? Not great, but then again people probably never change their passwords.

macOS has two things going on -- FDE (i.e., same as BL) which is auto-unlocked on boot up. What is protected by the user's password is FileVault encryption, but that's home directory protection only.

https://support.apple.com/guide/mac-help/protect-data-on-you...

FileVault 1 was home directory encryption. That hasn’t been current in ages. The current FileVault 2 is FDE using the users’ passwords as the keys.

Note in page that you linked:

> When you turn on FileVault, you choose how you want to _unlock your startup disk_ if you ever forget your password:

The password now locks the entire startup disk (as of FileVault2, which has been around a while) and needs to be entered into a pre-os screen. There is a place in the UI (once booted) to designate which users can do this.

This is useful for securing lost devices (since they don't have enough key material to decrypt the disk), but probably still susceptible to evil maid attacks (hacking the login screen).

You can read details on pages 119 and 120 of this document (in particular, page 120 has a diagram of how the volume encryption key is derived):

https://help.apple.com/pdf/security/en_US/apple-platform-sec...

Basic evil maid attacks are prevented by signing that login screen software (and everything leading up to it) so it can’t be altered. Of course there’s still the possibility of vulnerabilities in that software, hardware key loggers, etc.

Auto-unlock does exactly that, and its the default behavior for BitLocker encrypted OS disks.

Good. But why isn’t that the default? I get why the unattended-unlock mode would exist. Sometimes you have a computer that needs to be able to get started by itself. But it should be an advanced option, not be the default configuration! Especially on a laptop.

> I can’t understand this design. You should derive the disk’s encryption key from the user’s login password.

That's essentially what macos does. The key is not derived from the password, but it is stored wrapped with the users password (I assume the TPM is involved in the decryption of the key, but I haven't dug into the details). In the UI you can elect which users are capable of unlocking at boot, and wrapped keys are stored for them and hopefully updated when they change their passwords (or log in for the first time with the new password). On my work machine, with weird AD integration, I've had cases where this was missed, I've had to boot with the old password once to get things straightened out.

TBH, I don't reboot often, so I don't remember if it passes the password to the OS or if it makes you log in again after boot.

It passes the login to the OS. The user experience is basically the same as logging in normally, except there’s a pause for the OS to actually start up after you enter your password.

Deeper dive from The Eclectic Light Company: https://eclecticlight.co/2025/01/10/filevault-and-volume-enc...

Keeping your password in memory like that is pretty sketchy IMO. Then again, that's exactly what the fingerprint reader on my Lenovo tries to do if you set it up (though it uses a token and not the full password).

The reason TPMs are used is the unfortunate reality that most passwords are absolute shit. Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions. A TPM generates an actually secure key, and the brute force protections inside of it will make sure even quite insecure passwords don't get brute forced easily.

Another problem with this approach is that your password can be reset, remotely if it's attached to a domain. You can turn off a laptop, alter the domain password, boot it, and log in with the new one, even if you've forgotten the old password. With your proposed solution, you'd be disconnecting the password from the encryption password.

At that point, you might as well set the password to be the same as your login password and enable automatic login. You'll need to update both when they change anyway.

This TPM+PIN solution is actually the easiest, most common mitigation recommended for all of Bitlocker exploits I've seen.

It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password.

This isn’t a replacement for a TPM, it’s a way to use a TPM in a sensible manner. You have the TPM do the password -> key derivation, which lets you prevent brute force attacks (at least without a TPM vulnerability or physical chip-level attack). I imagine the TPM could also be used to securely tell the OS who did the initial login so it doesn’t have to prompt a second time.

Having a separate PIN means something else to forget and people will tend to choose the easiest option. We’ve barely managed to convince people to put up with having a password at all. If it’s a choice between password or password+PIN, people are going to pick the former. That option should be secure, and it’s not that hard to design a system where it’s more secure than having a separate short PIN.

> It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password.

But that means the user is using a different password... so you may as well use a TPM PIN.

What do you mean? A different password from what?

"Doesn't have to be your password ... [just a] correct password"

So not my password, then who's password? Why not TPM PIN?

Sorry to be unclear. Read that as “it doesn’t have to be your password.” As in, the fact that you’ve entered the correct password can be communicated to the OS without actually sending it your password. You can do it more securely than just setting a flag if that’s a concern, although the fact that the disk is readable at all is solid proof that some user’s password was entered correctly, so you don’t have to defend against too much.

> As in, the fact that you’ve entered the correct password can be communicated to the OS without actually sending it your password

Can't communicate with the OS -- the disk is locked.

> You can do it more securely than just setting a flag if that’s a concern

Now we just wait for a vulnerability in this mini-app stored in unencrypted storage to be able to set some flag and wallah, we bypass the user's password at the OS level.

Of course you can communicate with the OS. The disk is unlocked at this point, not that you’d want to use persistent storage for this. You’d put the info in RAM.

Doing this in a secure fashion doesn’t seem very hard. For example, hash the password in the same way the OS does. Hash that hash with some salt. Put it in memory at some agreed location. The OS can retrieve it, verify the hash and proceed if it matches. And of course erase the message.

If you’re worried about replay attacks from someone who can capture the message between login and the OS verifying it, you can add the current time to the hash. If you don’t trust the clock, I’m sure the TPM can produce an ephemeral nonce for both sides to use, or the OS could store a hash of each message after verifying it, and reject any reused message.

You’ll never be safe from software vulnerabilities, but this reliably prevents an attacker from reading your disk from a cold boot without knowing or cracking your password.

Your methods continue to open more methods of attack than TPM + PIN.

How? With my proposal, if an attacker can obtain your password then they can get in, otherwise they can’t. With TPM + PIN it’s the same, just with your PIN instead.

> Keeping your password in memory like that is pretty sketchy IMO.

Every Windows version since "... for Workgroups" keeps the passwords of every logged-in user in memory as plaintext. This fact is widely exploited for privilege escalation and lateral movement in Windows environments.

Local security authority protection changes this.

Do I understand it correctly that LSA Protection leverages VBS/VSM such that the "actual" Windows instance is punted into a VM while LSASS and friends run in a separate VM, with communication between the two controlled by a specialized version of Hyper-V?

See https://learn.microsoft.com/en-us/windows-server/security/cr...

Which is why recently Microsoft has been pushing very hard to replace the account login password with a TPM managed PIN. This way the (Microsoft) account password is rarely needed and never stored in memory.

> Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions

Why yes because adding a $%^* at any point in your password easily increased the entropy and didn't make it significantly harder to remember...

Realistically randomly generate your password and if you are the forgetful type write the bloody thing down. In 2025 you should be inputting it at most once every now and then and for disc encryption effectively never...

A long password in a locked drawer or safe is much more secure than Summer2025!5

The feature/bug only makes sense from the perspective that someone is telling Microsoft to leave it in.

Reply on news.ycombinator.com