Comments

Morgan • May 29, 2006 8:00 AM

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.

Kel-nage • May 29, 2006 8:02 AM

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.

Paul Novak • May 29, 2006 8:11 AM

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

Adam Langley • May 29, 2006 8:55 AM

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.

Paul Novak • May 29, 2006 9:14 AM

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.)

Hadi Hariri • May 29, 2006 9:15 AM

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.

Paul Novak • May 29, 2006 9:21 AM

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.

Steve • May 29, 2006 9:37 AM

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.

Thunderdog • May 29, 2006 9:53 AM

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?

Alan Porter • May 29, 2006 10:18 AM

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.

Michiel • May 29, 2006 10:32 AM

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.

1915bond • May 29, 2006 10:50 AM

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.

Anonymous • May 29, 2006 10:53 AM

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.

Nigel Greenwich • May 29, 2006 10:57 AM

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 !

Paeniteo • May 29, 2006 11:30 AM

@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.

Dominic White • May 29, 2006 11:32 AM

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).

M Dundas • May 29, 2006 11:38 AM

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

Anonymous • May 29, 2006 11:40 AM

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

Adam Langley • May 29, 2006 11:53 AM

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

Paul Novak • May 29, 2006 12:52 PM

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.

Bruce Schneier • May 29, 2006 1:12 PM

“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.

Anonymous • May 29, 2006 2:05 PM

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.

Anonymous • May 29, 2006 4:45 PM

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).

Jonathan • May 29, 2006 4:58 PM

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

Jonathan • May 29, 2006 5:03 PM

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?).

Bill • May 29, 2006 5:58 PM

@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 🙂

Sheldon Botha • May 29, 2006 8:13 PM

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

jose • May 29, 2006 9:24 PM

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.

jose • May 29, 2006 9:26 PM

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.

John Ridley • May 29, 2006 9:30 PM

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.

B-Con • May 29, 2006 9:45 PM

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.

Joe • May 29, 2006 11:44 PM

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

Andy Fletcher • May 29, 2006 11:51 PM

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.

Stuart Young • May 30, 2006 1:53 AM

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.

RonK • May 30, 2006 3:05 AM

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.

Paul Novak • May 30, 2006 3:19 AM

@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.

Steve • May 30, 2006 5:38 AM

@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%.

Steve • May 30, 2006 5:40 AM

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%.”

Anonymous • May 30, 2006 5:54 AM

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…

Paeniteo • May 30, 2006 7:11 AM

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.

Cryptkeeper • May 30, 2006 7:23 AM

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?

Sheldon Botha • May 30, 2006 12:36 PM

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

Sheldon Botha • May 30, 2006 12:50 PM

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

Andrew2 • May 30, 2006 12:54 PM

@ 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.

Sheldon Botha • May 30, 2006 12:54 PM

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

Cheers

Sheldon

Sheldon Botha • May 30, 2006 12:58 PM

@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

Christoph Zurnieden • May 30, 2006 2:27 PM

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

Matt Spong • May 30, 2006 11:30 PM

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.

Longwalker • May 31, 2006 12:35 AM

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?

Anonymous • May 31, 2006 2:12 PM

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).

Anonymous • May 31, 2006 2:46 PM

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.

Jungsonn • May 31, 2006 3:13 PM

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.

Mark J. • May 31, 2006 9:34 PM

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.

Bill McGonigle • May 31, 2006 10:05 PM

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.

Jon Smith • May 31, 2006 11:28 PM

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?

Paeniteo • June 1, 2006 2:06 AM

@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.

D.W. • June 1, 2006 1:15 PM

“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.

Alun Jones • June 1, 2006 6:24 PM

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?

Guillaume • June 2, 2006 9:00 AM

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 !

Jon Smith • June 2, 2006 11:55 AM

@ 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. 😉

Peter • June 3, 2006 5:11 PM

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.

MikeWas • June 5, 2006 7:25 PM

@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.

Peter • June 6, 2006 9:00 AM

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.

