Schneier on Security

I have used TrueCrypt for a long time and love it. It has excellent features, is very stable and I am yet to have a problem with it. Also the fact it is OpenSource and uses tried and tested algorithms makes me feel more comfortable using it.

This is the program I've been recommending to all my friends since it appeared on your blog a while back in the comments. Easy to install, explains what encryption algorithms you should use (with benchmarking) and, as you said, denyability.

A few key features of TrueCrypt that did not make it to the front page:

* Cross-platform (Windows / Linux / OS X planned)

* Open source

* Free

Although, from an abstract perspective, it may be impossible to know if a second, hidden, volume exists on the disk; their diagram suggests that one could look to see how many times a given area of the disk has been written. Hard drives tracks don't align perfectly on every write, so you can detect "older" tracks with an electron microscope and probably take a guess at how many times a sector has been written. If that sector "should" be dormant it would suggest a hidden volume exists.

Having said that - it should be sufficient for most uses.

> how many times a given area of the disk has been written.

That would not help the attacker. There could have been anything stored in that area of the disk before you stored the encrypted container there. Thus, you can _plausibly_ claim that there were other files (not the container) in that disk area before you put the container there. And it would often be true.

Remember that a TrueCrypt container is just a normal file. (You can even move it to another place when ever you want.)

Been using it for a long time and I love it. It's fast, hassle-free and I think is a better alternative to PGPDisk, which I tried and uninstalled soon after.

Also, you used the term "dormant" sector. I assume you meant a sector to which no data has been written for a long time.

What does that tell the attacker? Nothing useful.

Has it been reviewed by any security professional (like yourself, Bruce) ?

Hadi - I really liked PGP Disk - especially the ability to associate PGP keys with the disk with read or read/write permissions. However, I had many problems with the portability of a NTFS-formatted PGP Disk/container, and prefer TrueCrypt these days.

Off topic but is anyone using TurboCrypt? Will give TrueCrypt is peak- concened I can't do part of a disk or put key on smart device?

I have been using encrypted filesystems on (Ubuntu) Linux with the built-in "cryptoloop" driver. It's pretty straightforward.

I wanted to give TrueCrypt a try, but I was very disappointed that it required a special kernel module. This makes it difficult to run on several systems (for example, when run from a USB pendrive). It also requires some extra work when I upgrade kernels from time to time.

So, cross-platform is a plus. Special kernel module is a minus.

However, reading all of the reviews from happy users in this forum, I may have to give TrueCrypt another try.

I've been using truecrypt to routinely encrypt all my personal data for a long time now and it has never let me down.

I usually create a CD or DVD sized container and mount that as my p:\ drive and off I go. Easy to back up as well.

We use TrueCrypt for sensitive data on all USB thumbdrives.

note: I'd archive a copy of the current version of TrueCrypt - it's damn near perfect as is, and who knows what may become of future versions.

The one problem I see in the hidden sectors is that, since the regular sector doesn't know about the hidden sector and could thus presumably step on it, one wouldn't want to use the regular sector extensively. One would have to be sure that the data is such that last-access times of before you created the hidden sector (whenever that is) doesn't appear strange.

One way to search out these kinds of files is to use OFTE Volfinder from Sarah Dean's We Site http://www.sdean12.org/. It hints at those files that "look like" they are containers for OFTE encrypted data. More like sorting the wheat from the chaff - then you have sort thru the wheat !

@Anonymous: Recent versions of Truecrypt include a "write-protection" for the hidden volume, if you want to write to the normal volume.
Obviously, you have to enter both passwords for this to work.

I've been using TrueCrypt for 4 months now. It has worked perfectly both on Linux and Windows, the cross platform is a plus. I store my Outlook .pst files in the encrypted volume along with other confidential data.

What sells TrueCrypt is the additional features. Keyfiles to stop basic keyloggers, automatic unmounting after timeouts, locking the terminal or screen saver activation, header backup etc. The performance monitor was great in choosing which algo to encrypt with too.

The only real downside is the lack of many of these great features in the linux client, making it only slightly better than cryptoloop (which I used previously).

Have been using TrueCrypt for sometime now and love it.
My Thumbdrive is encrypted and uses "travel" mode, which is great. Plug into any PC and it 'runs' no install required. Also, encrypts my browser cache, and customer files on my laptop, should the laptop be stolen.
Only missing the linux / Mac cross compatibility which has been mentioned is coming. That will make it almost perfect for my uses I think.
--Mike

@Alan Porter:
FreeOTFE can read and modify (but not create) cryptoloop, dm-crypt, and LUKS volumes.

