4 ms·
Something like half of the comments are recommending using a password for the FDE key instead of the TPM. I thought that it wasn't normally recommended to use a
by ufmace 5y ago
Something like half of the comments are recommending using a password for the FDE key instead of the TPM. I thought that it wasn't normally recommended to use a hand-entered key directly, since they wouldn't be expected to have enough entropy for FDE. The better solution would be to store it on a TPM behind a password, where the password check happens inside the TPM, and it can destroy the FDE key after too many wrong attempts. And uh, not send the password unencrypted to the OS over an interface that can be tapped with electrical leads on the motherboard.
- mjg59 5y agoUsing a password with a per-filesystem salt and a modern key derivation function will be just fine here - the key derivation is expensive enough that brute forcing the key isn't practical, even assuming relatively weak passwords.
- escalt 5y agoThe way I understand full disk encryption (with LUKS at least) is that the device generates a random key which does the data encryption/decryption and the user entered password is used exclusively to encrypt that key. This allows encrypting the key with thousands of iterations (the number is picked in a way that it takes a few seconds on the currently used CPU). That way you can use a very slow encryption algorithm (meaning it's very slow to brute force) to get the actual key, which can then be used for fast encryption of the actual data. This approach also allows changing passwords or using multiple passwords without rewriting the entire drive, since just the key has to be re-encrypted
- ufmace 5y agoAh yeah that makes more sense. I suppose managing FDE key via TPM is theoretically / ideally more secure, but has a lot more attack surface. Probably not many TPM implementations have been attacked enough publicly for anyone to be confident they're actually more secure than a regular password with good modern KDF.