Truecrypt is unstable

I'm coming out openly today to say that Truecrypt is unstable.

My 230GB non-OS Truecrypt encrypted static container suddenly fails to accept correct password. No I did not forget the password. This is the second time it transpires within 2 years. Luckily, I have extra backup of my files.

Believe it or not, I know of a company working close to military, which uses Truecrypt as full disk encryption and they experience Truecrypt corruption. Sad stories but many people are still depending on Truecrypt as savior.

Such things do not happen to other encryption programs that I've been using like Dxxx and Jetico.

Thus, I do not recommend Truecrypt to anyone unless he/she is prepared to have extra data backup.

 

Personally, I never had the issue with TrueCrypt specifically. Been using it for ~5 years, although not the same container or device. Currently it's over 1 year of System Encryption and System Favourite Volumes.

My backups include online imaging with AX64 Time Machine and offline imaging with Parted Magic's Clonezilla. This kind of thing is more subjective than objective with the current evidence in my opinion.

 

If US-based, that company is in for some trouble, TC is not on the list :
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm

Do you have a file- or partition/device- hosted TC-volume ?

Uhmm.. Yes, and ?
I do not recommend taking advice from anyone who tries to make keeping backups an issue . If you do not have backups, your data is lost .
It's only a matter of time when, encryption or not .

 

I agree . redcell, you make backups sound like a hassle. Most of the time user error is to blame anyways. It's really not that hard.. Also I don't think they would be preforming an audit and have so many supporters on something that is "unstable".

 

Very long term user with several system disk encrypted machines and over XP - 8 OS's. Never had an encrypted system disk give me any issues at all. Still I backup all data and sleep well at night.

 

I have used TC encryption on heavily used server partitions, never had any problem. However I don't use container encryption so much, mostly partition encryption. I have used TC since 2005.

 

Yes, TC volumes can be quite vulnerable. They need to be handled with care. There should really be a chapter in the user manual that describes what not to do, as there are numerous pitfalls.

TC volumes could have been made much more robust, with identifiable headers, active protection, fault tolerance, enhanced recoverability, etc., but this would run directly counter to the wishes of those many users who value the so-called "plausible deniability" features. You can't have it both ways.

 

Same containers, going on 5 years on two machines - no problems. If they dismount cleanly, never a problem. A machine problem that causes a BSOD or hard reset while a container is mounted, can cause a problem, but that is not TC's fault. NTFS formatting is more robust than FAT32. I have nightly backups made of the containers (the whole machine actually, Windows Home Server FTW! )

 

It wouldn't help much, because many people don't read the manual anyways .
Despite the manuals clear instructions, people still get in trouble because they make changes to a multiboot-mess setup,
they create extended partitions on OS's that don't support it,they try to 'upgrade' a encrypted OS,
they even use OS's not yet supported by TC and don't bother to create/store the rescue-disk !

IMO :
The only pitfalls not well enough discussed in the TC-manual are :
The 'initialize disk' -trap and how to avoid it all together and
the issues that can arise from windblows plug-and-pray enumeration of HDD's
(The 'changing driveletter' mess)
Also, I think the concept of 'plausible deniability' and 'hidden volume/OS'
is introduced way to early .
It is quite obvious that many people who use the 'hidden' functions don't really understand their purpose
but think it's just some kind of extra super-safe gimmick .

 

Enigm,
Hadn't thought of it like that before but I couldn't agree more. PD is an advanced topic that only makes sense for advanced encryption users. Hidden volumes should be a hidden feature. Activated by a tweaking a setting in the registry or launching from the command line.
I consider myself very technically savvy with good computer skills and technical aptitude and it still took me several months of reading the docs, playing around with the software and reading many forum posts before I felt like I really understood how TC worked and why it was designed the way it was.

 

Having the exact same problem and - from Google searches - I'm quite sure we're not alone.

These are my woes:

http://forums.truecrypt.org/viewtopic.php?t=29148
http://tateu.net/forum/viewtopic.php?f=2&t=402