A previous version of truecrypt was broken (see for example http://groups.google.com/group/sci.crypt/msg/a30ac58c279087f2 ). The current version has completely replaced the faulty disk encryption part with LRW mode from SISWG, but who knows if they got all the other details right. I certainly don't.

> There could have been anything stored in that area of the disk before you stored the encrypted container there.

Although that data probably wouldn't look like random noise (which the container would).

> I assume you meant a sector to which no data has been written for a long time.

Assuming you gave up the keys one of the volumes, the metadata for that volume tells you which sectors should not currently be in use.

(I'm really not suggesting this is a practical attack)

AGL

How secure is TrueCrypt against side-channel attacks?

>> There could have been anything stored in that area of the disk before you stored the encrypted container there.

> Although that data probably wouldn't look like random noise (which the container would).

The former data could have been another encrypted container stored in the area in the past (before the present container). There are also other sources of perfectly random looking data (bascially any compressed file, zip, mp3, jpg, avi, etc). No, the "magnetic" analysis is useless.

> Assuming you gave up the keys one of the volumes, the metadata for that volume tells you which sectors should not currently be in use.

As the manual says, containers containing hidden volumes should not be stored on NTFS (or any other journaling file system that uses metadata). You should either store the container on a FAT-formatted disk, or encrypt a partition. Partition doesn't have any outer metadata and is also better performance-wise.

> I'm really not suggesting this is a practical attack

Ok.

"Has it been reviewed by any security professional (like yourself, Bruce)?"

Not that I know of. That is, I haven't recviewed it, and I don't know of anyone else who has.

Steve Gibson recently dedicated a whole podcast to the merits of TrueCrypt. It wasn't of course an academic review, but he certainly endorsed the product.

Podcast:

http://twit.tv/sn41

Transcript:

http://www.grc.com/sn/SN-041.htm

Am I being totally thick or what but if -

> It may happen that you are forced by somebody to reveal the password to an encrypted volume. There are many situations where you cannot refuse to reveal the password (for example, when the adversary uses violence). Using a so-called hidden volume allows you to solve such situations in a diplomatic manner without revealing the password to your volume.

If my adversary is "holding a gun to my head" and asks for the outer password - they know I am using encryption software - then why would they think that I have not set up a hidden volume and not start cutting off my pinkies till I give up the other password as well. With a gun to my head I could be in more trouble if I had not set up hidden volume and they assumed that because there was random data in the free space I could have a hidden volume and they want the key! They may not be that diplomatic.

ps : in the UK we have this lovely draconian/knee jerk reaction thing called RIPA

http://www.theregister.co.uk/2006/05/19/ripa_enforcement/

five years in prison - nice

> start cutting off my pinkies till I give up the other password as well.

If that is your threat model, you don't have to bother to hide or encrypt anything. Even if there was some ideal PERFECT 100% steganography, the adversary would torture you to find out IF you hide anything and WHERE you hide it (and what is the password).

Do you see how your threat model precludes your hiding anything from the attacker?

This "hidden volume" facility gives you actually one of the rare possibilities to satisfy a (not-as-much-violent) attacker by giving him a password to a decoy volume, which may contain something really sensitive, but not the data you really want hide.

If your attacker is willing to go beyond this, you don't have to bother to hide anything at all (even if you had perfect ideal steganography).

One possible solution to the detection of hidden volumes via looking for the number of times various sections of the disk has been overwritten: do regular defragments of both the hidden/outer volumes, followed by freespace wipes of both volumes using a product such as Eraser. This will very likely end up modifying virtually every sector in the encrypted volume. If done regularly, after a few tens (or hundreds) of times identifying via counting changes alone will become infeasible.

You still may have a problem if you have large files in the hidden volumes that don't get moved (e.g. sectors that are never changed). But some sort of variation on this theme that involves changing at least one bit in every block should solve the problem

One other thing...

I use Truecrypt for on-the-fly encryption all the time, both on flash drives and on my hard drives. You can also use Truecrypt to create volumes that are subsequently saved to CD. I always create encrypted volumes that fill the entire CD, to obfuscate how much data is on the CD. An added benefit is that hidden volumes can easily be stored on the CD. With nothing else ever written to the CDs, the hidden volumes stay safe (more of a problem with older versions of Truecrypt) and it's impossible to tell from looking at the disk whether or not a hidden volume is present.

Finally, take a look at Racoon's TCGina implementation that allows for full encryption of user profiles under Windows. I understand there are also efforts to use Truecrypt to encrypt the page file (also possible with Cryptoswap Guerilla, though that may be vulnerable to the same CBC problem Truecrypt recently fixed -- who knows?).

@Paul
>"perfectly random looking data (bascially any compressed file, zip, mp3, jpg, avi, etc)"

Correct me if I'm wrong, but aren't those file types distinguishable from random data? Yes, the basic compressed data that makes up most of the file looks random. But aren't the file format stuff like field markers and the "magic number" (file type identifier at beginning of file) standard? I haven't dug through the specs, but I'd imagine that if I took some of /dev/random and passed it to my mp3 player as an mp3 file, it would give me an error about "incorrect file format" (instead of playing a really weird sounding song). In fact, I'd like to try this test, but don't have a linux box handy. (I am at work right now, which has it's own source of random :)

Been using this since v1.0 and still using it, Linux version is catching up to the Windows version slowly but with great success.
A brilliant product, especially since it is 100% free with full source available.
Compared to commercial "bloatware" products which companies seem more than happy to lay down the green for, I think TC is something indeed to look up to.
I think if someone like Bruce could have a look at it and give his professional opinion this would definetly serve the crypo community.
Things that are closed source seem to get plenty of attention but never are really professionally reviewed, all the unknowing users read is *coff**coff* "military strengh encryption using triple blowfish".....lets not say more.
Something like this goes along the very merits of why PGP was released at first, those that need it in countries where using crypto is illegal or even life threatening could benefit from a program that is not only open source, does not only contain good "plausable deniabilty" but is also given the thumbs up from someone like Mr Schneier.
Just to correct something I read up above on TC been broken in a previous version.

The authors implemented LRW over CBC due to an attack that enabled an attacker to place plain text blocks within a mounted volume, which allowed the volume to be identified from the random space,thus it affects the "plausable deniablity" that TC strives for, this did not affect volumes created with AES-Blowfish or AES-Blowfish-Serpent chaining.

Cheers

Sheldon

Please stop , AES SERPENT and who knows others algorithm have broken by NSA , remenber bruce you comentary on AES , well please stop speaking this stupids things and use one time pads, yes is very molest but secure.

Or just use datacloak from mathew bennet twice or more times encrypting , and yes twice or more times , and your file will be safely really.

Yup, I've been using TrueCrypt for a while. I was using E4M before that, on which TrueCrypt is based. I haven't used the plausible deniability stuff, I just make TC volumes.
Both of my thumb drives have about 16 megs to hold the TC executable and a little bit of scratch space, the rest is a big ole' truecrypt volume. I have a 25GB TC volume on my work machine which holds company confidential info. Even if the machine gets stolen there's a good chance they'll get nothing valuable.

TrueCrypt is a good basis for the "emergency kit" thumb drive that was discussed after Katrina last year; get a thumb drive, encrypt using TC, put on it all your important info, scans of birth certificates, credit card numbers, 800 numbers to cancel credit cards, whatever. Put it in your go bag.
Thumb drives are approaching "free" - $20/GB or less. This is probably a pretty good idea.

For those interested, plausible deniability has been discussed a couple times on the TrueCrypt forums:
http://forums.truecrypt.org/viewtopic.php?t=1781
http://forums.truecrypt.org/viewtopic.php?t=1849

>> Please stop , AES SERPENT and who knows others algorithm have broken by NSA , remenber bruce you comentary on AES , well please stop speaking this stupids things and use one time pads, yes is very molest but secure.

No one knows or has proof that the NSA has broken those algorithms. And using OTPs introduces security risks of it's own -- for static file encryption, specifically, it's usually not practical.

>> Or just use datacloak from mathew bennet twice or more times encrypting , and yes twice or more times , and your file will be safely really.

What's so great about DataCloak? It isn't even open source.

I've switched to Mac and TrueCrypt is the one tool I miss most. Can't wait until Mac version is available.

I have been using Truecrypt for a while and have yet to lose a file except through my own stupidity.

Where Truecrype scores in comparison to Cryptainer and the like is the open source nature of it. Companies go out of business over time but having the source code means that I have a fighting chance of opening those old archives in 15 years time on whatever operating system I will be using then.

I had a look at TrueCrypt a while ago, but the one thing I found to be a problem is that the binaries available under Linux are built against the originally shipped kernel for the distribution in question, and not the latest version that the distribution provide (which contains security updates). So effectively your data might be compromised by other attacks on the system itself which have since been patched, but you are unable to install because installing them breaks the packaged version from TrueCrypt.

I just downloaded the package again to check, and it's still the same, at least for Ubuntu 5.10. The module is built against 2.6.12-9-386, while Ubuntu are now up to 2.6.12-10-386. Of course, you can compile from source, but it'd be nice if they released the packaging information used to build the packages (eg: the ".spec" file for RPM, the "debian/" directory for DEB, etc), something that is not currently part of their source code.

Other than that, it's a great tool.

I'm certain it's also been mentioned at sometime here, but you also have FreeOTFE (www.freeotfe.org). The source is available (don't know if it's an OS license, though).

For Windows / Linux compatibility, it claims to have the ability to use LUKS containers (but cannot yet create them on its own). So you'll have to create the container initially under Linux (probably using the 2.6.* kernel's device mapper and the latest version of cryptsetup). All of the necessary stuff can be installed using apt under Ubuntu (Dapper Drake).

