Edward Ned Harvey (lopser)
2013-06-28 11:42:39 UTC
First of all, all the major characteristics are the same, which is to say, very well implemented. They both use strong encryption, to encrypt the whole drive, decrypt it just an instant before booting the OS... Truecrypt supports multiboot bootloader, and they both prompt you to save a backup encryption key for recovery. They both perform a test boot before encrypting the whole drive, they both allow you to continue doing stuff while the application applies encryption as a background process. You can pause the encryption process, reboot if you want, and later resume. They both use the AES-NI instruction set when available.
So all in all, it's quite good. But there are a couple of differences that I felt were significant:
Truecrypt definitely uses a 256bit key, but that's enormously irrelevant because it's using a password key derivation process, and there's no conceivable way a user is going to type a password with 256 bits of entropy. A typical PC can brute force approx 10m keys per second, while a government super computer is approx a few million times that. Other techniques such as GPU and FPGA cracking can increase the attack rate by another factor of 1,000 to 1,000,000. So the world's most powerful FPGA cracking array might be able to attack 10^12 or 10^13 keys per second. And then of course, some clever people have identified smarter attack techniques rather than naive brute force. I have no knowledge how much they gain with improved technique. So the strength of your encryption very much depends on the strength of your key.
Bitlocker has conflicting reports on the internet. Some say it's 128, some say 256. I'm guessing it's actually 128 by default, with an option to go stronger somehow. I recently did a calculation to see how significant this difference is, and concluded that if somebody tries to brute force 128 bits with a normal laptop, it will take ~ 60,000 years. Which means either key strength is good enough to keep out typical attackers. But if a government agency wanted to brute force attack, based on info at top500.org, the 128bit key is brute forceable in a matter of minutes, while the 256bit key still keeps them out for like 10^12 or 10^19 years, way longer than the life of the Sun. End result: I prefer 256 bit whenever possible, but if it's not possible, I still consider 128 acceptable for anything less significant than national security.
In bitlocker, your "backup" key is random digits, stored in Active Directory, or something. So when a user gets locked out of their system (because they had motherboard replaced on warranty, or they applied a BIOS update) they can call your support desk, who can read the key across the phone, and get the user back into operation.
In Truecrypt - Oh, I forgot to mention -
In Truecrypt, you have a password, which is salted & stretched, to decrypt the Master Key, which is a random 256 bit number, which is then used to decrypt the hard drive. So normally, there's no way to "backdoor" or "recover" when you lose your password. But you can create a backup of your Header (which includes the key info), and create a rescue CD. This means I'm able to set a secret the initial truecrypt password, create rescue media, wait for the whole disk to finish encrypting, and then together, the user and I can change the password to whatever they like. They don't need to know my recovery password, and I don't need to know their password. If they're unavailable for some reason, I can boot from the recovery CD, type in the old password, and restore the bootloader key information. So then the system is bootable using my recovery password.
Problem is, if a user gets locked out (they forgot their password) they need a key reset - it can't be done remotely. Recovery involves booting from rescue media. You can only help them remotely if they have another computer handy with internet and a CD burner, or if they're willing to wait for a disc to arrive in the mail.
So that's thing #1.
Here's thing #2:
In bitlocker, the TPM does a pre-boot security assessment. Checking the BIOS, the boot device, the boot sectors... Only if it's untampered, does the TPM release the decryption key. That's good. :-)
In Truecrypt, it seems almost trivial to implement a bootloader attack. A malicious person could install a bootloader that puts up a fake login prompt, get the user to type in their password. Now that I think of it, both bitlocker and truecrypt have the same vulnerability here: If you have physical access to the machine you're attacking, you swap out the hard drive. The fake hard drive does nothing except put a fake login prompt on the screen that looks the same as the one the user expects. (Put up a video of the Windows boot screen to attack a user of bitlocker, followed by a fake login prompt that activates when the user presses ctrl-alt-del). But I think the tampered Truecrypt boot prompt is much more obvious and easier to implement than the Bitlocker implementation.
And finally, thing #3.
I use whole-disk backup software too. Acronis TrueImage. I know this works on bitlocker (although the backup itself is not encrypted.) I tried trueimage on truecrypt a few years ago and it didn't work at that time. I have not repeated the test in recent years, nor with different products. So I don't know what/if any whole disk backup program works with TrueCrypt.
All in all, both solutions are very good. For general purposes, especially in company deployments, bitlocker is better due to remote unlock and compatibility with backup software. In an unrealistic world where a user memorizes a key having 256 bit strength, TrueCrypt definitely has the potential to be 256 bit strong... Whereas bitlocker, maybe can do 256 bits. I emphasize it's unrealistic for anyone to memorize such a key, while the 256 bit bitlocker implementation might just be a simple config change, or a simple update patch or future release. So in theory they're just as strong as each other. In practice, bitlocker is better.
But they're both very good.