Driving myself crazy with the "what if I changed my password and just don't remember?" but no, no I didn't. This is ridiculous.

 

Hi dantz,

Just curious as to what some of these pitfalls are?

In the time between my container opening just fine to the now "Incorrect password or not a TrueCrypt volume" I'm quite sure nothing on my system has changed!

Thanks in advance.

 

From my own experience and from reading hundreds of forum posts, here is what I would say about TrueCrypt stability.
The vast majority of "Incorrect password or not a TrueCrypt volume" issues are caused by instabilities in the Windows operating system and/or hardware failures. Windows crashes, sudden power losses, and hard disk failures can and do cause corrupted TrueCrypt volumes.
The "pitfalls" really come into play after a corruption event occurs. It is not trivial to determine what is wrong and what the correct recovery procedure is.
If you do not troubleshoot carefully, you can easily blow away your data forever.
I would mostly agree that users of commercial encryption software have less issues with this sort of thing. I think Dantz said this earlier:

"TC volumes could have been made much more robust, with identifiable headers, active protection, fault tolerance, enhanced recoverability, etc., but this would run directly counter to the wishes of those many users who value the so-called plausible deniability features. You can't have it both ways."

TrueCrypt has been designed from the bottom up to preserve plausible deniability. The commercial packages are designed to maximize user satisfaction. If I were to change anything about TrueCrypt it would be to make it more difficult for newbe users. System encryption, and hidden volumes should be hidden features. Activating these features should require a technically savvy user. A hard to find registry setting or command line flag to activate advanced mode for example.

 

Appreciate the insight but I absolutely positively have not had ANY crashes, power losses or hard disk failures whatsoever since the container(s) became corrupted. I am also 99.999999999999999% sure I didn't change the password(s). It's literally driving me insane(!)

I don't suppose you have any particular advice in recovery procedures at all do you? There is literally nothing I wouldn't try right now. Thanks so much in advance. I am desperate.

 

http://forums.anandtech.com/showthread.php?t=2166480

Maybe this is where it got me.

 

First, do you have a hard disk somewhere with 230+ Gig of free space? The first step should be to make a sector by sector copy of the affected volume.
After you have a backup copy, run some type of disk check on the original to see if there are bad sectors.
Is the encrypted volume a partition or full disk?
Did you create a header backup?
At any time, did Windows present a message asking to format the encrypted disk? Windows thinks it owns everything on the computer so will try to format any disk that has a format it doesn't recognize. (Another pitfall I forgot to mention)
Have you changed keyboards recently? Sometimes keyboards can have drivers that map special keys differently.
If you have the backup header you can try to restore it. If only the header is damaged, you are done. I wouldn't count on that being the case though. There is a backup header copy at the end of the volume. If you try and fail to mount more than 2 times, TC tries the backup header. Sounds like both headers are corrupted.

You can also find lots of discussions on the TC forums about volume recovery. I suggest you do some digging there as well.

 

Here's a partial list:
https://www.wilderssecurity.com/showpost.php?p=2229764&postcount=30

The primary mistake that most users make is in not realizing how vulnerable their encrypted data is and in not exercising due caution. Using TrueCrypt (or most other encryption programs) to encrypt your data is a lot like trading your car in for a motorcycle. You no longer have the stability of four wheels, the protective metal cage that tends to protect you in the event of a collision, the airbags, the seat belts, the antiskid brakes, the electronic stability control and many other safety-related devices. Now that you're riding a bike you need to pay much more attention to what you're doing because the consequences of screwing up are much more grave.

Encrypting your data puts you in a similar situation. Your data is no longer under the watchful eye of the operating system, or at least, not as much as it used to be. For example, an encrypted partition is much more vulnerable than a normal partition because Windows doesn't recognize it as a normal file system object, and thus Windows doesn't make any special efforts to protect it. All that Windows sees is a large region of garbled data where a partition is supposed to be, and thus it assumes that there's probably something wrong with it. At the first opportunity Windows might even try to "fix" the damaged region, or it might overwrite the area with other data, since the space seems to be available.

