Ttdfjt

If understand correctly from this post and the Wikipedia page for BitLocker and TPM, by default, BitLocker uses symmetric cryptography like AES. However, TPM is capable of performing RSA encryption.
Given that the RSA key is stored in the TPM, why does BitLocker not use asymmetric encryption (i.e., RSA)? By using such an encryption technique, we might be able to defend against the cold boot attack or sniffing on the LPC bus.

Asymmetric encryption is vastly inferior to symmetric encryption. That is, in all respects, except one -- being asymmetric. When that property is needed, there's no way around it, obviously.

Asymmetric encryption is much slower. It is much more susceptible to showing recognizable patterns of some kind given non-random input. You need much larger key sizes to provide an adequate level of protection, and the system is much more vulnerable in general with current and future technology (reasonably-sized quantum computers will basically mean instant death for RSA, but AES is pretty much "yeah, so what" in that respect).

That's the reason why asymmetric encryption is almost never used to encrypt bulk data.

Nothing prevents you from encrypting a terabyte of data with RSA using 2048 bit chunks, much like you encrypt a terabyte with AES in 128 bit chunks. Only just, it doesn't make sense to do that because it is several thousand times slower, and at the same time is much more insecure.

The cold boot attack can be performed on any encryption scheme as long as the keys reside in memory. For full-disk encryption (FDE) with symmetric algorithms like AES, you will need to take the key out from the TPM, where you will be susceptible to a cold boot attack.

Though the TPM is capable of RSA encryption and decryption, for FDE RSA has problems, in short the speed:

1. RSA must use the OAEP scheme to be secure which reduces the message size.


2. To speed up public key encryption the public key is selected as 3, 5, ... However, the decryption to access one block will be much slower even if you use CRT to gain 4x speed.


3. Even though the TPM can perform RSA encryption on the chip, it will be much slower for Full Disk Encryption (FDE).

Therefore, TPM-based FDEs use TPM for key storage.

TPMs do not perform the actual encryption used for full disk encryption. All they do is encrypt the key while the system is powered off or in a suspended state. The key is decrypted and passed once to the operating system over the LPC bus, which then keeps it in memory while encryption is performed. The reason a TPM would be a poor choice for securely accelerating full disk encryption is threefold:

1. The TPM communicates over the extremely slow LPC bus (4 bit width at 33 MHz).




2. The TPM hardware is generally very slow, being designed for security, not speed.




3. TPMs are not general-purpose encryption coprocessors that take arbitrary keys.

If you really wanted to use it to perform the actual encryption in a way that would mitigate cold boot attacks, you would need to pass the plaintext (or ciphertext) from the disk to the TPM over the LPC bus to encrypt (or decrypt) it, then pass the ciphertext (or plaintext) back over the LPC bus to the computer. This process would be an extremely slow way to avoid cold boot attacks, and would likely be easy to bypass given the ability to tamper with signals on the LPC bus (the TPM would be a decryption oracle!).

Although you could in theory use RSA for bulk encryption, provided you used proper padding like PKCS#1v1.5 or OAEP, it would expand the message (ciphertext would be larger than plaintext), and it would be extremely slow and inefficient. Despite what some other answers have claimed, it would not be insecure when a proper padding scheme is used, but it would be a silly and inefficient use of RSA.