TrueCrypt - Current Thoughts??

I remember, and it's unfortunate, as my criticisms were given only in the best interest, and were strictly, and clearly, aimed at TrueCrypt as a piece of cryptographic software -- nothing personal. The majority of what I had to say was well-received by others, and any disagreements remained civil; earlier debates were somewhat "fierce," if you will, for those of you who remember Paul Cooper. (By the way, what ever happened to him?)

All in all, though, I enjoyed it. Unfortunately, I could never quite seem to get any sort of response from anyone involved with the actual design of TrueCrypt. My concern is the apparent lack of interaction between the developers and user base, the latter of which has become somewhat of a cult-like fan base -- something we haven't seen since PGP. Instead of appearing like a pop star with no time for its fans, those behind TrueCrypt should grip their work's popularity and use it to their advantage.

Just as much of a concern is that no cryptographers seem to be on board; a lack of interaction and community is uncharacteristic of this field, as we know it in the academic, public environment. If you're unwilling to accept criticism, then you're not cut out for security. If you pay attention to the folks responsible for pioneering and trailblazing this field, you'll notice that they're just as good, if not better, at breaking, as they are at making. Take a look at cryptographers; the ones who give us the best designs are usually the ones who publish the best cryptanalysis.

I've always said, to understand security, you must first understand insecurity. You can't progress if you don't criticise. Another thing I've always proselytized is that complexity is security's worst enemy. Well, complexity has made room for a bedfellow -- blind trust. Assuming that the implementation of features like "plausible deniability" is secure is as dangerous as assuming that open source is inherently more secure than closed source. If the moment comes when it seems like questioning its security is no longer acceptable, then it's time to stop using it.

TrueCrypt has a lot of potential; it just doesn't seem like anyone knows what to do with it.

(Long live TroutCrypt! Quick Disclaimer: It's a joke; there's no such thing.)

 

I agree with you that TrueCrypt does have a cult-like following, and a ridiculous amount of blind trust. It seems like only an incredibly tiny fraction of users even question anything in the documentation. But I've been thinking lately that it's also got something else. A big bulls eye on its back. The bigger it gets, the more someone will want to be the first one to knock it down a notch or two.

I know I rely on it, but I'd love to be the guy to find something that knocks out its plausible deniability. This started to occur to me when products like TCHunt started coming out. Wouldn't the developer of TCHunt love nothing more than to be able to detect hidden volumes? What do you think? Am I looking on the bright side too much?

Edit: There's also the Stoned Bootkit. It seems like a lot of people are trying to make a name for themselves by trying to take down TrueCrypt. That can't be a bad thing.

 

Oh, most certainly. It's one of the reasons I preach the use of the AES; it's receiving the most attention. Why? Because it's the standard. Obviously, more cryptanalysts are looking at it because more is riding on it. Whatever has the market share gets the attention.

You're absolutely right.

 

What is the most trustworthy and reliable method of creating encrypted volumes or folders? TrueCrypt or PGP?

 

Well, I haven't used PGP, but I don't believe it's possible to encrypt folders directly. You create volumes, and when you mount them they become a virtual drive. You work with them like you would a non-encrypted drive. They have their own drive letter as well. The way you would encrypt a folder is to copy that folder into the volume (or create the folder on the volume). When you dismount, the drive letter disappears, and you no longer have access. There's actually very little effort involved, and it's very reliable as long as you don't destroy/delete the volume (and especially the header).

I've used TrueCrypt almost exclusively, but I believe PGP works the same way. They should be equally reliable and functional. To me, it's exactly like working with a non-encrypted drive.

 

Okay. I have used trueCrypt and it is wonderful. So easy to use. But with all of the concerns that people have I was wondering if maybe PGP software would be better.

 

If you're talking about the concerns in this thread, then I wouldn't worry about it. So the forum moderators are quick on the delete button and the developers are anonymous. It just means TrueCrypt has been so popular and is so big now that people like to nitpick.

The software speaks for itself. If you're concerned about backdoors, then you should also know that PGP Desktop isn't fully open-source. They hold back some of their source code. But I don't think either is backdoored. So, go with the one that actually functions best for you. You can't go wrong either way.

 

Thanks for that.

 

Stoned-bootkit

TrueCrypt Attack (Full volume encryption, only the master boot record stays unencrypted )

Why did they leave some sectors free with no check ?

 

The official explanation is that once the computer is compromised (either through malware or physical access), there's nothing TrueCrypt can do to protect you.

But given that 2 new bootkits have come out targeting TC (Stoned and Evil Maid), I have a suspicion they'll introduce some type of protection in future versions. It's only a guess on my part, and they haven't said anything about it.

 

And IMO this is the correct explanation. The TC user should make sure that his/her system is not compromised, otherwise there are no guarantees...

 

Thanks that makes sense but any TC weakness helps the exploit.

Hackers don't care about TC rules and limitations.

TC could at least prevent the simple MBR overwrite in Windows in such a simple matter by filling the empty place with something safer.