Don't know about third-party review of this program, however.

@Bill
> Correct me if I'm wrong, but aren't those file types distinguishable from random data?

No, 99.99% of good compressed files is pure white noise. The 'markers' are so rare that (if you consider the usual fragmentation which may cast the markers to another area) compressed files are perfect source of non-interrupted stream of white noise. BUT, as I wrote, you can plausibly explain random data by saying that there were old encrypted containers in that area in the past. I don't see any problem.

As regards the Linux 3rd-party kernel module situation: TrueCrypt for Linux has been released only several months ago. It will take some time before all the major distributions will include the TrueCrypt package in their distros. When it happens, the burden or recompiling will be shifted from the TrueCrypt developers to the distro maintainers, and the problem will be solved.

@Paul Novak: we can do a blind test. You send me (a) an mp3 file, (b) a file containing random data generated by you, and (c) a mystery file. The mystery file is either another mp3 file, or some more random data. You know which, and I don't. The game is to see whether I can tell you what (c) is.

In fact, don't bother sending the files, because I will win the game every time, even if you send me smallish snippets of MP3 files rather than the whole thing. MP3, in common with other MPEG formats, contains regular "start of frame" markers, which players can use to seek within a stream for a place to start playing. This is useful if they temporarily lose the signal, or want to pick it up part way through, or whatever (think digital radio).

So if the data contains a "start of frame" marker, followed by an MPEG frame header (which tells me how long the frame is, so I can calculate where the next "start of frame" marker should occur), and then another "start of frame" marker at the predicted place, then it's MP3. The likelihood of it being random is extremely close to 0 - "beyond reasonable doubt". It is therefore extremely easy to tell an ordinary mp3 file from random data.

Don't base your security model on ordinary compressed formats being indistinguishable from random data. They aren't. Even in your own assessment, 99.99% of the compressed data is not white noise, so all the attacker has to do is look at the remaining 0.01%.

> 99.99% of the compressed data is not white noise, so all the attacker has to do is look at the remaining 0.01%.

I mean "99.99% of the compressed data *is* white noise. So all the attacker has to do is look at the remaining 0.01%."

I think your mistake is to think: "The 'markers' are so rare that ..."

Looking at the first mp3 file in my current playlist, it is 10388 frames in a 4332318 byte file. So there's a frame header every 417 bytes on average (and in fact it'll be quite close to exactly that, because it happens to be fixed rate encoded). This isn't enough to make it look random, even if it's 100% fragmented, because the incidence of the "start of frame" markers is much too high and too regular for chance - even with a 512 byte blocksize there should be at least one in every block, but never two closer together than about 400 bytes. So the chances of you being believed if you say that some random data "isn't steganography, just an old mp3 file", are very small indeed.

But yor general point is correct, that provided there is plenty of random data on the disk anyway, one can plausibly deny the hidden sector. So regularly write random data to disk and then delete it: there will always be plenty of randomised unallocated sectors, and you should be fine. Just don't use mp3s as the "random" data...

I am not quite sure what the point of the discussion is. The main argument of Truecrypt's plausible deniability feature is not to hide the existence of an encrypted container. It can be plainly labelled "truecrypt.tc" and stored right next to truecrypt.exe if you wish.

