Mine, and I like it to stay that way. A TPM can be a valuable tool for protecting my data, making it difficult if not impossible for anyone to decrypt my drives. TPM+PIN is hard to beat.
The first link said nothing about TPMs. The second link is nonsense. The third link says the NSA "teams" with the TCG, which could be concerning indeed, but there's no details there. The fourth link is light on details and full of FUD. The fifth link says roughly the same as the third, and is equally light on details. The sixth link is like the fourth but it does have some actually useful information that says you're wrong:
> It is also important to note that any user concerns about TPM 2.0 are addressable. The first concern, generally expressed as "lack of user control," is not correct as OEMs have the ability to turn off the TPM in x86 machines; thus, purchasers can purchase machines with TPMs disabled (of course, they will also be unable to utilize the security features enabled by the technology). The second concern, generally expressed as "lack of user control over choice of operating system," is also incorrect. In fact, Windows has been designed so that users can clear/reset the TPM for ownership by another OS of they wish. Many TPM functions can also be used by multiple OSes (including Linux) concurrently.
This refers to the fact that you can:
- disable the TPM if you don't want to use it
- change the platform/endorsement/owner hierarchies' seeds, delete all the platform and endorsement certificates, and thus render any agreements between the NSA and the TPM manufacturers useless to backdooring the host (unless the agreement involves voluntary vulnerabilities in the TPM's firmware)
The last article you link to is much more interesting because it actually involves thinking about how the NSA (or other such agency) could have a backdoor inserted into the TPM:
> However, such “trust” can be easily misused to break security. In the talk, I used TPM as an example. Suppose TPM is used to implement secure data encryption/decryption. A standard-compliant implementation will be trivially subject to the following attack, which I call the “trap-door attack”. The TPM first compresses the data before encryption, so that it can use the saved space to insert a trap-door block in the ciphertext. The trap-door block contains the decryption key wrapped by the attacker’s key. The existence of such a trap-door is totally undetectable so long as the encryption algorithms are semantically secure (and they should be).
Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately.
That doesn't mean that there aren't other backdoors. For example, the ciphertext could be larger than necessary rather than use a compression of the plaintext. But this too fails because the sizes of the ciphertexts are easy to determine from the plaintext sizes.
The best way to add a backdoor is to have secret commands that use public keys for authentication (and even encryption) so that you have to know the backdoor in order to be able to use it. I cannot prove that there is no such backdoor, but if you have the means to decap and reverse engineer a dTPM then you can do this.
>Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately.
Excuse me, but wtf. That's BS. Cryptographic material is nothing but data. A Huffman encode will work on a number that happens to be a public key just as happily as it will a anything else.
Cryptographic material doesn't have a magic "immune to compression" characteristic.
An RSA public key is a prime number. How are you going to compress a prime number?
Encrypted material should not be compressable because it needs to appear random no matter what the unencrypted contents are, otherwise you have information about those contents. (You can trade off between the security and compressability, but shouldn't.)
An RSA public key is a small exponent for encryption and a large composite pq where p and q are large primes. There's more to it, naturally, but I'll stop there. You can have many many RSA keys of any given size, say 2048 bits for now. So something somewhat less than 2^2048 possible keys for 2048 bit RSA keys, let's say 2^2000 keys, which... is a lot! Since one should generate keys randomly we can expect that no one key will be much more frequently used than any other, so Huffman encoding is right out, but even if you try Huffman encoding anyways you'll find that most keys will end up with Huffman codes that are longer than the keys themselves meaning that the keys are not compressible!
Thinking about AES-256 will be easier. Say we have 2^40 computers able to randomly generate 2^64 AES-256 keys every day. Well, it will still take a long time to generate all possible AES-256 keys. So say in the best case scenario we get close to 2^120 keys or so. How would we even measure their frequencies so we could assign Huffman codes to them? Well, we can't, and even if we could most keys would have a frequency between 1 and 3. And still the next key to be generated could be outside that set so we really have to assign a code to each key, and there's... 2^256 possible keys... which means that even if we could assign a code to each key we couldn't write that down because there's not enough atoms on Earth to do it with. But let's say we just define a collation of AES-256 keys and assign then Huffman codes in order... But now we'll soon see that most keys will get codes assigned that are longer than 256 bits. Which means that the average input to this compressor would... yield an expansion, not a compression.
> An RSA public key is a prime number. How are you going to compress a prime number?
In principle, given an n-bit prime p, you can store an expected log₂ n − 0.5 additional bits by using the gap between p and the next prime. Though in practice, I'd be surprised if the 19 or so extra bits could be dangerous.
Try it for yourself. Encrypt /dev/zero in some key using AES, then compress it with whatever compressor you like. Try it many times. Let us know how it goes!
And, yes, you can compress specific pseudo-random looking symbols, but only a few. We're talking about arbitrary pseudo-random data, and that will not compress.
Why is PIN insufficient? Assuming encryption algorithms are sane, a 20 character long PIN should be able to achieve adequate entropy to keep the data safe.