Sheldon Botha • June 7, 2006 8:44 AM

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

Mark Friedman • June 9, 2006 3:31 PM

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…

todd • June 12, 2006 7:18 PM

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

ET • June 24, 2006 3:33 PM

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.

bking • July 2, 2006 11:22 PM

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.

Mario • July 17, 2006 10:20 PM

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??

Bret H • August 14, 2006 4:13 PM

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.

Robert • August 19, 2006 3:29 PM

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.

Clive Robinson • August 19, 2006 9:02 PM

@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.

David Dyer-Bennet • August 28, 2006 9:50 PM

“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!

Steve Gibson • August 31, 2006 5:29 AM

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.

Phat-D • September 6, 2006 8:27 PM

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..

Seth • September 26, 2006 1:49 PM

@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.

locked out • November 8, 2006 10:43 PM

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.

Derek • December 15, 2006 3:24 PM

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.

Dave • January 17, 2007 4:08 PM

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.

Abdul • January 29, 2007 12:20 AM

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.

hrarne • March 4, 2007 9:55 AM

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).

Anonymous Idiot • March 5, 2007 6:22 AM

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 …)

Anonymous • March 13, 2007 5:24 AM

@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.

Bud • April 21, 2007 9:53 PM

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.

new user • April 26, 2007 7:45 PM

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?

sigid • May 14, 2007 2:11 PM

@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

Anonymous Idiot • July 2, 2007 3:54 AM

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.

Niha • July 24, 2007 4:28 AM

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

PeterLarkin • August 2, 2007 1:00 AM

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?

Thunderbolt • August 7, 2007 1:40 PM

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

AlanOswald • January 17, 2008 11:24 AM

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?

CyberRax • January 17, 2008 8:58 PM

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 🙂

CyberRax • January 17, 2008 9:16 PM

@ 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.

General Idea • January 20, 2008 4:49 PM

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.

Anonymous • February 7, 2008 9:11 PM

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.

bitrat • March 26, 2008 11:49 AM

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!

ShadoFyre • May 3, 2008 1:09 PM

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.

Dark Encryptologist • May 23, 2008 6:47 AM

Hi 🙂

I work a lot with decrypting files hidden by people…

You guys think in the wrong way…

People like me attacking you files are using very diffrent approches.

First we will attempt to run a ordinary password list. Then we will add personal information permutations. Bitrh, dog’s name and so on combined with a dictionary…

Then we will attempt to se if the chosen algorithm has a vounrability. A surprising lot have, but not the type of hole you are looking for. I always attemt using ways of skipping calculations, making it faster to test keys. Using assembler code doing a simple cmpsw (Compare stringword) as a first check you will have a 16 bit comparison. Quite fast. Then doing a thorough check.

Most times when we try too open an encrypted file you guys forget the passwords and the keys are the biggest security problem. How long is your password… 10-15 chars? Encrypting onley certain parts of the truecrypt volume, I find structure identificators of the disk system. This makes it possible to test the password very fast.

If a key is used, it usually is stored on the disk or other places where I will be able to access it. Often the key will giv 20-48 bits thaat are locked to what type of application, version, algorithm and padding that is used. So you can often appliy the same kind of attack…

No new info in the way of attacks here… Still works… I dear say I get a hit on 25% of all the systems I attach withing 2 weeks. Close to 50% within 2 months.

But this is because people forget the system is not stronger then the weakest point of the system. Usually beeing the passsword length and chosen characters.

Aprox 13*4 keys ~ 50 visible keys where 31 common and with applied statistics 60 of passwords onley use 23 keys. All depending of language and stuff… Do not think of the numbers, but the concept… (The number are probably of as I should be sleeping)

So a 7 char key = 27512614111 = 31 bit

I hope I calculated this correct… Quite tired…

So what you guys should do is two things…

Create reandom passwords with a length of 10+ chars. This will stop most. Using a special char increases security very much…

And using keyfiles is smart as it helps against key loggers.

Use a dual algorithem approch as it is much harder to crack. If you where to have one back door into a encryption you might not have it for the second…