The point is that you can hide a second container within this "outer" volume which cannot be proved to be there unless the correct password is known.

The feature of hidden containers is made possible by the fact that upon creation, Truecrypt volumes are completely filled with random data. This will remain to be the case for all sectors of the container that have not been used to store filesystem structures or files.
The hidden container is stored in an area at the end of the normal volume that usually stays unused (unless you really use up the volume's capacity). In this area, it is impossible to detect whether the data still is the pseudorandom garbage put there at creation of the normal volume or if it is pseudorandom garbage by storing encrypted information there.
This is the point: You will really have random data there no matter if a hidden volume exists or not.

The remaining question is how to make it plausible why the normal container is larger than the data stored inside. You have two points:
1) Make the ratio of the hidden container to the normal container not too big (i.e. the hidden container should not be larger than 20% of the outer container - just making the number up).
2) Who can blame you for your foresight to plan for about 50% of reserve-space in your (outer) volume? It is just that you have not found enough sensitive data to put in the volume *yet*.

I don't get it: If someone took a look at the contents of my HD and there were some files on it called i. e. somelinuxdistro.iso which turn out not to work, when being burned to CD, how would they ever suspect that these are in fact encrypted truecrypt containers? They could just be corrupt files, no need even for a hidden volume. Am I wrong? If yes, why?

Hey guys.

The point of it has nothing really to do with a hidden volume.
The volume is randomly generated data over all, no markers as in many other OTFE volume products.
The point is not to label it as a MP3 file, the point is "if you cannot prove that this is in fact encrypted data, then I have plausable deniabilty"
The hidden volume is simply there if you are forced to give away a password (someone breaking fingers?), then mabey this could come in handy.
Thing is, if you formated your HDD with TC, which is then filled with random data, you could say to "Mr Smith" from the FBI that the disc contained sensitive information which you destroyed with something like DBAN a few weeks ago.

If there is a file with a header/marker which shows its a DriveCrypt volume, there is not much you can say.
If however the attacker does not know for sure what the file/device/harddrive is, and if there is any hidden volumes, if there is in fact any encrypted data or just the random bits left over from your DBAN shred, then you have something to work with.
Lets face it, nothing is perfect, this just provides some tools that can be used for those who need it.

Cheers

Sheldon

Guys

The reason it is there is NOT for you to name a TC volume as song.mp3 and expect your attacker to belive it really is that.
BUT
If you formatted your HDD with TC, it will be now filled with random data.
You could tell the attacker that you had sensitive data on it a week prior which you have destroyed using Darik's Boot and Nuke disc, thus the reason for all the random data.
The hidden volume is ONLY there if you MUST give away a password.
Someone has you and is breaking one finger at a time, lets face it though, if it got to that, you would probably be toast even if you gave away the password.
But if giving away the HOST volume password that has some sensitive looking data can get you off, then that is what it is there for.
Nothing is perfect, but it provides tools that can be used if needed, mabey it wont save your butt, but it sure is better than having nothing.

The whole point that people seem to forget about "plausable deniabilty" is not that you need to prove that it is not an encrypted file or data, its for them to be able to prove it.
If you were in court, and it was demanded that you hand over your keys, yet they cannot prove that it is in face encrypted data, then how can they reasonabily expect you to give a password that may not exist?
Under that as well, if you had a volume file with a Hidden Volume, it would be a FAT volume.
You could be questioned why is it a FAT volume, there must be a hidden volume, since this is a feature that TC has, the product was found on your captured system.
Your argument can be made that you use FAT because you backup your TC volumes to CD-R's, and also use FAT because it is a filesystem that is easily used and stable across generally all OS's that TC supports.

Cheers

Sheldon

@ Cryptkeeper

Well, I'm not sure of the details for a CD image .iso file, but someone, from say, the government, might be able to look at the file and determine that it isn't even close to a valid filesystem, then ask some very pointy questions about it.

If you, instead, had an encrypted volume with some decoy sensitive-looking data on it (bank records, whatever) in which you could hide another hidden volume, it would be easier to explain away its existance.

Sorry, double post, my bad!!
Didnt seem to go through first time

Cheers

Sheldon

@Andrew2

Yes I agree with you.
The file volume that is filled with random data to me would raise plenty of questions in the right hands.
I feel more comftable with devices such as USB KEYS and HDD's that have been fully formatted with TC, then your device would simply be filled from start to end with random data.
This with todays freeware data destroyers such as DBAN can be easily explained I feel.
I think with a file volume, the hidden volume aspect could be quite handy to get out of a tricky situation.
I'm waiting for the ability for TC to create RAW CD/DVD's in which you can write the volume's raw random data to the CD itself, thus you would now have an encrypted CDFS.

Cheers

Sheldon

> Do you see how your threat model precludes your hiding anything from the attacker?

Not all people live in a jurisdiction, where the judges are both independent and mathematically literate. I'm not even sure there are any.

"Plausible Deniability" is a pure mathematical term and is also dependant on perfekt encryption besides the excellent legal system mentioned above.
A one-time-pad is such a perfect encryption and let's say we use XOR (A XOR B = (A \vee B) \wedge \neg (A \wedge B)) as the de/en-crypting algorithm. You can have two keys: one that decrypts the file to a bunch of credit card bills with a couple of slightly embarassing entries and another one that decrypts that file to the blueprints of the invention your competition dies for.
The file can be decrypted to anything with the right key, so the competition arranges a certain number of bytes such that it decrypts the file to a bunch of child-porn and starts to blackmail you to get the blueprints.
And now look for a judge who understands the math behind that and accepts the "Plausible Deniability", but that's way to late of course: in case of an accusation of child-porn, the indictment alone will kill your life.

