[ajklsdhfniuwehf]

> 2. I can use a simpler/more memorable password because entry attempts have to go through the TPM, rather than being able to be bruteforced with a GPU cluster.

this is already the case with every single open source encryption model out there. You have a simple password which then encodes the true key.

Nothing will save you from GPU cluster brute forcing it, if the adversary have your harddrive.

[Sanzig]

> Nothing will save you from GPU cluster brute forcing it, if the adversary have your harddrive.

Not really true.

In the case where a password is used to derive the encryption key, the password is passed to a key derivation function which deterministically generates the key of the appropriate length. Ideally, the KDF should be computationally difficult to slow down brute force attempts, but you can still parallelize the attack with a big GPU/FPGA cluster. If the password is sufficiently weak, you can often get a break this way.

In the case of using a TPM for full disk encryption, the key is generated by the module itself and requires a password to unlock. This is rate-limited by hardware, and typically the TPM will lock itself out if you have entered the incorrect password too many times. If you steal the hard drive, you can't decrypt it even if you know the password (the password unlocks the TPM and has nothing to do with key generation). Likewise, if you steal the whole machine but don't have the password, you'll be hard-pressed to brute force it since the rate-limiting / lockout features mean you can't make lots of parallel tries. Your GPU cluster is an expensive paperweight in this case.

In theory, the only reliable way to decrypt a device using full-disk encryption and a TPM without the password is to try extracting the secrets from the TPM itself. This isn't impossible, but they are specifically built to resist key-extraction attacks. You're pretty much talking about an attacker with state-level resources in that case, or at the very least a very determined group of private sector professionals.

[ajklsdhfniuwehf]

for this to be true, the password to key transformation have to be extremely broken for you to be able to infer what is a valid key from what looks like fixed size random noise.

well, this might be true if you use some NIST or RSA certified process :) but who cares about that other than bureaucrats who run entire cities with one set of master keys anyway.

> This is rate-limited by hardware

See this is the kinda of thing those bureaucrats would say. If your hdd is out of your device and i am brute forcing the key, who cares about the password to key transformation? that is already behind me.

[gruez]

> for this to be true, the password to key transformation have to be extremely broken for you to be able to infer what is a valid key from what looks like fixed size random noise.

You're not bruteforcing the derived key (ie. the value from the KDF), you're running a wordlist against the KDF and seeing which values work.

>If your hdd is out of your device and i am brute forcing the key, who cares about the password to key transformation? that is already behind me.

The difference is that with a TPM, you can't run a wordlist attack, since password attempts have to go through the TPM, and it throttles your guessing attempts. Without a TPM you can run the KDF as fast as you want, across as many machines as you want.

[ajklsdhfniuwehf]

put down the intel certification pamphlets and go find a single key encryption where those two things are true.