The slower algorithem the worse it is for brute force attacks… As it is frustratingly painful to wait for…

I have never tried finding a hidden TC volume, but often you can easily find traces. Just look in the recent file list in the registry. Then you will find a path and filename you can not find in the voulme or the deleted entries in the voulme. If it is many files you will have a pin pointer… But even so you would not bother doing it… And you would find it with the atttacks…

Is you want a really securesystem… Hide you keyfiles in a truecrypt volume. Then the second voulume will be awful to gain access to without accessing the first…

Second problem I found was someone mounting the “honnypot” voulume. Getting a key from there. Then opening it again accessing the hidden one with the key from the first… Quite confusing philosophy…

Per 🙂

Sam • June 6, 2008 12:00 AM

How does anyone know that truecrypt actually works? And who is behind the software anyway? it could be a government front for all anybody knows.

roflsam • June 9, 2008 8:37 PM

@Sam

They key words are “open source” Sam. The source code is given so that anyone can look at the way the software package is built. If there are hidden back-doors built into open-source software that millions of people use; someone (a programmer) would have noticed it when examining the code. There are more smart people out there than you think, some of which whom will not use software unless they can view and examine the source code.

Ward • June 16, 2008 8:37 AM

keyfiles don’t protect you against keyloggers! a keylogger intercepts the data stream coming from the keyboard, before you encrpt it, so your adversary simply reads what you typed before its encrypted. haha

Sam • June 16, 2008 5:22 PM

@roflsam

Examine code? Lol, I’ll bet 95% of the people on this forum couldn’t do it if their life depended on it. Who exactly examines the code of any open source apps? Do you? Or do you even know anyone reliable who does? My guess is no one ever examines the complete code, line by line, actually looking for exploits, they just assume everyone else is doing it. But does anyone? Probably not.

The Coderz • July 13, 2008 9:07 AM

@Sam, your point of view is pretty naive. No institution would produce open source software containing back doors and stuff like this. Because somebody would notice.
The second part is that actually a lot of people will look into the source code, because they want to take part in the development, need to analyse it for their company or just because they want to learn something.

You should never ever underestimate the eagerness of the open source community.

At a guy some postings above: using a password of the form xxxsomewordxxx is pretty weak, every more sophisticated dictionary attack will find it within minutes.

And to be honest it is more safe to use a strong password and note it on paper than using a weak password. Of course you should NOT tape the paper next to your monitor.
And you should destroy the paper as soon as you’ve memorized the password (this means when you can type it without reading from your note for some time).

Personally I’m keeping always a list with all passwords. And I don’t expect some terrorists to hurt me to get access to my encrypted data..

From what I’ve been reading here I suppose half of you are working for CIA and have to confidentional information on their computers and are thretened on a regular basis.

If your’re living in a country where human rights are respected you don’t have to fear for your live if you don’t give them your password and it’s very unlikely for the normal person that someone would hurt them to get the information.

If someone would threaten me to get some information from my company which is on my computer I would give them instant access to it. Why should I risk my life or health for it?

Clive Robinson • July 13, 2008 4:03 PM

@ Ward,

“keyfiles don’t protect you against keyloggers!”

Actually they can it depends on how you use them.

As you note,

“a keylogger intercepts the data stream coming from the keyboard”

But what if you do not use the keyboard in a meaningful way?

Also as you note a key loger only logs,

“what you typed before its encrypted”

If you do not type the file name or it’s contents on the machine the key logger is on then it has nothing to log…

So if you have the keyfile on a USB thumb drive when its pluged in the machine opens an options window which you scroll down with your mouse to open the file menu. Likewise you use the mouse to open a particular file and highlight the text string you want and cut and paste it into another application you have open.

At most the key logger gets the cut and paste key strokes…

Obviously a software key logger actually on the machine could be augmented to log mouse movments but with a little judicious thought you can see ways to make even that data fairly useless.

