Hacker News Reader

Comment by stouset | Hacker News Reader

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.

View on HN

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.

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.

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

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.

>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.

Reply on news.ycombinator.com