This sort of thing happens all the time. Users will often ask "What happened to my encryption headers?" and the answer is usually "You let Windows destroy them by not paying attention to what you were doing. Where are your backups?" Of course, that's not the only scenario, but the big picture is always the same.

Bottom line: Encryption is dangerous! Always back up your encrypted data if you want to ensure it's continued existence. And if you want to avoid major problems then I also suggest backing up your encryption headers, key files (if used) and passwords. A mere minute or two spent backing up these essential items (and that's truly how little time it will take) can help you to recover almost instantaneously from an accident that would otherwise cost you all of your data.

 

agree i am currently here reading this following your foot steps lol. Too many people definitely get ahead of themselves.....trying to ignore the erg of doing that.

The had thing is in today's world it is so damn complex you can't know or have the time to read everything....i am literally dieing trying to do this.

if i recall though what dantz is referring to is more for an encrypted drive and not a container correct?

 

Yes, I was referring mainly to encrypted partitions and disks. Encrypted files (file-hosted containers) are much safer, as they are a part of the file system and thus Windows gives them its full protection. Of course, if you end up mistakenly deleting a TC container file then you'll be quite sorry, as they can be particularly difficult to recover.

 

No mention is made of TC or Windows versions. I've been using 7.1a for however long it's been out on both XP and Win7, without any issues. I use both file containers and partition encryption. I have encrypted partitions on external USB drives -- just to throw more potential sources of corruption into the mix (but I don't use hidden partitions, I keep it simple). I use the external USB drives on different systems, mixing XP and Win7. I've had a BSOD just the other day with 3 partitions mounted, and numerous times the USB connection has disappeared on system wakeup (I suspect that's an issue with the PC); the worst I got from those was the wrist slap saying the device was not disconnected properly and make sure to dismount beforehand. Usually on reboot I remount the drives and chkdsk them all; so far I've been fortunate to not have any problems found by chkdsk, nor have I lost any files, and I've never had an issue remounting a drive.

The one time I thought I had issues with a TC volume being suddenly unreadable I eventually realized (after about a dozen slow and careful password attempts) that I was typing in the *wrong* password -- I wasn't making a mistake in the password, I was using the wrong one. Oops!

I don't think TC is unstable or unreliable. There are far too many variables and factors involved to make such a broad claim.

 

well if you recover it in recuva instantly it shouldn't have been over written yet...i blow through 20-30GB a day on my SSD but i doubt i would loose parts of it if in 60s i recovered it.

 

Thanks so much for the replies on this (have been busy with overtime so I can upgrade PC / run hashcat plus at full speed, as well as a new 3TB external drive for aforementioned sector-by-sector copy). Very much still here though.

Working on it!

It's a standard / basic non-hidden container (same as OP's I believe).

No. I really think TrueCrypt should start making this happen by default, too. I'd never even heard of headers until post-failure!

No, neither.

Hm, hope this isn't completely irreversible. Using OTF Brutus I've tried mounting probably in excess of 2...thousand times(!)

It's not that I've lost it, I just can't get in using my password!

Helpful post! I'm pretty sure all that's happened on my system pre/post-access denial is little more than a few minor Windows updates and the occasional (Defraggler) Quick Defrag, mind. That, and the odd CCleaner Registry clean. Hm.

7.1.a / Windows 7 Home Premium (32 bit).

Shall try a chkdsk post-backup.

Definitely not ruling this out - hence the upgrade to run HashCat Plus just in case - but I'm 99.9999% sure what the password was and I've tried allof it's variations / other possibilities to absolutely zero avail!

Anyway, shall keep you all updated if/when any progess is made. Should have my new HD by this time next week.

Thanks again for all of your inputs, very much appreciated.

(OP - redcell - how are you getting on?)

 

Note, I chkdsk the *mounted volumes*. If you're using an encrypted container, using chkdsk on the host drive might corrupt your container if it contains sectors that chkdsk attempts to repair. I don't use containers much, so I'm just speculating in that regard, but I'm guessing it would not end well.