Oh and for a realy sneaky keyboard use make the program interactive so the user simply scrolls up or down a charecter wheel that is always displayed at a random start position. Or even time dependent, quite a few people can use morse code etc…

Ben • August 1, 2008 8:56 AM

It turns out that the govt. can crack any encryption, including truecrupt.

A Washington post article (http://www.washingtonpost.com/wp-dyn/content/article/2008/08/01/AR2008080103030.html?hpid=topnews) states: **Also, officials may share copies of the laptop’s contents with other agencies and private entities for language translation, data decryption or other reasons…***

Assuming that some laptops use trucrypt, it is reasonable to conclude that truecrypt volumes are routinely being decrypted. Otherwise why send them for decryption? So it would seem that all publicly available encryption technologies are compromised.

Wahnfried von Braun • August 14, 2008 8:19 AM

to Anonymous Idiot and locked out:
let’s face it, that’s one of the big problems with encryption in the real word: if You have got a short , memorable password, it’s going to be cracked fast. If you have a password with reasonable hardness, you are probably going to forget it in the long run, especially if it’s info tat needs to be assessed by You only seldom.
I have yet to find a good 256 bit password for me, but you could use a book code… but than you are vulnerable to dictionary attacks. And all this, excuse me, encryption bllsht will never protect you from trivial hardwarebased attacks against your keyboard.
So in short: WHAT IS YOUR THREAT SCENARIO? The NSA will get Your data anyway, and against anyone else, you can use a good 8byted PW … and that’s it.

Wahnfried von Braun • August 14, 2008 8:27 AM

why is every dot in this forum so hot on thinking about how he can hide his info from a US govt. agency? They’ll get the info anyway, because they have lots of other means. And the same thing holds against the real bad guys.. after they have tortured You guys for a month or two, You’ll crawl on Your broken limbs and beg to offer them Your oh so precious data.

Again, encryption is a nice tool against jerks, if used right. It will NEVER stop somebody who is willing to wade through blood to get it. Again: WHAT IS YOUR THREAT SCENARIO? ((OK: a very good case for encryption might be the taxmen, but in my eyes they fall into the low-level jerk category as well )).

Wahnfried von Braun • August 14, 2008 8:31 AM

make the program interactive so the user simply scrolls up or down a charecter wheel that is always displayed at a random start position.
well, very nice try!! but i own several programs that hack that with no sweat… think screenshots, think ipc.

Wahnfried von Braun • August 14, 2008 8:33 AM

BTW: encryption combined with 2 pounds of C4 might be a very good solution 🙂 if there’s only dust left, you’ll have a hard time reading the info out..

Who? • September 24, 2008 6:36 PM

@Ben, Aug 1st:

PGP is so good that the only way the Feds could break it in a Mob trial was to install keylogging software to get the password.

It was a few years ago now. I’m sure Google remembers.

Al • September 26, 2008 10:26 PM

Does anyone know how many bits of encryption truecrypt uses from a brute force cracker ?

Just because an encryption program eg AES, serpent has 256 bits doesn’t mean you go through 2^256 possibilities! A weak password is enough to crack?

The max pswrd length is 64 characters.
This is 64 x 8= 512 bits. (But not really; how many keyboard characters can you actually use? ).

My question is the key file; how many bits of it are used in the encryption scheme?

I think to be really safe 2 or more (different) encryption programs should be used together.

Clive Robinson • September 27, 2008 6:30 AM

@ AI,

“Does anyone know how many bits of encryption truecrypt uses from a brute force cracker ?”

It’s a question that is almost impossible to answer in a quantative way. However you can make a qualative guestimate…

The reason for this is “assumptions” in three areas,

1, the designers,
2, the users,
3, the attackers.

The reason a “brute force” or “British Library” attack is quoted is that it is a bottom line quantative measurment that is easy to visualise and comprehend, it also has the advantage that it “halts” on a positive result within a known time period.

It can be shown that in general a brute force search is a worse case than a random search. However a truly random search does not “halt” in a known time period.
There is also the issue of short cuts which is based on the properties of metthods used on finite but sparsly populated data sets in an infinate or unbounded set. (which by the way can be used to attack the U.K. Premium bond system to your marginal advantage).

In practice an attacker would never start at 0x0… and work up to 0xf… They would use their own probablistic “speed up” or “short cut” method. That is even after encryption / hashing / compression / whatever a plain text string the result will still show some bias (the hard part for the attacker is reverse engineering the scheme to take advantage of it 😉 The simplest and most obvious of these probablistic methods is a dictionary attack where you test against a precomputed table this is sometimes refered to as a “rainbow table” (thought the definition is somewhat fluid).

The basic assumption made by the attacker is that the language the user used for their pass phrase/word is a language that the attacker has in their table.

Likewise designers are aware of this issue and might well “build in” a different entropy value to “normalise” the users keyboard entry based on frequency on single charecters bi-nims/glyps trinims, quadnims… or other language feature they see fit.

What it boils down to is User Interface efficiency -v- attacker ability.

Users do not like and in most cases cannot reliably type in a string of sufficient length to ensure that the entropy on the lowest level exceeds the entropy of the encryption process in use.

Therefore the interface designers try to squease the maximum entryopy possible out of any given string of text by making assumpptions about what the string is (ie natural languge not stochastic)

The attackers being aware of this human failing and the attendant design assumption look for ways to gain advantage of the “brut force” method and int the majority of cases they succed fairly easily (in the general case dictionary attacks are thousands of times faster and more probable than random or brute force methods).

However a switched on user could likewise come up with an anti short cut method of picking the pass phrase/word that used the design and attack features to actually make the attackers short cuts work against the attacker so that the attacker would have a better chance with just brute forcing or random guessing…

But as noted as you do not know the assumptions used by the designers the attackers or the users you can only give a qualative not quantative answer.

I hope that helps give you a feel for the issues involved.

dave • September 28, 2008 2:01 PM

@Al
“My question is the key file; how many bits of it are used in the encryption scheme?”

That should be easy to discover, in exactly 513 trials. Start with an arbitrary known key. Encrypt something with it. Then toggle 1 bit and encrypt again. If the output changes from the original, then that bit is significant; if it doesn’t change, that bit is ignored. Repeat for each bit.

pots • October 22, 2008 10:10 AM

You need to protect a hidden volume within a truecrypt volume to prevent overwriting. Presumeably whoever coerces you to reveal your password to the truecrypt volume will know this.
Any one who knows how truecrypt works can enable this feature then try to fill the truecrypt volume with data, and this will reveal the presence of a truecrypt hidden volume. Then the toenail removal can begin.

Marco • October 22, 2008 11:06 AM

@pots:
this is not how hidden volumes in Truecrypt work. So “whoever corces you to reveal your password” will know how TrueCrypt works, but you don’t.
The “protect hidden volume” option that you see, is used in order to prevent overtwriting data in your hidden volume when filling the outer volume with data. In order to use this option, you need to have BOTH the passwords to outer volume and hidden volume. Since you won’t reveal the password to hidden volume, your adversary won’t be able to find out wheter you are using a hidden volume in this way.

pots • October 23, 2008 8:08 AM

@marco

Youre right
just tried protection without the second password and keyfiles – the first volume wont mount I take it this is exactly what happens if you try to enable protection and there is no hidden volume.

Also requires there to be nothing in the memory cache as well I think.

anyway thanks for that

Personally I have no need for the hidden volume, My only real concern is actually losing my USB device so I prefer to use keyfiles from divergent sources.

Jochen • November 3, 2008 3:59 AM

Can you tell me how safe TrueCrypt 6.x and / or file encryption is to prevent the gouverment provide access to personal data. My boss believes the e.g. the NSA – USA /BND – Germany/and so on is in a position, to get access. I am not here my keyloggers, e.g.

moeen • January 23, 2010 3:14 PM

i have been using true crypt my self for a long time, BUT THE QUESTION HERE IS HOW SECURE IT IS WITH THE SOURCE CODE AVAILABLE.

Cant a person/hacker modify the sourcecode and skip authentication, I didn’t have the chance to look at it but i am sure you can skip mounting of the file block if it’s just an action on a button.

Any comments regarding this would be appreciated.

PackagedBlue • January 23, 2010 9:08 PM

Security depends upon OS, hardware, and user knowledge.

Truecrypt on windows, why bother?

All cots is trash, government mandated trash cans.

It really is that simple, although I will catch flack on here for putting it that simply.

John • July 15, 2010 9:24 AM

anon asks
“”TrueCrypt Boot Loader” in the very first sector of hard drives that use the full disk encryption feature?”

That would be because you have to load the boot loader up to unencrypt the disk. You don’t have to use that feature if you don’t want it. Make it through your freshman year of CS and you might have a clue.

bill 2 • December 12, 2010 6:42 PM

i am a bit confused re: truecrypt vrs cryptainer …
the newer cryptainer uses @448 bit encryption – is that not necessarily a more secure system?

Bob • December 23, 2010 7:01 PM

The latest Truecrypt appears to not allow the use of alt-xxx key characters in the passcode. I feel that this now restricts the encryption to just 98 bit instead of the 256 bit available if all 256 extended ASCI characters were allowed.
Am I wrong in this?

MarkH • December 24, 2010 12:43 AM

@Bob: Short answer, yes you’re wrong.

“Encryption strength” (really, key length) and passphrase strength (an estimate of how hard it is to guess the passphrase) are two different things. And the number of possible codes for passphrase characters is yet a third thing!

If you select AES-256 in Truecrypt, that is the encryption that will be used, no matter how strong or weak the passphrase.

If you are very concerned about security, the passphrase should have at least 100 bits of estimated entropy (basically, a measure of difficulty to guess), or 128 bits if you hope the ciphertext will remain unreadable long into the future.

If a passphrase can use any 8-bit code (including those alt-xxx characters), then a passphrase of 12 to 16 characters would be very strong if the codes were all chosen completely at random. Such a passphrase would be pretty hard to remember, and a little clumsy to type.

If your character codes are limited to 98 possibilities, then you would need 15 to 20 randomly chosen characters to get to the same level.

You can also get about 100 bits of entropy by making up a sentence or two (totaling about 16 words) of ordinary no-tricks English, or more than 20 words if you are seeking the 128-bit level.

Drew Einhorn • March 24, 2011 11:16 AM

DropBox http://www.dropbox.com runs on
Windows|Mac|Linux|iPhone|iPad|Android|Blackberry

Unencrypted filesystems in the cloud are not cool

Plays well with TrueCrypt with on Windows|Mac|Linux

Encrypted filesystems in the cloud are cool

Unfortunately TrueCrypt only supports Windows|Mac|Linux

Wishing TrueCrypt TrueCrypt ran on smartphones|pads to share encrypted
filesystems among smartphones|pads as well desktops|latops|notebooks…

Trick Danielz • March 31, 2011 11:40 PM

TRUECRYPT – CONTAINER PROBLEM
Hi there, I have a huge problem!! An entire portable hard drive, with very critical data – that I can no longer access, that I used TrueCrypt on….Appreciate any help you might be able to offer. Thank you in advance.

Here is what the error reads:
——————————-
“The container has been compressed at the file system level.TrueCrypt does not support compressed containers (note the compression of encrypted data is ineffective and redundant)

Please disable compression of the container by following these steps.
1) right click the container in windows explorer
2)Select properties
3)In the properties dialog box click advanced
4)in the “advanced attributes” dialog box, disable the option, “compress contents to save disk space” and click ok
5)in the “properties” dialog box click ok
——————————

That is the problem – the issue is when I try and follow these directions – click ok, and then click apply…… it looks like it works but – go back to the file, its still blue in color on the screen meaning its still compressed – i repeat the process and the box refuses to be “unclicked” so i can decompress the files!

Since I can’t decompress the files – I can’t fix the problem. What other options can I try – or ideas do you have. Thanks

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.