You see: you dont't need any kind of torture in this case, you don't even need the fact, that the mere existence of "Plausible Deniability" contradicts the existence of "Plausible Deniability".

But there are a lot of threads where "Plausible Deniability" is needed and usefull and TrueCrypt is a nice and easy way to get it. I can recommend it although the new implementation of the encryption algorithms hadn't been examined yet as it seems. Any volunteers for the code audit?

CZ

About a year ago I contacted the TrueCrypt development team about doing an OS X port. I had contacted Apple and wrangled the documentation for the private DiskImages framework out of them, which would have let me write a plugin to mount .tc files as if they were encrypted DMGs. All I wanted from them was some cooperation on the port - I could handle the OS X-specific stuff, but I wanted help making it a fully functional TrueCrypt port rather than a hack.

They pretty much told me to go screw. I was told that there's an OS X port "planned" with no concrete plans to do anything about it (and here we are a year later with still no OS X support), and they didn't want "outside" developers.

Whatever, I've got other things to do anyway.

Besides plausible deniability, what's the advantage to using TrueCrypt (or some other third party tool) over Windows XP's built-in file encryption? Is XP's encryption known to be weak or is it just untrusted?

> Is XP's encryption known to be weak or is it just untrusted?

Yes, the Windows EFS encryption is as weak as all single-file encryption software (as opposed to on-the-fly volume encryption software).

Windows EFS stores the data you encrypt in a temporary file *unencrypted* and then deletes the file to the recycle bin (which can be recovered). If you want to decrypt the file, again the data are decrypted to disk (stored unencrypted on the disk), which is very insecure.

With on-the-fly volume encryption (such as TrueCrypt) the data are never unencrypted on the disk. It's real time and transparent encryption. That's the main advantage over Windows EFS encryption (and other single-file encryption software).

I use it from the beginning. It's also a good backup solution. I have ~700 MB container files which I put on CD regularly. Additionally, I put TC itself and a batch file onto it, so this will work in some future. If the cdrom survives. And I remember the super duper high entropy passphrase...

TC is hassle free, my drives survived any bsod's.

And finally, together with tcgina its really worthy, because you have %userprofile% and \hkcu encrypted.

Looks prommising.

But about the header part i saw would not be deniable, plausible deniability: yes.
Anyway, i just downloaded it and i'm pleased with it.

Had a problem with an external USB drive using TrueCrypt 3.1. Windows had an Ftdisk data flush error and the entire USB drive became unreadable. It mounted and all, but Windows saw it as RAW data and nothing more. The TrueCrypt forums have quite a bit about USB drives getting corrupted for lots of reasons, not all of which are TrueCrypt related. They strongly urge you to back up your data (always good advice), but that means you need to secure it in two places instead of one.

Attacker: Give me your password or we'll kill your family.
User: OK, it's "fraggle1986"
Attacker: What do you think we're stupid? You're using TrueCrypt, give us your other password or we kill your family.

It's a great idea, but there's a 50/50 chance a user has a secret volume because that's why you use the software. So, I guess the moral of the story is to always have at least three volumes, normal, hidden 1 and hidden 2 so you can have two levels of plausible deniability and give up your fake hidden 1 volume under duress.

I couldn't tell from a brief overview of the site if this was possible or not.

Bill McGonigle Writes:

"It's a great idea, but there's a 50/50 chance a user has a secret volume because that's why you use the software. So, I guess the moral of the story is to always have at least three volumes, normal, hidden 1 and hidden 2 so you can have two levels of plausible deniability and give up your fake hidden 1 volume under duress."

And lets not forget that in many (most?) cases that involve getting data off a computer there is going to be a good amount of evidence already collected. IOW, they know you have what they're looking for, they'll know you're using a utility that allows "nested" containers, and they'll know that the stuff they're looking for isn't in the encrypted file you just gave up the keys to.

You have to ask yourself if you were a jurist, would mere denial of the inner container be plausible? Especially of there's enough evidence already in front of you to bring the matter to trial, or even result in a warrant?

@Jon: If they have enough evidence to get you convicted without the contents of the container, obviously plausible deniability won't save you.
If they haven't, they cannot be 100% sure that the stuff is there (they may strongly believe it, though) but the chance exists that there actually is no hidden data and they can't prove you wrong if you say so.

"Besides plausible deniability, what's the advantage to using TrueCrypt (or some other third party tool) over Windows XP's built-in file encryption? Is XP's encryption known to be weak or is it just untrusted?"
DISCLAIMER: I never tried EFS, so I have no own experiences with it. Here is what I (believe to) know:

AFAIK, it uses the user's login password. Further, some time ago I came across a web site where they claimed that they could "recover lost passwords" for EFS withing 10 minutes or so. No URLs at hand - trust me or google ;-) But I promise nothing - maybe I misunderstood something...

Have fun
D.

Don't you love anonymous commenters?
"Windows EFS stores the data you encrypt in a temporary file *unencrypted* and then deletes the file to the recycle bin (which can be recovered). If you want to decrypt the file, again the data are decrypted to disk (stored unencrypted on the disk), which is very insecure."
Rubbish.
EFS doesn't do what you are talking about, except when you are copying a plain-text file into an encrypted file, or copying from an encrypted file into a plain-text folder.
When you read from an EFS file, the NTFS driver decrypts the file into memory, and hands that memory to the process that's reading (assuming that you have rights, and an appropriate key); when you write, the NTFS driver takes the memory buffer you supply, encrypts it, and writes that encrypted buffer to the disk.
Think about it - what sense would it make to decrypt to the disk, when the operation works in memory?

I use disk encryption to protect me from a much simpler threat model : having my computer lost or stolen.

I want the crypto to be good enough that the "new" owner will just format the drive. All I loose is the hardware.

I use EFS with the syskey option that ask for a password at boot. I beleive it is safe enough for my threat model. I even managed to make it work transparently across computers on a USB drive.