So far I suggest a strong bios with an admin password to restrain/detect the exploit. You can boot with a linux distribution and you better check the MBR & volume MD5 and eventually add another extra check/split/join/compression/encryption from a ext3/4 partition. Windows is weaker than Linux.

Of course an offline computer with an hidden volume on a full crypted partition is better to restrict detection against tools like TChunt.

There is a french article about TCHunt vs FI TOOLS ( with english comments from the authors and other pages about dual crypted boot or seven support ...)

I don't trust TC really and won't use it for something else than a big honeypot ;-)

 

regarding the discussion if the US goverment has a back door, lets say they did for arguments sake, if they did they would only play that card as a last resort in a major event like if the US country was under threat. they wouldn't bother using the back door on all of todays small crimes because the word would get out and everybody would know about it.

 

If TC programmers start thinking from this point of view, they might as well turn TC into a full antimalware/antispyware/etc. solution. I'm afraid people got used to use a single tool that does everything, which is not exactly the best approach. You use TC to protect private data, and use HIPS/antivirus or other antimalware in general to protect your computer from being infected.

 

I totally agree but things like modulo 512 issue or not strong enough pre-boot authentication in Loader itself are inner weakness like Achilles heel that can result in failure. Let's see for the future i wonder about 'Raw' CD/DVD volumes.

 

With PGP NetShare (a component of the PGP Desktop “complete edition”), you can selectively encrypt folders. I use it, and the functionality is excellent.

Certainly, everyone needs to make their own decision, but it’s hard to beat the reputation and trustworthiness of PGP, in my opinion.

For a more complete description of how PGP allows a user to verify that it does not contain a “backdoor,” see PGP Assurance To Prospective Customers.

 

Again, I don't think this is a complete explanation. I don't think they release the complete source code for PGP Desktop. They only release the code for the crypto aspects of the program.

I can't find a source for this information at this time, but I remember reading it directly from PGP employees years ago. But if I'm wrong, please correct me.

So, TrueCrypt is fully open-source and PGP Desktop is not. Let's not dilute the meaning.

How is a TrueCrypt file-hosted volume being divisible by 512 bytes a security issue. If you mean plausible deniability, then I have news for you. It doesn't matter. Having a file that large with totally random data (regardless of its divisibility) could easily cause you problems if you're looking for PD.

The second thing is that you can easily append data to the end of the file if you want.

The third thing is that plausible deniability and malware prevention are two entirely different topics. You can't directly compare one with the other in terms of security implications.

 

Not that you implied this in any way, but I thought I'd add that this doesn't inherently say anything about security; that is, open-source versus closed-source isn't a valid security metric right off-the-bat. It can be, but it's not automatically. Keyword: potential.

 

512 modulo just made the file detectable.

According to my own tests and their FAQ it is the way TCHunt searches for four (4) file attributes:

1. The suspect file size modulo 512 must equal zero
2. The suspect file size is at least 19 KB or 275 KB in size (although in practice we set this to 15 MB)
3. The suspect file contents pass a chi-square distribution test
4. The suspect file must not contain a common file header

TCHUNT found 12 of 13 TC files on my computer. My whole encrypted partition was not flagged. I've got 1 false positive, in fact a compressed clean system partition backup.

TCHunt only locates potential TrueCrypt volumes

I will test again with a common file header and ''junk injection'' to the files. Further i will "toast" these files together with some χ² anti-Yates hidding techniques... nor steganography ;-)

Peace

 

I do not believe the above statement is accurate:

 

It is accurate. There was a whole long debate on the TrueCrypt forums years ago that I believe spilled over onto these forums. It involved Jon Callas, the CTO of PGP. I believe some of the links on the TrueCrypt forums have been deleted, and when I do a search for PGP here, it won't accept it as a search term (too short).

So, I'm having trouble locating the links, but I'll look again for you.

 

http://forums.truecrypt.org/viewtopic.php?t=3650&postdays=0&postorder=asc
http://forums.truecrypt.org/viewtopic.php?t=11100&postdays=0&postorder=asc
http://forums.truecrypt.org/viewtopic.php?t=3646

Deleted?
http://forum.pgp.com/pgp/board/message?board.id=46&message.id=4002
http://forums.truecrypt.org/viewtopic.php?p=16718#16718


The last two links aren't working for me, but I can't say for certain if they've been deleted or it's a temporary error.

 

This modulo 512 thing has no relevance whatsoever. If a skilled forensic investigator takes interest in studying your file system, you won't be able to hide an encrypted volume, no matter it's size is. Sure, you might be able to trick a poorly written detection tool, but not an investigator.

 

I agree with this, but I assume you're only referring to file-hosted volumes. Because, in my opinion, none of this applies to partition/device-hosted volumes.

 

Interesting. Fortunately, these differences do not appear to be material to the question of inspecting and verifying the integrity of PGP Desktop.

Note that the description of the source code differences is from August of 2006. It is possible that the policy and practices of PGP have changed since that time. Tom McCune, a PGP Forum Administrator, noted today that “As far as I know, it continues to be the entire product that is released in the source code” (see here).

You may wish to send an inquiry to source@pgp.com to ask further about this issue.