I'd like to hear from TrueCrypt users who've had both good and (if any) bad experiences with it: Is it reliable enough for business-critical use? In my case, I expect to use file-based containers rather than encrypting entire partitions.

For me the nightmare scenario is: I go to open the container, supply the right authentication information (whether it's a passcode, a key, whatever), and TrueCrypt just can't open the container for whatever reason. Perhaps there was a write error on the last update. Perhaps a stray cosmic ray hit just the wrong part of a data structure. Perhaps the machine I last used the container on was destroyed by a falling satellite and I'm now trying to open the container on a different machine with a different architecture (Windows 32-bit instead of *nix 64-bit, whatever). You get the idea.

I don't care about horror stories of lost keys or what-have-you; nothing without a backdoor can protect you from doing something dumb. I'm talking about the software actually failing in a way that loses your data.

(And yes, obviously, if I'm dealing with business-critical data, I'm going to keep backups of the container — multiple point in time going back days/weeks/etc. — to mitigate the effects of some of the above.)

  • 4
    Wouldn't your nightmare scenario apply to any situation encrypted or not? I think your real issue is a proper backup strategy to negate any nightmare. – Moab Nov 1 '10 at 15:33
  • 1
    And remember: TrueCrypt volumes can be decrypted within minutes if the key is still in memory, without brute-force attack: lostpassword.com/hdd-decryption.htm – Saxtus Nov 1 '10 at 16:36
  • @Moab: Yes, it would (hence backups). But with (say) just a normal HDD partition, gzipped tar files, etc., I have multiple independent implementations of code to read the data. With TrueCrypt, I have only TrueCrypt (granted I can get the source). I'm just trying to figure out whether that's worth worrying about. – T.J. Crowder Nov 1 '10 at 16:48
  • 1
    @T.J. Crowder: I totally understand. I mentioned it for completeness, just because I think it falls into reliability category and no one else talked about it, nothing more, nothing less. I didn't thought that should be an answer by itself. – Saxtus Nov 1 '10 at 17:05
  • 1
    @T.J. Crowder & Diago: For what is worth, I think that this question and answers given was helpful and I am glad that it was asked. Probably it started as general discussion topic but it ended up been having objective answers. Thumbs up! – Saxtus Nov 13 '10 at 9:11

I and my fellow engineers at the office all use TrueCrypt.

We each keep a local TC data store of 50GB formatted for NTFS. Everyone gives their pass-phrase to our boss, and keeps a back-up on the NAS at the office.

Procedurally, not having an escrow-recovery is the biggest reason NOT to use TC. I.e. if someone changes their pass-phrase, gets angry and quits, we have NO way of accessing their data. So, from a business-critical perspective, that's probably the biggest risk.

Performance-wise, TC will keep-pace because of how it integrates with the host OS, but I wouldn't use it to encrypt an enterprise data-store or anything.

We really like the fact that TC supports multiple platforms -- because not all our engineers use the same OS. Some run Linux, some run Windows, and regardless TC works. It also doesn't care if you switch platforms! That's nice.

  • 4
    You can create the container using your choice of password/keyfiles, and then backup the volume header. Once it is backed up, you can allow the end user to change the password/keyfiles as they would like and by maintaining the original header you can restore it and decrypt the archive. It should go without saying that you would want to guard those original headers very tightly. – Goyuix Nov 1 '10 at 16:19
  • Thanks, very good to hear about real-life situations. You've never had a situation where for some unknown reason, TrueCrypt just wouldn't open a volume, despite being given the correct authentication? – T.J. Crowder Nov 1 '10 at 16:44

TrueCrypt is as reliable as a plain partition is: If it suffers an unrecoverable error, doesn't matter what type of volume is, you lost data anyway.

The good thing about TrueCrypt is that you won't lose the entire thing (the following was taken from it's FAQ):

What will happen when a part of a TrueCrypt volume becomes corrupted?

In encrypted data, one corrupted bit usually corrupts the whole ciphertext block in which it occurred. The ciphertext block size used by TrueCrypt is 16 bytes (i.e., 128 bits). The mode of operation used by TrueCrypt ensures that if data corruption occurs within a block, the remaining blocks are not affected. See also the question 'What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted'?

What do I do when the encrypted filesystem on my TrueCrypt volume is corrupted?

File system within a TrueCrypt volume may become corrupted in the same way as any normal unencrypted file system. When that happens, you can use filesystem repair tools supplied with your operating system to fix it. In Windows, it is the 'chkdsk' tool. TrueCrypt provides an easy way to use this tool on a TrueCrypt volume: Right-click the mounted volume in the main TrueCrypt window (in the drive list) and from the context menu select 'Repair Filesystem'.


Truecrypt can deal with everything but these two.

  • write error on the last update

This is filesystem related and outside truecrypts scope, the OS and file system should worry about getting that right.

  • stray cosmic ray hit just the wrong part of a data structure.

I don't believe any software can be made safe if a cosmic ray flips the wrong bit of RAM at a crucial time.

The only way to be safe from these potential errors are backups.

Not the answer you're looking for? Browse other questions tagged or ask your own question.