But TC isn't integrated with Windows certificate store, and that's a plus for me. My private key "disappered" twice. Turns out I stumbled across a documented Windows XP SP2 security measure (Q290260). Nonetheless, all this certificate chaining is useless pain in the neck, since the syskey password is really the only secret.

I'll be swithchign to TC now...

ps: I had a EFS recovery agent key stored in another location, no lecture about that please !

@ Paeniteo:

Whether they have enough evidence for a conviction is irrelevant. They will want the additional evidence either way. That's their job.

You're also forgetting that 100% proof isn't necessary in most legal systems. Nor does "plausible" denote any sort of absolute. The criteria is going to be "reasonable doubt" in most cases.

In a lot of situations your plausibility factor will be exactly zero because only the most unreasonable person wouldn't doubt you were lying your a$$ off. ;)

All this arguing over the plausible deniability feature is a bit silly. If you have data that people are willing to hurt/torture/kill you for, that's a whole different ballgame.
Most "normal" users would use TrueCrypt to encrypt data that they wouldn't want someone to get if their laptop or USB key was lost or stolen. TC does a great job in that situation.

@Spong:

That's too bad they weren't cooperative - but if you've got the Apple expertise, what more help do you need from them?

It seems to me that even a TrueCrypt "hack" is better than not having TrueCrypt functionality on OS X at all. I use OS X, Windows, and Linux platforms and I know it would be a huge boon to me to use this on all three. I just lack the chops to make it happen.

Mark J. - "They strongly urge you to back up your data (always good advice), but that means you need to secure it in two places instead of one."
Actually you don't need to secure it that well. That's part of the point of encryption. The raw encrypted data can (in theory) be freely available to anyone since no one would be able to decrypt it.

Ye, you will also note that they advise you to create a NEW volume for backup, not using an imaging tool such as GHOST as this then would allow an attacker to check one volume against another since both would have the same master key, salt and so forth.
Like someone said before, the purpouse for someone like me using this is not to hide data from the NSA, its for legit reasons, I dont expect someone to be kicking down my door for my encrypted HDD.
TC over all is good in my eyes in that source is available, it is a slimline package that gives you what is needed without all the bells and whistles.
So many commericial packages are 10-15Mb in size, and personally in my opinion are just bloatware.

For me it comes down to safety, stability and usablity, in that order.

Cheers

Sheldon

Hi. Interesting thread. Has anybody used TrueCrypt on a U3 device such as Memorex MiniTravelDrive? It would seem that melding the units existing password protection and this product would make the units much more secure. [I just had a person show me a hardware device that basically direct disk level read of the password-protected U3 device. Now I'm thinking it isn't as safe as I had hoped...

Also check out http://arg0.net/wiki/encfs
For linux. Uses the Fuse kernel module (filesystem in user space). Nice thing is that it is a file-system that can expand to the size of the space on your harddrive since it operates on files, not a device (loopback or otherwise). I.e., I am "mounting" a directory tree.

Used it for a long time for my laptop email, and web-browser directory. I also have an ecrypted tree on my USB thumbdrive. I absolutely love it.

Disadvantage: you have to modprobe the kernel module on RHEL and Fedora 4 and below as Fuse is not compiled in by default. Fuse *is* is available out of the box on Fedora Core 5, but I had to muck with file permissions to make it all work. So... not perfect as far as "out of box" experience just yet. But, in the end, it is easy, and works nicely. I have used it for a year or two now.

-t

Wonder if Mr Schneier (or any other security pro) is ever going to review True Crypt... This would be very helpful, both to the customers and to the developers.

Any word on when this will be out for OS X? I'd really like to not have to do a virtual machine just to be portable.

Now imagine:

Windows or word for windows tell that the last opened files are file1.doc and file2.doc

Now it happens that your outer container does not have any such file1.doc

Now add the fact that all files on your outer container are over 2 months old.

There goes your plausible deniability.

To defend truecrypt, the most recent version allows you to mess with the container, still protecting the hidden drive (you need to input BOTH passwords to open the outer container and to protect the inner). So you actually should fuzz around on the outer container occasionally, to maintain plausible deniability.

Comments??

This whole thing is stupid.
Any one know if police find evidence that you installed ANY encryption program on your hard drive your as good as GUILTY IN THE GOVERNMENT'S EYES!!!........
The only hope if you want to encrypt and not have it show that you installed the program is to rum from a live CD (LINUX)
SLAX
PC LINUX OS
D@AM SMALL LINUX
KNOPPIX

Any linux variant that boots from usb or CD is great.
You people don't want to be encrypting stuff using a hard drive--thats just plain stupid!!!!!!!
Any of the above OS'S will boot from a sandisk cruiser or cd.
Slax has a mod for truecrypt that works quite well.
If you ever come under the gun of your local prosecutor you will know the first thing they go for is the HARD DRIVE,then your CD'S then you keychain devices.
Just to keep it simple here,they can't unerase a HADRD DRIVE that was never in the computer in the first place.
If you really want to get nasty you can buy what is called a (I-RAM card ) made by Gigabyte.
It replaces your hard drive and gives you 6 gig of virtual hard drive space all on DDR on a card that fits nicely into a pci slot in your computer.
Want all your data gone in litterally 2 seconds?
Break the red wire running to the battery of the card.
DDR is volitile memory and requires voltage to keep it alive and your data in place,unlike a hard drive that can be removed and un-erased.

It seems to me that the plausible deniability of the hidden volumes relies exclusively on giving some plausible explanation for large amounts of random data on your disk. This is where the outer TrueCrypt volume comes in.
Any other plausible reason for storing random data would do just as well. Not that I can come up with any.
At any rate, to have any kind of plausible deniability, you shouldn't store all your data in such a hidden volume.

@Robert

"Any other plausible reason for storing random data would do just as well. Not that I can come up with any."

I can give you a reasonably good reason for having random data in all the tracks and sectors of a drive, or for that matter in files as well.

They have been "securley erased" as part of company policy.

There are security products out there that use encryption as random data generators to repeatedly overwrite tracks and sectors of files and hard drives to securly erase them. As long as they use the same algorithum as TrueCrypt uses it would be difficult to tell the results apart.

All you have to do is get used to allways using it to erase files to build up a belivable history.

"This whole thing is stupid.
Any one know if police find evidence that you installed ANY encryption program on your hard drive your as good as GUILTY IN THE GOVERNMENT'S EYES!!!........"

I hope not. Anybody with any Windows version that supports file encryption would be in big trouble by that standard. Also anybody with WinZip. And most backup software will encrypt the backups, too. I guess we're ALL toast!

I have loved TrueCrypt ever since i first layed eyes on their site. The implimentation and methodology those guys use is solid and secure. I would trust my most valued data with TrueCrypt, because of 2 things: 1, They update all the time and add new functions, and 2, its Open source. Open source is very important for security. This kind of outfit is just what the public need to feel secure with storing their data on a PC. I would also like to say that it has a linux version too which is very cool. These guys put lots of time and effort into each release of this amazing software and it just gets better and better.

I'm using true crypt to encrypt my sensitive documents and burn it to DvD..At first there was no problem.But the problem occurs when i'm using containers to put my encrypted files.After i defrag my external hard drive,the drive seems to be not readable and corrupted.I have many inportand file in there..It would be really helpful if u can help me with this problem..

@Bret H,

-"If you really want to get nasty you can buy what is called a (I-RAM card ) made by Gigabyte.
It replaces your hard drive and gives you 6 gig of virtual hard drive space all on DDR on a card that fits nicely into a pci slot in your computer.
Want all your data gone in litterally 2 seconds?
Break the red wire running to the battery of the card."

I like the way you think brudda, after reading your comments, I plan on my next OS hard drive purchase being a Gigabyte RAM card. I imagine an additional benefit would be blazing disk I/O performance to boot.

Currently I use truecrypt partitions under Windows XP and Linux to store all my personal data. But I've always thought it made better sense to boot your machine to linux using a USB key or CDROM, and then use loop-aes to encrypt the *entire* hard drive, partition table and all (if that's possible) so that to any disk forensics tools, the whole hard drive appears to be filled with random garbage data.

Jose,

Dude, try cutting down on the grass.. it's making you paranoid.

Dear Sirs/Madames,

I made my Truecrypt and put my confidential docs in and so happy. Great application. Used it frequently for 2 weeks. Didn't use it for another month.

Pass was a string of personally meaningful words and one or two irrelevant nonalphanumerics, about 16-18 characters long in total.

It was a busy month and blammo, I forgot which unique nonalphanumerics I'd used, still recall entire meaningful chunk.

Perhaps this situation suggests a challenge. Imagining Russian mafia or the Feds got my encrypted dossier about JFK. Could they crack a pass of this nature? I don't pretend to understand half of what I have read looking for an answer, but would some dictionary-informed bruteforce attack of the password input field be likely to work within my lifetime-? I could create a similar but much smaller sample volume with a similarly constructed pass for target practice.

Ignoring the antagonists, it's a realistic scenario. Any tool that does this would be a valuable pass-integity tool for the many users of TrueCrypt. And, coincidental to that great public service, it might get me my files back. :)

Any ideas or takers welcome.

Compression vs. Randomness.

The test for "optimal" compression is that it passes any test for randomness. Intuitive, but not easy to prove. If interested, Google Greg Chaitin or Bob Floyd for many fascinating articles on the subject.

I am glad I found TrueCrypt and am about to try it, after unrecoverable disasters with PGP Corp's software - the original PGP of course works great.

Just to throw in my two peneth here, why not allow future versions of trueCrypt to accept a self destruct character(s) that can be specified at the time of encryption. For example I specify the SD characters to be '%' or the word 'Now', and my normal password to decrypt my file was 'OpenSesame'. If I told my adversary under duress of losing one or two pinkys that my password was 'OpenSesame%' or 'Open%Sesame' or 'OpenSesameNow' then Truecrypt magically decrypts the container into view before the adversarys very eyes just as they would expect having been given the 'correct' password, but on inspection there is nothing to see, the container is empty. Truecrypt indertakes the destruction of the data within the container whilst allowing the container to be shown. My point is, from a plausible deniability point of view, you could conceivably prove you have given the correct password because the volume decrypted and became viewable, its not my problem I hadn't got around to storing anything in it yet. Prove that one.

I had the same idea as Dave, but got to the end of this thread and found that Dave had beaten me to it. Doesn't have to be self-destruct characters, but potentially a different password; whatever. Of course the down side is that you lose the data you are trying to protect, but at least you have the choice, given the ensuing circumstances to decide whether data loss is better than the looming alternative.

How do I get my hands on a alpha osx version of TC? Got to be one out there....

--donofrio

As far as I can see it, Daves scheme with self-desruct password would to the aversary appear no differently than using an inner hidden TC container while keeping the outer container empty. From your own viewpoint, the difference is that you still have your data (assuming your adversary doesn't confiscate the medium).

I have the same problem as "locked out" above.

I created an encrypted container and moved information onto it.

I have since forgotten the exact password.

I do know, however, the basic form of the password. Where x is a number or character or non-existent, my password is of the form:
xxxsomewordxxx
It is painful to try and go through all the possible combinations, however, I don't know of any tool that is likely to be able to brute force the password.

Not being a programmer, I'm not about to be able to modify the Truecrypt code to enable me to implement such a scheme either.
So, for anyone out there who can program in whatever language Truecrypt is in, it would be grand for a function to enable bruteforcing based on a pattern.

Anyway, apart from forgetting the password for this one container, I've used Truecrypt for a while, both the Linux and Windows versions and I am very happy with it. It would be nice to have a GUI for the Linux version, but I can cope.

(I can't be fucked sending an email to anyone, so I have removed the URL. If this still trips the spam filter ...)

@Dave

I could save a copy of the encrypted volume beforehand and break more than a few pinkies if I find that the volume has changed significantly just by "decrypting" it.

Wow so many people saying how easy truecrypt is to use, how great it is. I just tried it for the first time and it seems like a real pain initially...create, format, mount..bla bla bla. I haven't been able to create an encrypted container yet, seems to loop around over and over. I'm feeling dumb but then I didn't read the manual either. So far there seems to be too many steps to get a simple container encrypted and that's frustrating. The program doesn't flow for me.

I guess it's way better than the program that comes on Sony flash drives but that one is chimp simple. Even I figured it out without any reading. I'd like to use it on my other flash drives but Sony makes it so it works only in Sony drives.

Truecrypt reminds me of the place I used to work where they had three doors one must pass to get out of the data center to the toilet. Each door required one to enter ones social security number at each door before the door opened. How fun is that especially with enlarged prostate? Data is safe even if your britches are wet.

i was just looking for truecrypt, and upon failing to find it decided to google, found this site that discusses it. any idea where truecryptDOTorg went?

@new user:
if you are having trouble, try Google for "truecrypt", but the website url is as you have written it...newest version is 4.3A as of this writing

Hey, I'm the same anonymous idiot as above. Well, I've since written a PHP script that sort of does what I want. It is still in early stages of development, but definitely brute forces passwords (but unfortunately, only the easy ones (one could say trivial) so far)... I think there is a problem in my program...

Anyway, I'll upload it eventually and it will be released under a nice licence (GPL3 perhaps?).

Just a heads up, but if you are writing your own, don't stop...

Anon I.

I am using Private Disk, it has a whitelisting feature that allows only some specific applications to access the virtual drive.

So in summary, If someone stole my laptop with TrueCrypt encryption on my sensitive data, what would be their main approaches of deciphering that information?

Having trouble trying to open a Truecrypt volume...The host file/device is already in use....Any ideas would be greatly received.I am using Vista Home Premium.
Thanks, John

Less a comment, more a question. I'm testing TrueCrypt and it seems to do what I need EXCEPT if I copy large numbers of files to an encrypted container, after about 15,000 it give me an error message saying it cannot create the file. Does anyone know whether there is a limit to the size of directories under TrueCrypt?

Shouldn't be. IIRC TC handles only the low-level stuff of encrypting the buffer that holds the data that is to be written to disk. The whole filesystem part is handled by the operating system. So it ought to be Windows that can't create more files. The filesystem on your TC volume is most likely FAT, right? FAT has severe limitations, especially when it comes to the the capassity of the root directory. Create folders, that ought to help.

As for the idea of self-destruction: didn't the author of FreeOTFE offer a "helper" application for all kinds of OTFE systems that could among other things delete (or even wipe?) specific files on hotkey or even when instructed over the net? If so then that could be used for the self destruction functionality... It does, of course, presume that you are allowed to enter the password yourself or atleast the feds haven't made sure that you're not running some unwanted program when they enter your given code :)

@ Albert

I think it's related to the multi-platform nature of TC. The program doesn't really use ASCII characters, but the HEX codes created by the keyboard when pressing those keys. But keyboards are different, much also depends on codepage the operating system is using. Sticking to well known ASCII codes gives the certainity that the password you enter under Windows is the same that you get when pressing the same keys under Linux. The password ain't used directly anyway, only as part for creating the main key used for en-/decryption, so this shouldn't even be an issue.

I use truecrypt on a bunch of external USB2 hard drives. My desktop computer is a Dell SX280 - ultra small form factor (nice and quiet too) with a 40GB sata drive. I use Drivecrypt Pro Plus Edition (256-bit AES) with bootauth (pre-boot encryption password). It has the option of using a hidden container, but I don't use it. With windows running and a screensaver password in place, my data (and all of windows) is completely secure if taken/seized.

I really like the AES-Twofish-Serpent option in truecrypt - go ahead, image my drive and load it into RAM on your 1024 core cryptoanalysis server with each core running its own thread of a segmented & distributed mega-dictionary/brute force attack. I don't care if you hit it with alien technology out of area 51 - I'll be long dead by the time the encryption is broken.

I'm also a strong proponent of the Gutman 35-pass wipe whenever I acquire a used hard drive. I can't believe too many people actually do it as it often takes me more than 50 hours depending on drive size and speed. I usually only do this if I'm keeping a drive for myself, 7-passes should be good enough for the next guy. I like the Abylon Shredder app, it's more stable than others I've tried like Eraser (windows at least). Abylon also has some encryption tools that I haven't played with - Drivecrypt and Truecrypt are enough for me to remember.

I'd really love to be able to format a drive up on a mac and encrypt either the drive or make a .DMG or other file (.TC) and mount it on a windows box, give it a key and be able to read & write. I use macdrive frequently to read mac format external hard drives, and I like it, but it doesn't support encrypted DMG files. Hopefully I'll get it with the new scheduled release of truecrypt.

It is funny the random data worries. Why not just call the file randomdata.bin and find some excuse to use it in another application.

All this theorizing about hypothetical people being interrogated for their passwords - How often does this happen in real life? Sadly, I was personally involved in a state/federal drug bust that resulted in the seizure of two computers in may, 2000 - both were filled with all sorts of encryption software, both linux & windows based, and I was never even asked about it!

I've used 5.0 a while now, and now have 5.1a. How do I upgrade 5.0 to 5.1a without uninstalling the old version, or corrupting the truecrypt partition. I don't have enough free space on my hard drive to recreate the partition, and want to have the features of the new version.