TrueCrypt 5.0 Released, Now Encrypts Entire Drive

A funny little man writes "The popular open source privacy tool, TrueCrypt, has just received a major update. The most exciting new feature provides the ability to encrypt an entire drive, prompting the user for a password during boot up; this makes TrueCrypt the perfect tool for non-technical laptop users (the kind who are likely to lose all of that sensitive customer data). The Linux version receives a GUI and independence from the kernel internals, and a Mac version is at last available too."

Comments

Slashdotted

[hsdpa]

The site is sooo slooow. Mirror please! But the update seems great!

Re:Slashdotted

[susub23]

...and now the site is down completely. Sorry TrueCrypt...you just lost my interest.

Re:Slashdotted

[apathy maybe]

Actually, I've been having trouble accessing the site all day.

I've been looking forward to the Linux GUI since I read about it, checking back, checking back etc.

Then today, suddenly the entire site is virtually inaccessible.

On the actual release, I think it is going to be good. After all, we see a new MacOS version, a Linux GUI and a few other nice little tools which most people might not even notice.

On the actual software, I love TrueCrypt, I use it both in Windows (where it, simply, is so easy to use), and in Linux (command-line, mehs all around, plus you have to go and delete history if you don't want to save the fact that your using it (or perhaps the fact that a specific file/partition is a container)).

The hidden-partition feature is the bees knees, especially for those extra secret documents, just hide them behind some porn, financial data or something else which you access and make changes to regularly (to hide if you are making changes to the hidden volume).

The ability to back-up headers makes this software great for businesses or governments (can restore a password if a user loses it), and this new encrypt the entire system thing, simply swell (though it doesn't work on Linux/MacOS I don't think).

Anyway, as always, check out the Wikipedia article for more info. http://en.wikipedia.org/wiki/TrueCrypt

Re:Slashdotted

[telchine]

The site is sooo slooow. Mirror please! But the update seems great! http://sourceforge.net/projects/truecrypt/

Re:Slashdotted

[hsdpa]

Actually, I've been having trouble accessing the site all day.
That sounds like DDoS in my ears: New revamped version with nice features => site goes mysteriously down and is partially accessable with response times at over 10 seconds.

Re:Slashdotted

[RandoX]

IMPORTANT--Official_TrueCrypt_distribution_packages_can_be_downloaded_only_from_www.truecrypt.org

Re:Slashdotted

[somersault]

I thought that was called the 'Slashdot effect', or the fact that a lot of people have been waiting for the new version and now are downloading it and sucking up all the bandwidth.

Re:Slashdotted

[FutureDomain]

You must be new here.
Slashdot effect

Re:Slashdotted

[InvisiBill]

FYI, http://www.truecrypt.org/downloads.php links to http://truecrypt.sourceforge.net/downloads/TrueCrypt%20Setup%205.0.exe.

Re:Slashdotted

[BobPaul]

TrueCrypt is an OSS project hosted by Sourceforge. All of their CVS and release files are stored on SourceForge.

Re:Slashdotted

[AngusSF]

True, but if you choose a download from that "official" page you get sent back to sourceforge for the actual package. Here are some links:

http://truecrypt.sourceforge.net/downloads/

Ubuntu/Debian: http://truecrypt.sourceforge.net/downloads/truecrypt-5.0-ubuntu-x86.tar.gz

Windows: http://truecrypt.sourceforge.net/downloads/TrueCrypt%20Setup%205.0.exe

Re:Slashdotted

[macdaddy]

he hidden-partition feature is the bees knees, especially for those extra secret documents, just hide them behind some porn, financial data or something else which you access and make changes to regularly (to hide if you are making changes to the hidden volume).

I could be mistaken here but I could have sworn that the install docs/HOWTO unequivocally said to never ever ever write data to the dummy volume once you've started using the real hidden volume. Something about overwriting blocks of the hidden volume because TC and the dummy volume has no idea where the dummy volume ends and the real hidden volume begins. It's been a while since I read the docs when I implemented this on my new laptop (2 weeks back) but I was pretty sure that's what they said.

Re:Slashdotted

[SScorpio]

You're able to write protect the hidden area and write to the dummy partition. The only bad thing that it reports is that data written to the hidden partition area will appear as a write error. So you can technically have updated files in the dummy area.

Re:Slashdotted

[Anonymous Coward]

The ability to back-up headers makes this software great for businesses or governments

I think a small business or home based business where everyone is on board that WDE is a good thing could get away with using Truecrypt's WDE feature. Unfortionatly it is not ready for any government agency, nor any business of significant size. Several problems exists:

• Anybody with admin rights to the machine can remove the FDE (And even though the FDCC guidelines (Which all government agencies are supposed to follow and implement as of Jan 31, 2008 (yea right)) say this is a no-no, all it takes is someone, somewhere to sign off saying "We allow local admin rights because: " and viola! Admin rights.
• No support for two factor authentication.
• No support for the "I forgot my password" syndrome beyond saying: Here is a rescue CD, and here is the password, and have fun! Commercial products allow for a challenge-response one time login/password change request.
• No support for multiple users to log in to the laptop (Ties into the point above).
• No support for policies (Password length/complexity, time restrictions, that sort of thing)
• No support for automatic updates (which I guess is a moot point because of the above issue)
• No support for automatically updating the header files (Needed when the user changes password, a new user is given rights to the machine, etc.)
• And the biggest one: Truecrypt would need to have a champion at the highest levels before it has a chance of being deployed.

Some of these problems also prevent Truecrypt from being used as a portable media encryption option in the government as well. For example there is no easy way that a end user can create a container and say "Only myself and Bob can open it".

In short, it is close to being useful beyond the SOHO market, but not quite there. Reading through there todo's I see that they are going to be addressing some of these issues, and I suspect that with enough constructive input, they will eventually meet the other requirements as well.

Re:Slashdotted

[networkBoy]

Specifically when mounting a "dummy" partition you can also hand TC the key to the hidden volume to allow it to know where the hidden data starts at.
-nB

Re:Slashdotted

[Knara]

hsdpa's comment made me cry a little inside

(weeping for the chil'en!)

Re:Slashdotted

[macdaddy]

This isn't the page I was looking for but it does elude to the problem:

Protection of Hidden Volumes Against Damage

So basically you have to provide both the key for the outer volume and the key for the hidden volume to prevent damage to the hidden volume. Essentially it is trivially easy to damage the hidden volume. That's not the page I was looking for but it essentially talks about the same thing. I wasn't aware of the 2nd-key trick to prevent damage though. That helps but I can easily see that being forgotten; I'm sure I'd forget it if I used the hidden partition.

Re:Slashdotted

[hsdpa]

I think that you and your parent misunderstood me. My first comment in this thread/tree was

Slashdotted: The site is sooo slooow. Mirror please! Then I replied to someone claming

Actually, I've been having trouble accessing the site all day. So that's why I mentioned DDoS.

Re:Slashdotted

[TemporalBeing]

I work somewhere that uses the commercial EPHD product (I think this is it). I believe the systems actually got less secure after installing EPHD.

• To start, the Single Sign-on allows entry of username/password at boot, and then by-passes the Windows login. Even if you time-out at the Windows login, it will usually just let you in.
• If you fail to provide the correct password after 3 to 5 times, it prompts to call the help desk for a special code. However, if you simply turn off the computer and turn it back on, you can try again. Repeat until you get it right.
• You cannot have multiple people/users recognized for the login. Only one user can login to EPHD. So, people (even managers) started creating dummy users for systems and told others how to generate the password for the users so that more than one person could login. Keep in mind password sharing is forbidden by policy.

We also had a 50% success rate with installation because it kept corrupting the master FAT table. Kept the techs busy for a few weeks as they tried to sort it all out. They had to rebuild my system 2 or 3 times before it took.

There's good ways to manage it - BitArmor seems to have a good method; though I've not actually used it myself yet.

Not sure how TrueCrypt compares to either, but it can't be any worse - likely its better.

Re:Slashdotted

[Anonymous Coward]

and in Linux (command-line, mehs all around, plus you have to go and delete history if you don't want to save the fact that your using it (or perhaps the fact that a specific file/partition is a container)).

Assuming you're using bash, try 'man bash' and grep for HISTCONTROL.

Re:Slashdotted

[Anonymous Coward]

I work somewhere that uses the commercial EPHD product (I think this is it). I believe the systems actually got less secure after installing EPHD.

• To start, the Single Sign-on allows entry of username/password at boot, and then by-passes the Windows login. Even if you time-out at the Windows login, it will usually just let you in.

But how often does a user boot the computer, put in their password, and then just walk away? And more to the point, how is this less secure then booting into Windows, putting in a password and then walking away till the desktop comes up? At some point you need to trust your users enough to follow simple directions. (I admit that is part of the problem where I work, Management thinks that they hired idiots that can't follow directions. Said idiots are making $50,000-$150,000/yr working with hazardous materials, I think that they can follow simple directions.)

• If you fail to provide the correct password after 3 to 5 times, it prompts to call the help desk for a special code. However, if you simply turn off the computer and turn it back on, you can try again. Repeat until you get it right.

I'm not familiar with the product you mentioned, but my guess is that there is a policy setting that can be set up by the admin to prevent this type of behavior (IE: 15 minute lockout after 5 incorrect attempts) I know that they product that we are using (pointsec, now checkpoint does. If it doesn't it is an defective product, and if it does, then the people in charge of security at your company didn't think this through (or it was decided against for other reasons. (For example they may have 32 character minimum password requirement and they thought that would be enough of a deterrent for a brute-force attack))

• You cannot have multiple people/users recognized for the login. Only one user can login to EPHD. So, people (even managers) started creating dummy users for systems and told others how to generate the password for the users so that more than one person could login. Keep in mind password sharing is forbidden by policy.

This is a big defect. But perhaps the functionality is there, and it hasn't been implemented. (See above for polices not being enforced, or see below for my point on companies investing in this technology.)

We also had a 50% success rate with installation because it kept corrupting the master FAT table. Kept the techs busy for a few weeks as they tried to sort it all out. They had to rebuild my system 2 or 3 times before it took.

With Pointsec, our success rate is 95%+ We found out in testing that certain (Windows) patches needed to be installed before it would work reliably. Before that it was fairly hit or miss as to whether it would work or not. (It's only that low because I can think of one time where a hard drive died, and a couple of others that had so much crap installed that Pointsec refused to install correctly and a re-image of the laptop fixed those issues) The product that your company is using my have had similar quirks that had not been discovered by the time that your machine was worked on.

Which brings up a good point: Companies invest in the technology blindly. Management imposes unrealistic deadlines, or they impose unrealistic dollar constraints, or they burden people who are overworked, and fail to budget for training, or allot time for testing, or even asking end users for their input. This almost guarantees that someone (usually with clout) will be upset, the deployment will go badly (50% success rate? 3 tries to get it right on one machine? Defiantly a botched deployment, probably because of lack of training/testing) or the project fails completely and gets scrapped.

There's good ways to manage it - BitArmor seems to hav

Re:Slashdotted

[mdwh2]

The hidden-partition feature is the bees knees, especially for those extra secret documents, just hide them behind some porn

Hey, in some backward prudish over-censoring countries like the UK, we have to hide our porn behind extra secret documents!

Re:Slashdotted

[xSauronx]

you can already encrypt an entire disk with linux, i started doing it months ago. debian, and the ubuntu alternate installer allow this to be done pretty easily for those with a little installation experience. i cant speak for other distros as these are the only two im using at present.

Re:Slashdotted

[jdbear]

If you KNOW that you are using a hidden volume, then you know that writing data to the outer volume (the false front, so to speak) requires a bit of special care. Don't use the outer volume as a real place for often changing data. It's a smoke-screen, a place to put stuff so the cops ^H^H^H^H interested other parties will not be able to prove you have anything else to hide. "See officer ^H^H^H^H^H^H^H interested other party, all I was hiding in my encrypted volume was my taxes and pictures of Britney Spears!"

Re:Slashdotted

[jdbear]

While I've read through your list of problems and agree that most of them would keep it from being deployed by Government, I've got to ask, "who gives a shit?" Do I care if the Govnernment is using the product I use to keep myself safe from them? No, I don't.

Also, while support from external authentication devices would be nice, there is support for keyfiles as well as passwords, so technically this is a two-factor authentication system. Since the system will not boot at all with System Encryption enabled without the password entered, Automatic update for user password changes (for when a NEW USER is given access to the system) is meaningless. When the user changes the encryption password on the system, it's changed. No automatic update needed. It's true that if the current user leaves without providing the password he is using, the hard drive is inaccessible, and therefore useless to anyone else, us but isn't that the point?

My company uses PointSec for WDE for our systems. It seems to work well, and yet I understand that nothing I put on the system is private. My PC admin has the ability to log in at any point and rifle through my files. If someone in our home office decides to reset my password through Active Directory, there's nothing I can do about it. I'll be locked out and not able to even view my files or get a chance to delete any private data I may have on the machine. I use a TC volume to keep my private files private. The hard drive is encrypted, so if the laptop is stolen, no one can yank the drive and steal corp data, but on the other hand, if someone want's to see what I've got in the box, all they'll find is an encrypted file. The TC is for ME, not for my Government or my employer.

Re:Slashdotted

[jdbear]

One of the advantages of Truecrypt is the ability to encrypt external drives. I have several drives that I use to transport media (audio, movies, ebooks, etc.) when I travel. If one gets stolen, it will appear to be empty, or corrupted. If it gets comfiscated by the copyright police, it will appear to be random data. Using TC, I can mount these drives on my Linux box at home, my Windows box at work, or connect it to my wife's Mac to transfer files. All I need is the portable version of TC on a USB key, and I'm golden.

Re:Slashdotted

[Selivanow]

There is a way, at least on Windows, to "protect" the hidden volume while writing data to the outer volume. The hidden volume must be unmounted at the time, IIRC.

Re:Slashdotted

[Anonymous Coward]

My company uses PointSec for WDE for our systems. It seems to work well, and yet I understand that nothing I put on the system is private. My PC admin has the ability to log in at any point and rifle through my files...

Why is this a problem? They are, in fact, the companies files, not yours. You want private files? Get your own laptop, put TC on that and be safe and secure. Because even with TC on the companies laptop, you're still pretty much screwed if they really want the data. Want to see how easily screwed? Mount your TC volume. Have your admin browse to your computer. Watch him copy the files from your mounted TC volume. Group Policies turn off PC file sharing/network browsing? A special policy is made just for you. A filemon type app will also get you the name of the file that is your truecrypt container, which can then be copied off your drive. A keylogger will get the passphrase and the same filemon type utility can get the names of the keyfiles that you use. A clever one would even make a copy of the files in case they were on removable media.

The point is: Don't be so sure your sticking it to the man by using TC on a corporate computer, because you might not be as smart as you think you are.

Now, having said that, I've never worked at a place that would go through that much effort to find out what you had squirreled away. If TC was even found, the worst that would happen would be delete the container file, and delete TC and you'd be told don't do it again, or we'll slap both wrists next time.

Re:Slashdotted

[xSauronx]

oh, i know, ive been using TC in a similar capacity for well over a year. encryption is handy stuff :)

Re:Slashdotted

[Anonymous Coward]

I welcome the improvements in version 5. Even the additional speed for the Windows version should be nice, though it has never seemed slow to me.

I've been looking forward to the Linux GUI version, too, and hoped to try it today, but it seems I'm out of luck. Truecrypt supplies packages for Ubuntu and OpenSuSE. I use CentOS to match my CentOS and RHEL servers, and because I generally prefer RH to SuSE. The OpenSuSE rpm depends on libfuse2, which is not available as of CentOS5.1 even from third party packagers.

My attempts to download the sources for Truecrypt have been unsuccessfully redirected to an unrelated page on their site.
I've been a user and huge fan of Truecrypt on my XP laptop since v4.1, and am eager to have cross-platform encryption since I prefer Linux and work in it most of the time. So far, no luck. Anyone else managed to try it?

Re:Slashdotted

[Anonymous Coward]

The hidden-partition feature is the bees knees, especially for those extra secret documents, just hide them behind some porn, ... ... which you access and make changes to regularly (to hide if you are making changes to the hidden volume).

You edit your porn? Whyever would you do that?

Re:Slashdotted

[jdbear]

You asked "Why is this a problem?" I did not pose it as a problem, merely shared my experience for information. If you think what I do is irrelevent, ignore it. I read opinions and ancedotes related by others all the time, and sometimes even find many of them interesting.

On your other points, yes, it is possible that an admin could disguise a key-logger on my company laptop to steal my truecrypt password, and therefore gain access to that data. It is a violation of our corporate security policy, but it could be done. I don't expect them to go to that length to spy on me, however.

I keep a TC volume on my corp laptop because I occasionally want to access non-corporate, privately owned files without having to carry a second laptop with me. My company allows "limited private use" of corp computer equipment, email, and Internet access, so there should be no hand-slapping involved. I want to keep my private files private, because they are no one else's business but mine.

In the event that I have a malfunction on the computer, or I get to upgrade, or I decide to leave the company, or any of a dozen reasons that I lose physical control of the laptop, the TC volume will ensure that my files stay private. I'm not being paranoid, nor is there anything shocking or illegal in the private space that I would have to worry about, but it's still a better policy to keep the files locked away.

There are things in the TC volume that I find funny, or interesting, that my fellow employees may not. Off-color jokes, or cartoons, downloaded discussions of non-work-related political causes, my tax information or IRA contributions, etc. It's just best to have these things kept private, even from my fellow employees. The PointSec encryption on the laptop as a whole does this for the majority of situations, the TC volume takes care of the rest.

If someone were to truly dedicate themselves to finding out my every last secret, I'm sure they could do it. They could install a key-logger on my system, a camera in the ceiling tiles above my desk, put bugs in the furnishings around me, use TEMPEST techniques to capture the output of my monitor, etc. If they want to know that badly, all they would have to do is ask (they might have to say please, and give me a decent reason they want to know.) I'm not THAT secretive, and what I am hiding is not that important.

Still, it's fun to use an encryption system to lock away my "naughty secrets." When it comes time to turn in the laptop, all I have to do is to erase the private.tc file from my home directory, and know that the data is gone. Even an unerase utility will not retrieve the files. It's possible that fragments of the files were swapped out to disk by the Windows swap utility, but like I said, there's nothing there THAT damaging that I'm worried about it.

Re:Slashdotted?

[b100dian]

..redditted!

Thanks a lot

[Teran9]

There goes any chance of downloading version 5.0 today.

Independence from Kernel Internals?

[gweihir]

I do not think that is feasible for what is essentially part of a disk-driver. Marketing-lies now on Linux versions as well? Linux must be going mainstream...

Re:Independence from Kernel Internals?

[FudRucker]

yup, i agree, i knew this would happen as Linux gains market share and popularity...

Re:Independence from Kernel Internals?

[Chris Mattern]

It is also, of course, impossible that it encrypts the *entire* disk. It may encrypt all the partitions your running system uses, but unless your BIOS has encryption support (which it doesn't), you can't have an encrypted boot partition.

Re:Independence from Kernel Internals?

[hilather]

Thats a very good point. If the site wasnt slashdotted I'd be reading it right now trying to figure that out myself. The boot sector seems like the area that would need the encryption, otherwise the part of the program that is doing the key negotiation would be exposed. I'll be honest, I've heard of truecrypt but never been interested in it. What kind of security could this provide? I would like to encrypt my entire laptop drive, but I'm not going through all the trouble if its just another easy layer to break through. Any Truecrypt experts out there?

Re:Independence from Kernel Internals?

[Bandman]

Assuming the password isn't stored plaintext in the boot partition, isn't an encrypted data partition the important part?

Re:Independence from Kernel Internals?

[Chris Mattern]

Yes. Having an unencrypted boot partition isn't much of a vulnerability if you did your encryption right. That doesn't change the fact that saying you've encrypted "the entire disk" is a marketing lie.

Re:Independence from Kernel Internals?

[Anonymous Coward]

At what point did anyone state that the "entire disk" that is being encrypted is also your boot disk?

Your boot disk could be a small USB stick that you plug into the computer so that it can decrypt your main disk.

Re:Independence from Kernel Internals?

[Ed Avis]

You could boot from a floppy or a CD and mount the whole disk (/dev/sda) as your root filesystem. Dunno if TrueCrypt supports this out of the box.

Re:Independence from Kernel Internals?

[Chris Mattern]

Yes, they can recover key and encryption algorithms from the unencrypted boot sector. But if they can crack you simply by knowing the unencryption program, you're boned anyways. What they *can't* recover, assuming that your encryption vendor hasn't screwed up, is your key. And without that, they can't read your encrypted partitions. If they've done it right, it's secure. Somebody in possession of your laptop but without your passphrase cannot read the disk, no matter what he does, except for the boot partition, and there won't be any useful data there. I don't use Truecrypt and haven't researched them, so I can't guarantee that they did it right (look at WEP, where they managed to botch the encryption for a major standard, resulting in it having to be replaced by WPA). I believe every laptop should be "whole disk" encrypted--it's just too easy for a laptop to disappear. I run debian on my laptop, so I used cryptmount to encrypt my disk. If you're not encrypting your laptop's disk, you definitely should be. A brief glance over some recent news stories should tell you why.

Re:Independence from Kernel Internals?

[Maljin Jolt]

It is also, of course, impossible that it encrypts the *entire* disk. It may encrypt all the partitions your running system uses, but unless your BIOS has encryption support (which it doesn't), you can't have an encrypted boot partition.

Your concept of impossible is, of course, a little bit flawed, for I have at least 5 *entire* disks encrypted in this single box I am writing on. And some of them has no partitions, just a filesystem over raw disk.

Re:Independence from Kernel Internals?

[filbranden]

Hi, I read the site yesterday (from Firehose), and I think I can say one thing or two.

TrueCrypt does a good job of encryption, it's not a trivial level. It uses strong algorithms, and you can choose from 5 or 6 different algorithms. It doesn't store your password anywhere in the disk, when you type the password, it tries to decrypt the header, and if it makes sense (I guess if checksums match) then it knows it's the right password and it goes on, otherwise not. It uses basically the XEX (almost sure that's the name... I don't really know what it is, this is what I remember from the site) schema, but XEX uses only one key for two purposes, and TrueCrypt uses two different keys for these two purposes.

The whole-disk encryption (the correct term is partition encryption) seems to work well, at least from the documentation, I didn't try it (yet). It includes a boot sector that does the part of asking the password during boot and decrypting the partition. The boot sector is obviously encrypted, and I suppose it also stores some unencrypted data to implement the boot code (I don't believe it can be done in 512 bytes only), but after you boot the OS, everything it sees is encrypted, so it will protect even temporary files or logs created by the OS on that drive. Even if it doesn't encrypt 100% of the data (boot sector, boot code), it encrypts everything that you should encrypt. What it doesn't encrypt is not secret in any way.

I tried previous versions and I liked it, it is really a great product, and if 5.0 does everything they say it does, I guess it's really worth it. Whole-disk encryption is no longer missing from this excellent software, many businesses need it for laptops (just see how many information theft happened last year due to lost laptops). I believe TrueCrypt is going mainstream now.

Re:Independence from Kernel Internals?

[CarpetShark]

unless your BIOS has encryption support (which it doesn't), you can't have an encrypted boot partition.

Of course you can. You just can't have an encrypted MBR... unless you boot from a floppy or a USB drive you keep on your person, or something like that. Note that bios limitations can also be circumvented with linuxbios ;)

Re:Independence from Kernel Internals?

[gweihir]

I would like to encrypt my entire laptop drive, but I'm not going through all the trouble if its just another easy layer to break through. Any Truecrypt experts out there?

I am not a TrueCrypt expert, but I follow the discoveries of the crypto community. It seems TrueCrypt is highly respected. While it cannot defeat a (hardare in this case) keylogger, the crypto used seems to be strong crypto implemented according to current standards. Not a snake-oil product with home-rolled ciphers or "passwordless" security or such nonsense. At the moment, nobody admits being able to breaking it and I am not aware of instances that indicate it has been broken. And, other than many other products, it is widely used. Personally I would say it is on a level with PGP/GnuPG/dm-crypt/LUKS with regard to security level offered.

Re:Independence from Kernel Internals?

[gweihir]

Assuming the password isn't stored plaintext in the boot partition, isn't an encrypted data partition the important part?

True. I am not criticizing the technology. I think it is sound. I am criticizing the marketing statement.

Re:Independence from Kernel Internals?

[AmiMoJo]

That isn't entirely accurate. You can encrypt the boot partition, just not the boot record part which contains executable code. The code is driver for Truecrypt volumes that allows Windows to access them for booting the OS. All the files on the boot partition are encrypted, and the key is not stored anywhere.

Re:Independence from Kernel Internals?

[Anonymous Coward]

No, you are wrong. It can encrypt all of the partitions, system drive included. I haven't actually used TrueCrypt 5, but having read their blurb I am 100% certain that they replace the boot-loader. Their code will prompt for a password before the system starts loading, patch the BIOS functions with custom encryption-aware code and perform on-the-fly encryption for ALL disk operations. That means the boot drive can be encrypted.

This is quite straight forward in theory, but really, really difficult in practice (not least of all because you only have 500 or so bytes of code to play with in the boot-block). If they've pulled it off, and this works, it is a massive thing - enterprise software to do this kind of work costs hundreds of dollars per user.

Independence from kernel internals means that TrueCrypt hopefully won't break every time the Kernel is patched, which I believe has been a problem in the past. I guess they have created some kind of bare-bones ABI in the kernel source that can be re-compiled without needing to recompile TrueCrypt. Now stop being dumb-asses!

Re:Independence from Kernel Internals?

[filbranden]

Oh, I forgot to mention. According to their website, TrueCrypt can encrypt the boot partition even after the OS is installed, even with Windows.

Basically, you install it, then you ask it to encrypt the whole disk. It will install the boot code to ask the password and decrypt the partition before loading the OS, and then it will start encrypting your partition in the background, you may continue using the OS. You may even reboot the machine, it will boot correctly and continue encrypting from where it stopped. If it really works as they say it does, this version is indeed amazing.

Re:Independence from Kernel Internals?

[Anonymous Coward]

You do realize that it will encrypt entire disks without boot partitions, don't you? In which case, their statement is entirely true.

Re:Independence from Kernel Internals?

[cryptoguy]

Previous versions for Linux required a kernel module. When they say 5.0 has "independence from the kernel internals", does that mean there no longer is a kernel module? Or that the kernel module is somehow portable across kernels??

And, does this mean you can mount a Truecrypt volume from the traveler mode as a guest on a system without having root or admin privileges?

Re:Independence from Kernel Internals?

[Nimey]

If the Mac version is any example, TrueCrypt now uses FUSE. That's not /completely/ independent of the kernel, but it's still rather more stable than having to recompile TC every time you build a new kernel.

Re:Independence from Kernel Internals?

[Trevelyan]

Only volume (file) encryption is supported on Linux.
Not full system encryption, that is only available for MS Windows.

Re:Independence from Kernel Internals?

[geminidomino]

Doesn't FUSE provide that sort of interface?

Re:Independence from Kernel Internals?

[Anonymous Coward]

I believe every laptop should be "whole disk" encrypted--it's just too easy for a laptop to disappear.

/home and swap make a lot of sense. Maybe /var. But /usr? What's the threat? ("Oh no, someone stole my laptop and now they have my version of /usr/bin/ls!")

"Whole disk" encryption is probably the best lazy default (e.g. all Dells should ship that way) but I wouldn't say it's the best for "every laptop."

Re:Independence from Kernel Internals?

[Anonymous Coward]

What it doesn't encrypt is not secret in any way.

So you wouldn't be upset if that information were made public? (Point: Be very careful how you use the phrase "not secret".)

Re:Independence from Kernel Internals?

[viper66]

Whole disk encryption is meant to avoid the possibility that an application (possibly without your knowledge) could write sensitive data to a location that is not encrypted.

Re:Independence from Kernel Internals?

[Skapare]

If it runs while loading the OS (kernel), and then runs when that OS mounts a filesystem, it must be running in two different places since in one case the I/O is done through BIOS calls and in the other case through device driver calls in a kernel. That doesn't sound like independence from the kernel to me. It sounds like it has to be compiled into the kernel (otherwise the / filesystem isn't encrypted), or at least inside initramfs (which is still compiled into the kernel).

I'm really not concerned about the install process. I'm concerned about reliability aspects, including the ability to support the way I structure my file systems. Performance would be good, too, but there is obviously a certain amount of performance hit for the encryption. For example, things like direct write should still continue to work faster, by doing the encryption of data blocks directly from the original buffer to a temporary (not copy to a temporary first), then completing the write.

Re:Independence from Kernel Internals?

[Dan541]

Problem I have is that I dont shut my notebook down I just put it to sleep at night and for transport.

During the day I just lock by WindowsKey + L

Im not sure how good the windows lock is but if its good enuth that someone would have to reboot to get around it then the disk should become encrypted as soon as the system loses power for the reboot.

~Dan

Re:Independence from Kernel Internals?

[rdradar]

Only the Windows version supports whole disk encryption, not Linux one.

Re:Independence from Kernel Internals?

[mattpalmer1086]

The disk is always encrypted. It's decrypted on the fly, transparently to the O/S, when running. You're right that leaving it in sleep mode is a bit more vulnerable than leaving it powered off - if people can get around your windows lock without powering off, game over.

Re:Independence from Kernel Internals?

[russ1337]

Im not sure how good the windows lock is but if its good enuth that someone would have to reboot to get around it then the disk should become encrypted as soon as the system loses power for the reboot.

The disk is encrypted the whole time - truecrypt decrypts what it needs on-the-fly in RAM. Its not so much about "How good the Windows lock is", but "how guessable your password is". Even if an attacker stole your notebook and plugged it in to wake it up from 'sleep', then they should be faced with the standard windows login. If you've got a strong password, then they'll be there forever. There is no way I now of that would allow them to launch an automated attack either.

If they wanted to get data off your machine, and are faced with the standard windows login if stolen while it was asleep, they probably wouldn't know it's hard drive is encrypted. The best way for them to try to get your data is to power down the machine and reboot into a live CD, or pull the drive and put it in another machine. Once they've done that, they'll discover the disk is encrypted. While they can now launch automated Brute Force attacks, it is the strength of your password (and the strength of the encryption algorithm) keeping them out.

A good place to learn more about encryption is the "Security Now" podcast at www.GRC.com/security now (also free through iTunes). Look back at the old truecrypt episode, as well as those with Crypto in the title etc...

Re:Independence from Kernel Internals?

[BalanceOfJudgement]

True. I am not criticizing the technology. I think it is sound. I am criticizing the marketing statement.

Fair enough.

I think the alternative though - something along the lines of "TrueCrypt offers NEAR full disc encryption" is far more confusing and would do a far greater disservice to those non-technical people attempting to use it.

Re:Independence from Kernel Internals?

[Marsell]

Just a nitpick:

Yes, they can recover key and encryption algorithms from the unencrypted boot sector.

In TrueCrypt's case, they can't.

Here's what they know, since you're using TrueCrypt: you're using at least one of several supported algorithms for encryption, there are three possible hash algorithms used in key strengthening (and the number of iterations), and they can find the salt used in the key strengthening at the beginning of the volume.

That's all. You need a key -- derived from the password -- in order for TrueCrypt to make an attempt to determine which algorithms you're actually using. They don't know which hash algorithm you used for strengthening and they don't know the algorithms (you can chain several) you used to encrypt the volume header. Add a salt to prevent Rainbow attacks and this becomes very computationally expensive even for short passwords.

This is a nice article about it: http://blog.bjrn.se/2008/01/truecrypt-explained.html

Re:Independence from Kernel Internals?

[Anonymous Coward]

Yes, they can recover key and encryption algorithms from the unencrypted boot sector Not true at all, you obviously do not know anything about how TrueCrypt works.

Re:Independence from Kernel Internals?

[kyofunikushimi]

Even if an attacker stole your notebook and plugged it in to wake it up from 'sleep', then they should be faced with the standard windows login. If you've got a strong password, then they'll be there forever

Assuming all of the other accounts on that machine also have strong passwords and there aren't any unpatched-and-exploitable services running.

Re:Independence from Kernel Internals?

[kyofunikushimi]

There are dozens of encryption software packages out there touting 'whole', 'full', and 'entire' disk encryption. They ALL require BIOS support. If TrueCrypt will encrypt the MBR on machines with the necessary support, they can certainly tout that feature. If they don't, well... then I agree. But I haven't seen anybody in here say one way or another that they or they don't support MBR encryption.

Re:Independence from Kernel Internals?

[skeeto]

unless your BIOS has encryption support (which it doesn't), you can't have an encrypted boot partition. [...] Note that bios limitations can also be circumvented with linuxbios ;)

Of course, then your BIOS isn't encrypted, so you encrypt it and need another one below that to decrypt it, but then that bottom one isn't encrypted.

It's encrypted boot code all the way down!

Re:Independence from Kernel Internals?

[russ1337]

Assuming all of the other accounts on that machine also have strong passwords and there aren't any unpatched-and-exploitable services running.

Other accounts true,

Also, good point about services running. That'd probably be the easiest way in - plug into a router and see what shares are available, then start attacking services via a network vector - so many options!!!. I never thought of that.

Re:Independence from Kernel Internals?

[proselyte_heretic]

Not even with windows, only with wondows, it doesn't work with mac/linux.

Re:Independence from Kernel Internals?

[cortana]

So did you configure your BIOS to decrypt the MBR on the boot disk? Or are you using a decent architecture where such things are commonplace?

Re:Independence from Kernel Internals?

[cortana]

Someone with access to /usr could replace /usr/bin/firefox with a script that tars up /home, mails it to themselves, and then runs firefox.

Re:Independence from Kernel Internals?

[jdbear]

The term that is used on the Truecrypt website is "System Encryption" and it works by loading an encryption program into the boot block of the boot disk. The MBR will call the boot block, which then prompts for a password. The password is used to attempt to decrypt the rest of the boot partition. If it fails, there is no boot, and the only data that is unencrypted on the disk is the boot program itself. The rest of the disk looks like random data. If that's not "whole disk" encryption because the MBR is not itself encrypted, then what is the advantage of encrypting the MBR?

Re:Independence from Kernel Internals?

[jdbear]

so far

Re:Independence from Kernel Internals?

[kyofunikushimi]

Um, I suppose if the MBR is not encrypted, your would-be crypto-cracker could get frustrated and just write junk all over your MBR. That could be annoying. I suppose there is some sort of security in your partition table being encrypted, but I'm not smart enough to figure out what that security is.

Re:Independence from Kernel Internals?

[petermgreen]

on the other hand if they DO know (or at least stronly suspect) it is encrypted and they have the right rescources then there are techniques they can use. The key will be in ram somewhere so if they can copy the ram then they have a much easier path to cracking the encryption than guessing keys at random.

One common hole is that many firewire chipsets allow DMA to all main memory over the firewire bus. So you can plug a firewire device in and DMA out a complete image of the devices memory.

also many laptops have an exposed PCI or PCI express bus in the form of a minipci or cardbus or expesscard or similar slot. Again with many chipsets this will have direct DMA access to all of main memory.

also dram doesn't lose it's content entirely as quickly as you might think, apparently there is enough time to take the modules out, put them in a reader and get back the data albiet with some errors.

Re:Independence from Kernel Internals?

[mrv20]

That would certainly explain firefox's load time :b

Re:Independence from Kernel Internals?

[Anonymous Coward]

/usr/local...there is often a /usr/local/etc dir for example

Re:Independence from Kernel Internals?

[Lincolnshire Poacher]

> there is often a /usr/local/etc dir for example

System partitions should be mounted read-only in normal
operations.

If you're mounting /usr, /bin and /usr/local writable then
you've got bigger problems than needing encryption.

For example, someone pulls the power lead. If your system
partitions are mounted writable, you risk corruption.

So /var, /tmp and /home are the only partitions that should
be mounted writable at boot.

Re:Independence from Kernel Internals?

[CarpetShark]

Indeed. However, when I first got involved in this whole-disk encryption debate, I should have clearly said that there's no need -- only your personal data and config needs to be encrypted. There's no point in encrypting something that can be downloaded publically. In fact, it probably poses a security risk, since that gives a plaintext copy to try matching the encrypted data to.

Re:Independence from Kernel Internals?

[russ1337]

Wow, thanks that is good info. Wasn't aware of those vectors until now, I guess I should have thought a bit harder. Interesting about the firewire too.

For some reason, the thought of keeping a laptop powered while transporting it reminds me of that Seinfeld episode where George is trying to keep the arcade machine powered... (not that the latter had a battery)..

Re:Independence from Kernel Internals?

[jhfry]

The one weakness that people seem to ignore with all full disk encryption schemes is the hacked bootloader.

For example, I create a utility that installs a replacement bootloader onto your machine's UNENCRYPTED boot partition. It looks the same, so you enter your password... my code than passes the typed code and saves your password so I can later log into your system.

HOWEVER, people who point out that weakness also forget that full disk encryption's primary purpose is to prevent loss of important business and private data when a laptop is stolen, not to prevent an intentional theft. Which is why my organization (DHS) requires WinMagic on all of their laptops... at least that way they can be fairly certain that the user who has their laptop stolen didn't just divulge a few million records of personal information.

A true full disk encryption to prevent an intentional theft of data should:

A. place the boot loader on a separate read-only device (USB key type device), rendering the system's disk unusable without the seperate hardware device.
B. use biometric or token based authentication to prevent interception of entered key's

Even then, it's still only as secure as the system is once the user has authenticated. I think that the funniest thing I ever heard was the guy who backed up his encrypted system to a DVD before every trip... then carried the DVD with him just in case something happened while he was on the road and he couldn't access the data he needed. What he didn't do is take the time to ensure that his backup was encrypted... many users think that once the data is encrypted it stays that way, even when it's copied off the device.

Re:Independence from Kernel Internals?

[jdbear]

Yep, that would work.

Re:Independence from Kernel Internals?

[jdbear]

By saying that he has FIVE disks that are entirely encrypted, he gave you a clue that they were not all bootable disks. Why would one worry about putting an MBR on a non-bootable disk? If there's no MBR on the disk, why would one worry about whether it is encrypted or not?

Why is everyone so hung up on encrypting a boot record, anyway? The purpose of encrypting these disks is that one cannot take a disk away and gain access to the data. If someone had physical access to a system, where they could alter the system then put it back in place for the owner unsuspecting owner to use again, the encryption system used is not the problem. Given that level of intrusion, passwords and even biometric measures are likely to fail to protect the data. I'm not sure a secure token would be enough for that dedicated a hacker.

For less drastic protection, allowing the boot disk to load up the encryption algorithm and present a challenge and password should be sufficient. It would be very easy to configure a USB key to be the boot device for a system, and have the boot sequence mount the kernal from an encrypted disk. No MBR on the root disk at all, so the entire disk could be encrypted.

The final excuse.

[Anonymous Coward]

That removes the last excuse people have for not encrypting everything..."It is too complicated". Total encryption with a password at bootup...couldn't be simpler.

Re:The final excuse.

[stevie.f]

Nope, the last excuse for people is "What's encryption?"

Re:The final excuse.

[chord.wav]

Simpler uh? Expect more of the "Duh, I don't remember my password" problems, then.

Never underestimate stupid people, specially on large groups.

Re:The final excuse.

[Lord Ender]

No. Encryption imparts serious performance penalties. Normally, things like DMA allow you to transfer data directly from your disk to your RAM, another disk, or another device. With encryption, every bit must pass through the CPU to do crypto on it. It some cases, that is a very noticeable delay. At our company, that delay was too long for some purposes, so I had them use DriveLock instead, which has no performance penalty.

Re:The final excuse.

[maxume]

What about 'my data is more valuable to me than it is to anyone else'? I'm pretty sure that's a good reason not to bother with encryption.

Re:The final excuse.

[somersault]

But then you finally have a good reason to buy a supercomputer (to crack the passwords)! Or, alternatively, you could write them all down and put them in a safe.

Re:The final excuse.

[n6kuy]

No problem.
It's written on a piece of paper stuck to the bottom of your laptop.

Re:The final excuse.

[Lumpy]

SILLY! write the password on the bottom of your laptop!

Re:The final excuse.

[mi]

A reasonable compromise would be to encrypt only the "interesting" data — such as the /home partition and, maybe, the /var/log (or simply make sure the particular log-files you wish to protect — such as maillog — reside on the encrypted /home).

Whoever tries to crack your laptop is unlikely to be interested in the standard-issue binaries you may have installed...

Re:The final excuse.

[phantomcircuit]

All I have to say is this.

Re:The final excuse.

[TheSkyIsPurple]

Depending on your directive...

For us, since we can't guarantee our users store their confidential data in any particular location, we had to do full disk encryption and take the penalty.

Re:The final excuse.

[TAiNiUM]

What about data recovery? If my drive fails in some manner, can I still recover my data? Without this tool I can at least recover *some* data. Does this eliminate that possibility and turn it into an all or nothing scenario?

Re:The final excuse.

[Anonymous Coward]

But DriveLock is Windows-only. End of story.

Re:The final excuse.

[Anonymous Coward]

Isn't that what folder permissions are for? They don't have permission to write to any folder except those which you allow. Problem solved.

Re:The final excuse.

[Anonymous Coward]

Ignorance is no excuse; at least, not for government agencies or for corporations.

Re:The final excuse.

[Anonymous Coward]

Quite - any IT manager that is allowing his users to run as root / administrator is not doing his job properly.

Re:The final excuse.

[timeOday]

"That removes the last excuse people have for not encrypting everything"

The biggest "excuse" is data loss. Companies don't want employees having sole control over company data. This is something I worry about when I encrypt my personal backups, too; how can I be sure I'll still remember the password in 5 years? Does that risk worry me more or less than the risk of the backup being stolen and abused?

Re:The final excuse.

[Lord Ender]

It is well known that DriveLock can be broken. It is also well-known that breaking it is beyond the capability of 99.9% of laptop thieves. This is a fair risk/reward trade-off for all but the most sensitive data.

Re:The final excuse.

[Lord Ender]

The entire point of whole disk encryption is that it is impossible to define where "interesting" data is. Temp files, cache, and swap files can all end up with sensitive data in them. They only way to be sure is to encrypt the whole disk. (or nuke it from orbit)

Re:The final excuse.

[Lord Ender]

That is 100% false. DriveLock, aka "ATA Security Mode," works by direct interaction between the BIOS and the hard disk's firmware. DriveLock is in, out, and done before the MBR of the HD is touched. The OS has no influence.

Re:The final excuse.

[Eivind]

You are right, in principle

In -practice- most people use DMA only device-RAM (like video-card to RAM or network-card to RAM)

TrueCrypt would not interfere with any of that.

Re:The final excuse.

[Lord Ender]

Obviously you should rely on backups for recovery. That said, depending on the blocking mode used, recovery is possible with encrypted disks, though it is more complicated. If a few sectors go bad, but your blocking mode doesn't chain to those sectors, the rest of your data is theoretically recoverable... but you may need a crypto expert alter your software to handle this case.

Re:The final excuse.

[rizole]

How about; "what's my password?"

Re:The final excuse.

[Lord Ender]

I would have thought disk-to-ram via DMA would be a very common occurrence. My testers found serious performance penalties when using disk encryption with VMware (for sales demos). We obviously didn't publish our findings, but you seem to question them. Are you aware of any published benchmarks which contradict this?

Re:The final excuse.

[TAiNiUM]

But if your backups are unencrypted then what is the point of encrypting the primary operating drive?

From their FAQ:

Q: I forgot my password - is there any way to recover the files from my TrueCrypt volume?

A: TrueCrypt does not contain any mechanism or facility that would allow partial or complete recovery of your encrypted data without knowing the correct password or the key used to encrypt the data. The only way to recover your files is to try to "crack" the password or the key, but it could take thousands or millions of years depending on the length and quality of the password/keyfiles, on software/hardware efficiency, and other factors.

Re:The final excuse.

[__aaxwdb6741]

Yeah, of course, because you're smarter than ALL of the developers working on TrueCrypt. I can't believe they didn't ask you for advise first, or why you're not famous yet (With all those smarts you've got, and stuff!!!)

Or not. They require you to burn a "recovery" disk before you can do the whole-drive encryption. The point being that you store the disk in a safe, far away from the laptop.

In other words, read the fine manual.

Re:The final excuse.

[Skapare]

Maybe this isn't an "excuse" for not encrypting, but from what I read in their documentation, which doesn't really go into enough detail to satisfy me that they are doing things as reliable and efficient as possible, I would have to reformat everything to their special volume format. And I see at least a couple issues with its design. If I knew enough about the actual encryption algorithms, I'd just implement my own encryption system. If someone who does wants to join with me, maybe we can produce something.

Re:The final excuse.

[mattpalmer1086]

Why do you say DriveLock has no performance penalty? It does software encryption, same as TrueCrypt.

Re:The final excuse.

[DamnStupidElf]

General PC hardware doesn't allow DMA transfers between disks, AFAIK. Encryption also doesn't prevent DMA from working properly. You can still get full speed transfers over UDMA ATAPI or SATA interfaces. A modern CPU can easily encrypt or decrypt 100MB/s on modern hardware using AES, although if you have CPU intensive tasks they will obviously have to share some of the CPU with the encryption/decryption routines. Encryption is a tradeoff between needing absolute data secrecy and convenience. If you don't really need encryption, why even bother trying it? If you actually do need encryption, then convenience isn't really a consideration.

DriveLock looks like just a policy based device filter that stops Windows from using certain devices. Nothing prevents someone from taking the hard disk out and mounting it under Linux in another machine, or even booting from a Linux live CD or USB stick to get the data (unless you've disabled that in the BIOS, set a BIOS password, and the BIOS password can't be easily reset).

Re:The final excuse.

[Cairnarvon]

I see no reason why it should be impossible to recover much of the encrypted data and then just decrypt that. The whole disk isn't some giant encrypted blob that requires the entire dataset to decrypt; all you need is either one or two encrypted blocks, depending on the block cipher mode, and a block is typically not that big (128 bits for AES, which I think is TrueCrypt's default cipher).

It becomes impossible to tell the difference between scrambled data (or empty sectors) and real data, if there are any recovery techniques that rely on that, but on the whole, it shouldn't be more difficult to recover data in principle. Though you do need the encryption key.

Re:The final excuse.

[Alsee]

No, you forgot:

Huh? What?
Heay check this out! Brittney shaved her head again!

-

Re:The final excuse.

[cayenne8]

"It's written on a piece of paper stuck to the bottom of your laptop."

Nah...no need for that. I just keep my password simple to remember, it is the same one I used for my luggage!!!

Re:The final excuse.

[Hal_Porter]

DriveLock looks like just a policy based device filter that stops Windows from using certain devices. No, it uses the ATA security commands to lock the drive

ftp://ftp.compaq.com/pub/supportinformation/papers/na118a0598.pdf

No password, no read or write sector operations - it doesn't matter what OS you use. So it should stop a thief from accessing your data.

On the other hand the FBI can probably get the master password if they have a warrant

http://www.schneier.com/blog/archives/2006/05/man_sues_compaq.html

Re:The final excuse.

[Lord Ender]

Disk encryption is meant to counter a specific threat--laptop theft. Your backup server, hopefully, isn't sitting on a coffee table in an airport. Protecting your backup server is an entirely different issue.

Also, yes you CAN recover truecrypt volumes if you lose the password. If you backup the volume header and store that with a password, you may later get back at your data by restoring the volume header.

That FAQ is either out of context or out dated. I've recovered TC volumes using volume headers.

Re:The final excuse.

[Lord Ender]

If I load a file into RAM using DMA, I don't touch the CPU. If I'm using encryption, everything must go though the CPU and every block must be decrypted. This isn't about CPU speed, it's about bus speed.

DriveLock looks like [something completely wrong]

Look harder. DriveLock is ATA Security Mode. Your disk's firmware refuses to cooperate until it gets the right password from your BIOS. It is completely independent of the OS. The only way around it is to clean-room and move the platters to an identical casing.

Re:The final excuse.

[mi]

For us, since we can't guarantee our users store their confidential data in any particular location

How do your users manage to put their files outside of where you permit them (plus /tmp and /var/tmp)?

There are large swathes of directories, where no user's stuff can be saved. These can be made accessible directly — without encryption and the associated performance penalty.

I realize, that it may be simpler (and still within budget) for you to just use a hardware solution to encrypt everything — my point is, that is not the only option. What I'm describing is a workable compromise...

Re:The final excuse.

[Anonymous Coward]

No. Encryption imparts serious performance penalties.

Unless you put crypto right on the CPU. Sun's Niagara 2 can saturate its two 10gigE on-die network connections. Unfortunately there's aren't many other CPUs do crypto.

Re:The final excuse.

[afidel]

More specifically for a large organization: How do I implement key recovery in a secure and manageable way.

Re:The final excuse.

[cecil_turtle]

"Serious performance penalties"? I've been running a few whole-disk-encrypted laptops for over a year now and I have to say the performance drop is not noticeable for me. What encryption program specifically did you try? When you say "every bit must pass through the CPU" - only bits read from and written to the drive, and drive I/O is pretty slow compared to modern CPUs. Maybe your company has extremely high performance requirements but in my experience there is not a "very noticeable delay".

Re:The final excuse.

[Lord Ender]

The groups in my company that had performance problems were those who routinely ran simulations and demos using multiple VMware instances.

Re:The final excuse.

[rtechie]

The big reason not to do this is because there is no data recovery mechanism. If you loose the password you're fucked. If the drive crashes you can give up any hope of data recovery because you went out of your way to mangle the data (by encrypting it).

True, in the narrow edge case where sales agents are carrying COPIES of customer data (that is backed up on another server) on company laptops and the data is considered more valuable than the laptop, this makes sense.

Otherwise it just makes disaster recovery impossible.

Re:The final excuse.

[jdbear]

Oddly, I've never noticed any difference. I guess I'm just not as fast as you?

Re:The final excuse.

[RiotingPacifist]

Drive lock is completely unsuited to your needs.
The performance hit is trivial with most encryption methods, i recently unencrypted my / and there is no speedup (apart from lack of password) same can be said for swap and temp.
I only had problems in 1 area, i was using an ntfs, truecrypt, ext2 partition, for my home, the culmination of the ntfs & truecrypt was noticeable, however that was with the old truecrypt its a shame this news is a day too late for me :(

There are very few times you want data to get of a system without going through the CPU, straight from disk to ram smacks of rootkits and the sort.

Re:The final excuse.

[jdbear]

Um, perform encrypted backups? Or is that too much?

Personally, I rsync a diff of my files over ssh to another computer and store the results in a compressed archive on an encrypted drive. I have multiple copies of my files in case of failure, all transport was encrypted, and all files remain encrypted on all media.

Re:The final excuse.

[TheSkyIsPurple]

If the IT manager is allowed to do his job...

Too many developers in our company are old-timers and connected to the EVPs.
It took several years of fighting just to get enough support to not allow developers to disable antivirus software.

Re:The final excuse.

[TheSkyIsPurple]

> What I'm describing is a workable compromise...

Not in our company.

It took years of fighting just to get developers to not be allowed to disable their antivirus software.

And these are mostly Windows machines, so removing admin access is a little trickier than on a Linux machine.

Re:The final excuse.

[mrv20]

I remember hearing a story that I would dearly love to be true about someone who kept forgetting their ATM PIN so rather than make the mistake of writing it on a bit of paper that they carry with the card, they wrote it in permanent marker on the housing of their local ATM.

Seemed pretty smart, as dumb ideas go.

Re:The final excuse.

[mi]

And these are mostly Windows machines

Oh, well, you should've started with this info. All bets are off, of course...

Re:The final excuse.

[symbolic]

There are so many things that require usernames and passwords now. Every site wants a set of 'registered' subscribers. Then there are banks, work logins, email accounts, etc. Password overload. And then, if you actually expend the effort to use secure passwords, it gets even worse, because even if you remember the general password (or phrase), you forget the little tricks you used.

Re:The final excuse.

[AviN]

The following service appears to permit unlocking a password protected hard drive for $49.95:

http://www.hdd-tools.com/products/rrs/

Re:The final excuse.

[NateTech]

Seems like if they have AV turned off, there's plenty of ways to lay traps for them to stumble over that would cause SERIOUS company-wide problems.

Not saying this is ethically all that great, but you're not being creative enough if you haven't though of ways to teach them the lesson the hard way.

Half-joking, half-serious... where's your BOFH *skills*, man?!

Re:The final excuse.

[Lord Ender]

The people with encryption slowdowns were running multiple simultaneous VMware instances on their laptops for the purposes of sales demos.

Re:The final excuse.

[chord.wav]

Never said I was smarter than anybody, chill out man.
Never stated that TrueCrypt does bad software, on the contrary, I'm sure they do a fine job.

My point is, as life in Jurassic park, users, ALWAYS find a way. Regarding information security, the weakest link usually tends to be the user.

That's all.

Hope your day gets better. Cheers.

Re:The final excuse.

[Eivind]

disk-to-ram is very common. But what you're missing is that this is NOT prevented by the use of encryption.

It means that what was:

• Order Disk to DMA certain blocks to a certain RAM-location
  
• Wait for disk to signal "done".
  
• Deliver the data to the app (how depends on if it's read() or mmap() or whatever)
  

Now becomes:

• Order Disk to DMA certain blocks to a certain RAM-location
  
• Wait for disk to signal "done"
  
• Decrypt blocks (in-place)
  
• Deliver the data to the app
  

The DMA-step isn't influenced at all. All that happens is that you need to decrypt the data prior to returning it to the application.

This -does- take additional time offcourse. But in most settings it isn't very significant. With modern CPUs decrypting a few blocks of data goes MUCH quicker than physically accessing disc. If the disc spends 70ms actually getting 100 blocks of data into RAM it doesn't make -that- much of a difference that you now need to spend 5ms additionally to decrypt the blocks. (if we assume 1KB blocks this means 100KB of data in 70ms for the disc, adds up to 1.5MB/s for the disc, slow but realistic for a small transfer like this, you're punished for the seek and rotational latency.

5ms for the decryption is actually fairly generous, it amounts to an encrpytion-speed of 20MB/s, and for example my fairly standard Core2 Duo running at 1800Mhz can do more than double that using only one of the cores.

For larger transfers the slowdown is more noticeable. If your disc can do 40MB/s sustained, that would be about equal to the decryption, so you could see a slowdown to half speed. Worse yet: when copying a file from one encrypted filesystem to another you need to first decrypt with one key, then re-encrypt with another. Which takes double time, so in principle you could see what used to take 2 minutes now taking 6.

In practice it's not quite that bad, because on larger transfers you can do decryption/encryption in parallell with the disc working. You don't need to idle the CPU until the disc is done and then idling the disc until the CPU is done, you can run both in parallell.

Still, in general I'll say that not-noticeable for small seek-dominated access, to half-speed at large transfers fits pretty well with my practical experiences. More RAM helps, because it means stuff can be buffered and encrypted "later" when the CPU has a spare microsecond or two.

a pity the British government won't use it

[tolworthy]

It's not by Microsoft. Plus they don't have much data left to lose.

Re:a pity the British government won't use it

[Anonymous Coward]

Well, the UK government agency I work for forbid the laptop to be taken away from site until such system has been found and installed on every laptop. They also extend that to all memory stick, pda and phones that could be used to store personal data. AS most phojnes nowadays have some kind of memory, if you visit any of our site with you phone, they should confiscate it until it can be encrypted.

That you have data to protect or not does not make any difference for them.

I'm a software developer to work at making scientific data available for re-use my old laptop contains only my code. I don't have access to any of the restricted data sources like the HR databases, science proposal database or travel agency data.

I'm not sure that they would trust TrueCrypt as it is free.

Re:a pity the British government won't use it

[Anonymous Coward]

A pity the British government employs naval officers who know how to tie a bow-tie or abseil down a cliff, but don't have enough common sense to avoid leaving a laptop computer containing restricted data in a car seat. A pity the British government employes software developers who don't know English.

Re:a pity the British government won't use it

[Constantine XVI]

I'm not sure that they would trust TrueCrypt as it is free. On the other hand, they could ultimately trust TrueCrypt because the source is open, and they (or someone they paid to do it for them) could easily vet it's capabilities.

Re:a pity the British government won't use it

[Anonymous Coward]

You're not at Rutherford or another STFC site are you? I'm wondering how much of these ludicrous new rules are due to the cabinet office and how much is due to incompetent STFC people. I've been talking to other labs and they seem to have a much more sensible policy (ie if you have national insurance + bank details of people, encrypt it if you take it offsite which should be done) but dont completely cripple peoples ability to do their job if they are extremely unlikely to have any personal data.

A RAL Researcher (who cant take his laptop offsite even though it has NO personal data on it and like his coworkers is pissed off)

Mirror, mirror, on the wall...

[Anonymous Coward]

Truecrypt.org took a fall.

Mirror anyone?

Re:Mirror, mirror, on the wall...

[Library Spoff]

You can ONLY download from truecrypt.org. According to the sourceforge page anyway...

How to DDoS your favorite open source project.

[Scott Lockwood]

Step 1: Post on Slashdot
Step 2: ???
Step 3: Profit!

Re:How to DDoS your favorite open source project.

[Loibisch]

This particular news item was probably submitted by a puppet of the *IAA...

Re:How to DDoS your favorite open source project.

[Anonymous Coward]

It's not /.'ed.
The contents are encrypted, duh.

Site

[w3bd4wg]

Does not Slashdot notify the site owner of the post?

Re:Site

[Rob T Firefly]

The few zillion referrer tags coming from this URL is sort of an "OH HAI GUYZ!"

Re:Site

[shakestheclown]

Where are the Snowdens of yesteryear?

One thing annoys me:

[imsabbel]

They have to option to convert boot drives to encrypted drives... even while the system is running.
Thats nice.

But how about converting non-boot drives?
Doesnt seem to be possible.

Not everybody starts with a blank sheet, or has double the needed capacity to empty first one HD and then another...

Re:One thing annoys me:

[Grym]

Converting non-boot drives seems like a fringe use, honestly. Most people can just make a new truecrypt volume and then mount like normal. For everyone else, move the files temporarily onto DVD-R/CD-R media, create a truecrypt volume, then move the files into the new truecrypt volume. Problem solved.

-Grym

Re:One thing annoys me:

[hey!]

That doesn't seem so important to me.

If you want something encrypted, you put it on a truecrypt drive; you can move it from the original drive to the truecrypt drive, then juggle the drive letters if you use windows, the mount points otherwise. The only thing that can't get this treatment is the boot drive, therefore (uniquely) you have an absolute need for a way to encrypt that while it is running.

Re:One thing annoys me:

[Anonymous Coward]

And remember to microwave the DVDs/CDs after your finished with them, if it's information you want to keep secret.

Re:One thing annoys me:

[waddleman]

Assuming there is free space to move data between and have room for a new partition. While not critical, still an inconvience

Re:One thing annoys me:

[Firehed]

That's still a pain in the ass if they can already do it on the drive you're running from. Surely that's much more complicated than encrypting data that's NOT loaded as part of your kernel.

I'd be much more likely to convert a non-boot drive to full encryption anyways. I find typing a password in enough of a pain so a nice, long, secure passphrase would drive me nuts on bootup. I'd much rather just store any sensitive data on a second disk - not only does that mean I'm not completely hosed if I forget the passphrase (or make a typo while pounding out a paragraph while I'm in a hurry), but I can easily physically separate the encrypted sensitive data so it never has to go offsite.

Re:One thing annoys me:

[HP-UX'er]

don't forget to destroy the media afterwards!

Re:One thing annoys me:

[Anonymous Coward]

What do you mean with "truecrypt drive" -- a TC image file or an external hard drive?

Because if you have the scenario with a 160 GB data drive with 100 GB in use and no large enough external hard drive lying around, you won't have space to move the unencrypted data to the encrypted storage if you intend to use an encrypting image to move to. Note that TC do NOT support "growing" volumes, but only static ones. So you'd really want to make the 160 GB TC image in one go if you intend to use image files. And then you'd have to use something like DVD's as temporary storage...

Re:One thing annoys me:

[Jugalator]

Yes, granted it would be safer security-wise to encrypt the system drive than going through the trouble of ensuring the system doesn't store anything sensitive on it without your knowledge.

However, if the encryption is only about personal documents, mails, and simple things like that, and you don't need "deep" encryption of various stuff that may risk ending up on the system drive without your knowledge, I would also rather encrypt a non-system drive. That way, you would as you say not always have to enter a passphrase, and also gain a lot of performance boosts since an operating system that's running encrypted (swap file and all) could have a noticeable performance penalty.

Re:One thing annoys me:

[TheSkyIsPurple]

I know we'd be interested in this, but we need something that can be rolled out to tens of thousands of machines automatically, encrypts in the background with minimal hassle to the user, won't lose data if power is lost during encryption, and will resume automatically after the system comes back on.

Our current Windows-only solution does that, so the Macs get left untouched... which works out OK for me, but is technically a problem =-)

Re:One thing annoys me:

[Asm-Coder]

That is already a feature of truecrypt, and has been for a long time. I currently use it for my data partition, and am rather impressed that I don't notice any performance penalty..

Re:One thing annoys me:

[imsabbel]

I know you can use it for data partitions (or whole drives).
But you cannot convert full data drives into encrypted data drives. You first have to copy everything off, create the volume, and then move everything back.

Re:One thing annoys me:

[Anonymous Coward]

Changing fstab is easy, juggling with drive letters will almost certainly break a Windows install.

Re:One thing annoys me:

[Monkeybaister]

Everyone is ignoring the security problem with this, the unencrypted versions should be destroyed! What better way to do that then by overwriting with an encrypted version of the partition!

Re:One thing annoys me:

[Anonymous Coward]

Rather, encrypt the discs with TrueCrypt.

Re:One thing annoys me:

[Hal_Porter]

If you run Windows you can use the EFS for that stuff. It's a feature of NTFS that supports encryption on a per file or per directory basis. So you could encrypt your documents directory. Then anything you save there will be encrypted and decrypted on the fly. So it would stop someone using a boot CD to get at them. Best of all if someone resets your password the decryption key is invalidated since it is hashed with your password.

Re:One thing annoys me:

[Bonker]

It doesn't seem to be possible in the Truecrypt app at the moment. You can encrypt entire devices and have them mounted, though. It's great for removable drives and USB sticks.

Re:if truecrypt.org is still down

[Sal Zeta]

Too Bad that for some reasons they refuse to upload any files on the sourceforge server. There is only a "the files are only on truecrypt.org.html" available.

Download here (as the site seems down atm)

[_bug_]

http://sourceforge.net/projects/truecrypt/

Press release here.

We are pleased to announce that TrueCrypt 5.0 has been released. Among the new features are the ability to encrypt a system partition or entire system drive (i.e. a drive where Windows is installed) with pre-boot authentication, pipelined operations increasing read/write speed by up to 100%, Mac OS X version, graphical interface for the Linux version, XTS mode, SHA-512, and more.

After four years of development, during which millions of people downloaded a copy of TrueCrypt, it is the only open-source disk encryption software that runs on Windows, Mac OS X, and Linux. The newly implemented ability to encrypt system partitions and system drives provides the highest level of security and privacy, as all files, including any temporary files that Windows and applications create on system drives (typically, without the user's knowledge or consent), swap files, etc., are permanently encrypted. Large amounts of potentially sensitive data that Windows records, such as the names and locations of files opened by the user, applications that the user runs, etc., are always permanently encrypted as well. For more information, please see http://www.truecrypt.org/docs/?s=version-history

Re:Download here (as the site seems down atm)

[base3]

You can't get the distribution from SourceForge. The download page only contains text directing the would-be downloader to truecrypt.org.

Re:Download here (as the site seems down atm)

[Shabbs]

Sourceforge no longer carries the latest versions. Distribution is only via truecrypt.org. We'll have to wait the Slashdotting out.

Re:Download here (as the site seems down atm)

[Anonymous Coward]

http://superb-west.dl.sourceforge.net/sourceforge/truecrypt/IMPORTANT--Official_TrueCrypt_distribution_packages_can_be_downloaded_only_from_www.truecrypt.org.html

As of November 2, 2005, all official TrueCrypt distribution packages can be downloaded only at:

http://www.truecrypt.org/downloads.php

SourceForge.net mirror servers are no longer used. For more information, visit www.truecrypt.org

What about wake up?

[unbug]

I almost never turn off my laptop, I just close the lid. Will it ask me for a password when it wakes up again?

Re:What about wake up?

[smooth wombat]

If it's anything like SafeBoot, no. Would you want to have to put in a username and password twice every time your laptop went to sleep?

The way SafeBoot works you only have to get past it once, when your machine starts, then you log onto the domain.

Re:What about wake up?

[apathy maybe]

In Windows at least (not sure with the other versions), you can set it to dismount mounted volumes whenever certain ACPI events (lid closing, suspend or hibernate etc.) happen.

This forces you to re-enter your password to access the volume.

Of course, you should have an option in your OS to ask you for your login password whenever you close and then open your lid as well.

Re:What about wake up?

[twoshortplanks]

No, but you should have a screensaver that won't let you use the computer unless you enter a password.

Normally this wouldn't offer complete protection - you could just reboot from a system disk and access the filesystem, but with truecrypt (or FileVault, or any of the other encrypted file system solutions) they can't do this.

Re:What about wake up?

[binaryspiral]

I think you're missing the point. The data continues to be encrypted - even if your operating system is using it.

So if your computer is in sleep mode or has a screen saver - you need to password protect your computer so that you control who accesses your data and apps.

If I wanted your data, and I didn't know your password - I would get your entire drive (either by stealing it, booting up with a liveCD, or image it to another drive). Now I can't even do that because the data is encrypted on the disk, not just password protected by the OS.

Re:What about wake up?

[unbug]

Of course, you should have an option in your OS to ask you for your login password whenever you close and then open your lid as well. I don't see how that helps. Simple way of circumventing this:

• Wake up laptop, do not try to log in on the console.

• Hook it up to a network.

• Log in remotely, exploiting a vulnerability in the OS (every OS has one).

• Access encrypted drive.

Not asking for a password on wake up looks like a huge security hole to me.

Re:What about wake up?

[Lord Ender]

Unless the thief is specifically targeting your data, the computer will have to make it through the black market, and the battery will die before someone who knows what they are doing gets their hand on your PC.

Re:What about wake up?

[Exp315]

I agree, that's the key weakness in Truecrypt. I hibernate both my desktop and laptop systems, and mounted Truecrypt drives remain mounted with no need to re-enter the password no matter how much time has passed. A data thief would have no problems. I think Truecrypt needs a review of their real-world security. And BTW, I've run into bugs with previous versions of Truecrypt used to encrypt USB drives where it suddenly stopped accepting the password and I lost access to the data. Nothing vital lost, but enough to scare me off using Truecrypt again.

Re:What about wake up?

[gardyloo]

You mean there are no power bricks or batteries on the black market?!? I feel sorry for those guys.

Re:What about wake up?

[borisrules]

if I leave my laptop turned on and someone else sits down at it, is this a security hole?

Re:What about wake up?

[Anonymous Coward]

Truecrypt doesn't really need this. It's a Windows feature. You can make Windows lock automatically when the laptop goes to standby mode. After that only way to get access to the laptop's unencrypted hard-drive contents is to knowing the user account password or rebooting the system and knowing the boot password.

Re:What about wake up?

[Just Some Guy]

Wake up laptop, do not try to log in on the console.

That would work great. If TrueCrypt didn't really dismount the encrypted volume like the grandparent said it did. Because in that case, your idea wouldn't do a darn thing.

Re:What about wake up?

[Lord Ender]

The thieves primarily want the value of the hardware. The idea that the average laptop snatcher will immediately plug it in to a backup battery and deliver the entire package to a data recovery expert while the generator is running is... well... a bit far-fetched. I'm sure some purchasers of stolen laptops will go for the data, but I doubt they care enough to keep them powered on the whole time.

Re:What about wake up?

[PitaBred]

How is that a problem? You hibernate, and you still need a password to get back into Windows, right? If they reboot or try to boot it from a LiveCD, you're safe since the data's encrypted. Mounting through TrueCrypt isn't a magic "decrypt everything on the drive" switch, it just allows decryption through the running OS. Perhaps you're the one who needs a bit of a review on computer security.

As for USB drives, I haven't ever had that issue, but I could see it happen if a bit physically goes bad where it tests the password for validity. But I haven't ever seen that happen. To each his own... I'd trust TrueCrypt more than any other encryption, and it's better than no encryption if you want to keep things safe. Not to mention, why don't you do backups? You can back up the encrypted file/drive periodically and still access it through the password, and it's safe while encrypted. Any reason you weren't doing that?

Re:What about wake up?

[Anonymous Coward]

FileVault is actually pretty much useless on laptops. You see, Apple's laptops and some of their desktops do something called "Safe Sleep". I first saw it on IBM machines a while ago. Essentially, the system performs a hibernate operation, then goes to sleep. That way, if it still has power, it just resumes from RAM. If it loses power (you swap batteries, for example), it resumes from the disk.

The problem is that the image of your RAM is not encrypted (in Tiger, at least; I'm not sure about Leopard). The RAM needs to have your crypto keys in it in order to read from and write to the FileVault volume. Pull the drive, find the sleepimage file (it's in /var/vm, with the swap files) then cat it and run it through strings. Admittedly, you'll have quite a lot of potential passwords, but far fewer than the entire potential keyspace of an arbitrary password. It would be trivial to turn that into a dictionary and feed it to a traditional password cracker.

Further, someone who really knows what he's looking at might be able to just find the key outright and wouldn't need the password.

Re:What about wake up?

[Atti K.]

In Truecrypt's menu, under Settings -> Preferences, there is an Auto-Dismount section. TrueCrypt volumes can be automatically dismounted when:

• user logs off
• screen saver is started
• enters power saving mode
• no data has been written for x minutes

Dismounting can be forced even if there are open files on the volume. All those options were there even in TrueCrypt 4.3.

Re:What about wake up?

[ABCC]

But can you unmount the partition windows is installed on when it's in sleep mode??

Re:What about wake up?

[guardian-ct]

Plus, if they leave it powered on the whole time, they risk having the laptop send out an "I was stolen" message the each time it found itself in a different network environment (or after a set time, etc. etc. depending on anti-theft software and/or inclination).

Re:What about wake up?

[ditoa]

Interesting question so I just tried it with a system I have just done a whole disk encryption on using TC5.

Stand By does not cause the system to boot up again so it just returns to Windows without asking for the TC password. This is correct behaviour as TC can only prompt when the system boots, as the system is not booting it cannot ask.

Interestingly when I tried to enable Hibernation via Power Options TrueCrypt intercepted with a message explaining that it has disabled Hibernation as the disk is encrypted. The reason given is that the contents of the system memory is written to the hibernation file thus the encryption keys would be written to the hibernation file.

For those interested I encrypted my system (3.4Ghz P4) with 20GB system partition (of which only 1.94GB is used) in little over 15 minutes. Boot performance was a few seconds slower but once up and running system feels the same. I have not tried copying any large files though, I am sure this would stress the system a bit. YMMV :)

Re:What about wake up?

[ditoa]

Bad form to reply to myself I know but I took a screenshot of the message for those interested.

http://x025.uploaderx.net/x/tc-hibernation.png

Re:What about wake up?

[Zaffle]

I agree, that's the key weakness in Truecrypt. I hibernate both my desktop and laptop systems, and mounted Truecrypt drives remain mounted with no need to re-enter the password no matter how much time has passed. A data thief would have no problems

There are two kinds of people, those who understand cryptography, and those who think they do.

The encryption is live "on-the-fly" encryption, this means the bits and bytes stored on the disk are encrypted as they are written to disk, and decrypted as they are read. So if you laptop was booted, and you forgot to shut it down right, the whole disk(*), everything, is still encrypted.

Now, as for hibination, sleep mode, etc. If your laptop prompts you for a password everytime to goes to sleep or hibinates (and it SHOULD, even without full disk encryption!), then the would-be-attacker has three choices when he steals your laptop while its sleeping or hibinating.

1. Rip the disk out, and inspect it. Whoops, its still encrypted (even though it was running while it was ripped out).

2. Power cycle the PC, and try and boot it. Whoops, its still encrypted.

3. Crack/break/bruteforce your screensaver. Assuming you aren't running X in its default setup (where you can press Ctrl+Alt+F2 and bypass the screensaver(**)) then this should be very difficult.

So, the short story is, sleep mode and hibinate are not the giant loopholes you seem to think they are.

Now, just because in the world of cryptography, nothing is simple, you do have one point - a laptop that is sleeping would presumably still have the disk master key stored in memory (so it can read the disk). In *THEORY* a sufficiently advanced hacker, *COULD* steal a laptop that was sleeping, with full disk encryption, and password protected screensaver, and use some funky hardware to read the RAM on the system whilst it was still running/sleeping. We are talking NSA level hacks here, this isn't a simple task, but its in theory, possible. The only way to defeat this would be to wipe the master key just before going to sleep, and prompting the user for their full disk boot password when the laptop wakes up before userland is activated. You'd only be able to do this with the assistance of the kernel, as swap and everything else would be unavailable until the master key is retrieved again.

* - Yes, full disk encryption is most of the time, partition level encryption of the system partition, but to simplify the discussion, I'll refer to it being full disk.

** - Yes, the would be hacker would still be prompted for a getty user/pass, but thats assuming you haven't left a console open by mistake. I always disable the Ctrl+Alt+F keys on X on laptops. The other aspect is once the screensaver is prompting you for a password, the PC is back on the network. However, if a solution as above was implemented, the wake-up password would occur before userland is running again.

Re:What about wake up?

[sidb]

In Tiger or Leopard, check "Use secure virtual memory" in the Security preference pane.

Re:if truecrypt.org is still down

[Scott Lockwood]

IMPORTANT: Official TrueCrypt distribution packages can be downloaded only from www.truecrypt.org (above, select 'Project' > 'Web Site')

You Fail It.

Re:Slashdotted - Download Mirror on Filehippo

[HP-UX'er]

Here it is

Re:if truecrypt.org is still down

[base3]

Thanks, but the packages are not available to download from SourceForge. "IMPORTANT: Official TrueCrypt distribution packages can be downloaded only from www.truecrypt.org (above, select 'Project' > 'Web Site') Notes"

Re:Slashdotted?

[imbaczek]

Both!

Mod me +5 Captain Obvious. kthx.

download link

[treak007]

The site is down, but the sourceforge page is not.

http://sourceforge.net/projects/truecrypt/

Finally a Linux GUI :)

[Loibisch]

I've been waiting for this release. I know that real men use the command line for each and everything including brewing their morning coffee, but I was really looking forward to the graphical user interface. :) Of course, thanks to Slashdot now the site (which has been dead slow all day) has now been blasted out of orbit...

Ah well, maybe the storm will be over till I'm home.

Re:Finally a Linux GUI :)

[Hatta]

I've been waiting for this release. I know that real men use the command line for each and everything including brewing their morning coffee

Holy shit, you can do that?! And I've been weighing, grinding, and pouring my own coffee by hand. This is one time I really wouldn't mind being replaced by a very small shell script.

Re:Finally a Linux GUI :)

[Loibisch]

Sure you can, here you go: HTML version | text version

My favorite part must be from the "device driver" section:

Just read kernel hacker's guide, implement a device driver (it could even be user space I think). Please compile it as a module, so that we won't need a kernel compile in every update. Then write:
        echo cappuccino > /dev/coffee
And you will have a hot cup of coffee in minutes! Remember to give the right permission to /dev/coffee, depending on whether you want only root making coffee or not. Have fun setting that one up. :)

Re:Finally a Linux GUI :)

[russ1337]

I've been waiting for this release. I know that real men use the command line for each and everything including brewing their morning coffee,

I brew my coffee with butterflies and wind currents.

Re:Finally a Linux GUI :)

[CompMD]

$ ./configure --percolator="mr_coffee" --grounds="fine" --cups="12" --install_dir="/usr/local/coffeepot"
$ su
Password:
# make coffee
make: Target 'coffee' has been made in /usr/local/coffeepot
#

Re:Finally a Linux GUI :)

[Anonymous Coward]

$ /usr/local/coffeepot --help

coffeepot version 0.89arabica

switches:

-h --hot brew hot coffee (default is cold)

$

Re:Finally a Linux GUI :)

[amorangi]

Unfortunately it's a hobbled gui - you can't create hidden volumes for instance.

Re:Finally a Linux GUI :)

[The_reformant]

I know that real men use the command line for each and everything including brewing their morning coffee

My sugar cubes won't fit through the pipe.

Re:Finally a Linux GUI :)

[Loibisch]

I haven't had the chance to try it yesterday. I could live with the occasional trip to the command line, all I need is a proper GUI for the everyday tasks like mounting and unmounting multiple images easily...hoping this will do the trick.

Dual boot?

[Anonymous Coward]

How well does this play with with the other *legitimate* operating system you might have on the computer? Would you be locked out of a drive on the other?

Re:download link NOT

[Anonymous Coward]

If you'd take a moment and actually LOOK at their Sourceforge entry, you'd not have posted this. Here's what it says there:

IMPORTANT: Official TrueCrypt distribution packages can be downloaded only from www.truecrypt.org (above, select 'Project' > 'Web Site')

So - no Truecrypt 5 until http://www.truecrypt.org/ is back up. Sit tight folks.

Will the karma whores . . .

[Anonymous Coward]

. . . please quit linking to SourceForge. The download packages ARE NOT AVAILABLE THERE, as would be obvious if the posters had bothered to look before trying to farm points.

Mac version???

[Rufty]

Is the long promised OSX version out yet? Or still vapourware???

Re:Mac version???

[Nimey]

It's here and it works.

Re:Mac version???

[sssssss27]

Read the summary:
"The Linux version receives a GUI and independence from the kernel internals, and a Mac version is at last available too."

Re:Mac version???

[EXMSFT]

But is there a Mac version available?

Re:Mac version???

[Roadstar]

It's here and it works.

I wish it did. I've downloaded the package a few times, and I just can't get the Intel Leopard dmg to mount (tried the PPC one with similar results, too). When I try to extract the package from terminal, I get "bunzip2: TrueCrypt 5.0 Leopard Intel.dmg.bz2: trailing garbage after EOF ignored" and it fails to mount. The same happens if I try to extract the .bz2 with The Unarchiver and mount it. Checking the dmg with Disk Utility states that it has an unrecognized filesystem.

If any of you have a working version, could you please post the md5 checksum? And yes, I know that it would be more efficient to post to the TrueCrypt forums, but they are down at the moment.

Re:Mac version???

[Nimey]

010e18f55e5c885dc5a17177cd32f817 TrueCrypt 5.0 Leopard Intel.dmg

Re:Mac version???

[Roadstar]

Thanks! With the checksum I noticed that my Safari had appended .bz2 extension to the filename even though it was the actual dmg right from the start. So I just had to get rid of the additional extension and mount it afterwards. I'm not too surprised about the dmg failing to mount after running it through bunzip2 :)

In case you have messy hair

[jeric23]

And no mirror, try file hippo ( http://www.filehippo.com/download_truecrypt ).
If that somehow fails you, or want to download it even faster. Try the P2P channel, I hear that's a popular one these days. Check your local listings for TrueCrypt v5.

Hard Drive Read/Write Times

[sjaguar]

As someone who has never used a full-drive encrypted, how does this impact hard drive access? Will reads/writes be noticeably slower (assuming a relatively new drive)? Will this affect utilities such as a defragmenter or disk checker? How much slower will boot up be? What about memory or CPU usage?

I am all for more security. But, if it slows my laptop down to the point of un-usability....

Re:Hard Drive Read/Write Times

[imsabbel]

My personal experience with TC 4.0 (and, obviously, not my boot disk):

Random accesses arent slowed down noticable, but large STR (like copying 50Gbyte to another HD) are. For me, the limit was about 30Mbyte/s.
But as this is driver-level CPU load, and not interupt driven, the system responsitivity was not negatively affected.

Memory usage is neglectable, and CPU load scales linearly with bytes/s. So in most scenarios, or multicores, its not the limiting factor.

But you would NOT want to capture video or stuff like that onto a truecrypt volume

Re:Hard Drive Read/Write Times

[CavemanKiwi]

I use encryption software on my work laptop and it seems to make it considerable slower. It isn't too bad for me but it seems to freeze completely every now and then. I don't use the laptop for intensive work and even then I do notice it; I tend to use the laptop to remote into my desktop more often. I have heard other people complain a fair bit. So yes it does slow the system down a noticeably, but if you use it for basic tasks it should run fine.

Re:Hard Drive Read/Write Times

[WuphonsReach]

I am all for more security. But, if it slows my laptop down to the point of un-usability....

There will be a performance hit, but my plan is to:

1) Make two backups of my entire disk with something like Acronis TrueImage. That way, if I decide I don't want to stick with full-disk encryption, I can revert back easily.

2) Leave my backup drives unencrypted. My primary worry is that someone swipes the laptop. So I use something like Second Copy to write data files off to a regular USB external drive periodically in the office.

I've used older TrueCrypt volumes in the past. They're extremely handy. I use them on my laptop to store select documents in a secure location. Combined with a bit of GPG, and I can lock up secrets fairly well.

Speed of regular TrueCrypt volumes doesn't seem to be an issue. I've seen 15-25 MB/s transfer speeds when copying between two different TC volumes (on two different spindles).

Downloading

[margam_rhino]

I will just wait until you pesky North Americans are in bed and download in the morning UK time, ha ha. Wait, no, everyone forget I said that! Aww, now you all will try then.

Re:Downloading

[SQLGuru]

You forget: that will be when everyone's torrents are running sucking up the bandwidth....

Layne

OT -- what's the state of flash encryption?

[swb]

Like for USB drives?

Are there any standalone encryption systems that don't require software install on the host environment but can "mount" an encrypted disk file on a USB drive?

Re:OT -- what's the state of flash encryption?

[Thyamine]

It seems to me that you'd have to have software installed or part of any system you wanted to access that USB/removable media on. Otherwise the system won't recognize that it's encrypted and see gibberish, or won't know how to decrypt it at best. I know that some USB drives (at least the thumb drives) come with small applications for just that purpose, but you have to install it on each system you want to run it, and I don't know how secure it is as I've never used it myself.

Re:OT -- what's the state of flash encryption?

[XMyth]

TrueCrypt can do this when used in 'Traveler' mode.

It does install a system driver when in use, but the driver can reside purely on the unencrypted portion of the flash drive.

James

Re:OT -- what's the state of flash encryption?

[TheLink]

As far as I know there are encryption systems where you can run the program on an unencrypted partition of the usb drive in order to be able to mount the encrypted bits.

BUT would you want a computer that you don't have full control over, to have full access to:
0) your passphrase
1) the entire contents of your encrypted disk that's now decrypted after the mounting.

Think about that seriously.

Encryption is for terrorists.

[w3bd4wg]

http://www.truecrypt.org/downloads/transient/9b6d4c43d4/TrueCrypt%205.0%20Source.zip Forbidden You don't have permission to access /downloads/transient/9b6d4c43d4/TrueCrypt 5.0 Source.zip on this server. Apache/1.3.34 Server at www.truecrypt.org Port 80 I cannot get the source. The NSA has removed it.

Re:Encryption is for terrorists.

[w3bd4wg]

And I cant get the PGP file. http://www.truecrypt.org/downloads/TrueCrypt%205.0%20Source.tar.gz.sig

Features-Changes List from Truecrypt.org:

[Anonymous Coward]

5.0

February 5, 2008

New features:

* Ability to encrypt a system partition/drive (i.e. a partition/drive where Windows is installed) with pre-boot authentication (anyone who wants to gain access and use the system, read and write files, etc., needs to enter the correct password each time before the system starts). For more information, see the chapter System Encryption in the documentation. (Windows Vista/XP/2003)

* Pipelined operations increasing read/write speed by up to 100% (Windows)

Mac OS X version

* Graphical user interface for the Linux version of TrueCrypt
* XTS mode of operation, which was designed by Phillip Rogaway in 2003 and which was recently approved as the IEEE 1619 standard for cryptographic protection of data on block-oriented storage devices. XTS is faster and more secure than LRW mode (for more information on XTS mode, see the section Modes of Operation in the documentation).

Note: New volumes created by this version of TrueCrypt can be encrypted only in XTS mode. However, volumes created by previous versions of TrueCrypt can still be mounted using this version of TrueCrypt.

* SHA-512 hash algorithm (replacing SHA-1, which is no longer available when creating new volumes).

Note: To re-encrypt the header of an existing volume with a header key derived using HMAC-SHA-512 (PRF), select 'Volumes' > 'Set Header Key Derivation Algorithm'.

Improvements, bug fixes, and security enhancements:

* The Linux version of TrueCrypt has been redesigned so that it will no longer be affected by changes to the Linux kernel (kernel upgrades/updates).

* Many other minor but dickalicious improvements, bug fixes, and security enhancements. (Windows and Linux)

If you are using an older version of TrueCrypt, it is strongly recommended that you upgrade to this version.

Re:if truecrypt.org is still down

[leuk_he]

5.0

February 5, 2008

New features:

*

Ability to encrypt a system partition/drive (i.e. a partition/drive where Windows is installed) with pre-boot authentication (anyone who wants to gain access and use the system, read and write files, etc., needs to enter the correct password each time before the system starts). For more information, see the chapter System Encryption in the documentation. (Windows Vista/XP/2003)
*

Pipelined operations increasing read/write speed by up to 100% (Windows)
*

Mac OS X version
*

Graphical user interface for the Linux version of TrueCrypt
*

XTS mode of operation, which was designed by Phillip Rogaway in 2003 and which was recently approved as the IEEE 1619 standard for cryptographic protection of data on block-oriented storage devices. XTS is faster and more secure than LRW mode (for more information on XTS mode, see the section Modes of Operation in the documentation).

Note: New volumes created by this version of TrueCrypt can be encrypted only in XTS mode. However, volumes created by previous versions of TrueCrypt can still be mounted using this version of TrueCrypt.
*

SHA-512 hash algorithm (replacing SHA-1, which is no longer available when creating new volumes).

Note: To re-encrypt the header of an existing volume with a header key derived using HMAC-SHA-512 (PRF), select 'Volumes' > 'Set Header Key Derivation Algorithm'.

Improvements, bug fixes, and security enhancements:

*

The Linux version of TrueCrypt has been redesigned so that it will no longer be affected by changes to the Linux kernel (kernel upgrades/updates).
* Many other minor improvements, bug fixes, and security enhancements. (Windows and Linux)

If you are using an older version of TrueCrypt, it is strongly recommended that you upgrade to this version.

4.3a.......

==============
System Encryption

TrueCrypt can on-the-fly encrypt a system partition or entire system drive, i.e. a partition or drive where Windows is installed and from which it boots (a TrueCrypt-encrypted system drive may also contain non-system partitions, which are encrypted as well).

System encryption provides the highest level of security and privacy, because all files, including any temporary files that Windows and applications create on the system partition (typically, without your knowledge or consent), swap files, etc., are permanently encrypted. Windows also records large amounts of potentially sensitive data, such as the names and locations of files you open, applications you run, etc. All such log files and registry entries are always permanently encrypted as well.

System encryption involves pre-boot authentication, which means that anyone who wants to gain access and use the encrypted system, read and write files stored on the system drive, etc., will need to enter the correct password each time before Windows boots (starts). Pre-boot authentication is handled by the TrueCrypt Boot Loader, which resides in the first cylinder of the boot drive.

Note that TrueCrypt can encrypt an existing unencrypted system partition/drive in-place while the operating system is running (while the system is being encrypted, you can use your computer as usual with

Linux 64bit?

[Wubby]

Any word on 64bit binaries for Linux? I've compiled the Non-gui version without issue before, but with a gui, things get more complicated. GTK/KDE? Which libraries? etc etc etc etc etc

Re:Linux 64bit?

[Cley Faye]

GTK/KDE? Which libraries?

It's not like those questions are answered in a Readme file...

Re:Linux 64bit?

[jrwr00]

You can Compile the source to 64bit .. i think

FIPS 140-2?

[soboroff]

Are they planning to submit their system for FIPS 140-2? The US OMB decreed that most laptops must be encrypted with full-disk FIPS 140-2-compliant encryption, but the only certified tools for this exist for Windoze. The algorithms used are fine, but this stamp of approval would be very useful for federal Linux and Mac users!

Re:FIPS 140-2?

[SuperBanana]

The algorithms used are fine, but this stamp of approval would be very useful for federal Linux and Mac users!

http://www.extrapepperoni.com/2007/09/10/fips-140-2-for-mac-os-x/

Filevault already provides FIPS 140-2 compliant encryption.

Re:FIPS 140-2?

[keihin]

http://www.truecrypt.org/docs/?s=compliance-with-standards

  TrueCrypt complies with the following standards, specifications, and recommendations:

        * PKCS #5 v2.0 [7]

        * FIPS 197 [3]

        * FIPS 198 [22]

        * FIPS 180-2 [14]

        * ISO/IEC 10118-3:2004 [21]

!slashdotted

[Nimey]

The site is back up & is actually responding pretty quickly.

Risky?

[Anonymous Coward]

What are the chances I could break my system with this? I'm dual-booting Vista and Ubuntu with Grub. Does TrueCrypt add it's own bootloader, and will this play nice with Vista/Ubuntu?

Re:Risky?

[imsabbel]

Well, i could test it yet, because i discovered _another_ annoying problem:

I have 2 HDs, and a Raid.

HD1 has XP
HD2 has Vista
RAID has... well, raid
It cannot encrypt the vista partition, because the bootloader is on the first HD.

Re:Risky?

[tracerjpn4k]

Not really.

I also duel boot windows / linux, and ran into the following errors tryin to set it up with TC

You can't encrypt the whole drive if you have more than 1 OS on 1 drive (not partition)

You can encrypt only your windows partition, but ONLY if you are using the windows boot manager in your MBR, and move grub to your linux partition.

If you have 2 drives, 1 for windows and 1 for linux, you should be home free.

Guess i'll stick to encrypted volumes :)

Re:Risky?

[zsau]

I also duel boot windows / linux,

I myself am solely Debian-only, but I imagine duel booting goes something like this ...

Linux had been growing in popularity on the desktop for the last — well, even more than a decade, if you go back to his attempt for primary school captain — and felt it was time. Windows needed to be dealt with, finally. He accused Windows of improper behavior — changing file formats and systems and network protocols just so that Linux would be unable to read them — and threw a stone at the nearest window, breaking it. The insult was unmistakable.

Linux appointed his second: a grubby young boy named Chaine Loda. A few years ago it would've been Lilo, but he was past his prime nowadays. Windows had NTLDR. The seconds did their work well: the duel would take place at dawn exactly tomorrow morning, where the Murray and Berly Rivers join: The set out immediately by train.

Throughout the night, Windows slept soundly, confident that the upstart had come in a bit to soon. It would be easy; Windows was not the fastest shooter any more, but he was still far better than Linux. And it would be a synch for Windows to buy a better gun than Linux could possibly dream of.

And indeed, Linux was worried he had made the wrong choice. Surely Windows needed to be brought down, but he was the best bet and if he mis-stepped — but no point in dwelling on it. He spent the night upgrading his home-made gnu, which was now at a point where it was the rival of any. It still looked a bit plain around the joins, but surely the design and execution — he regretted thinking that word the moment he had — were excellent. Linux did not sleep that night, but he rarely did so it did not bother him much. He would be at the peak of his form, and Windows would be groggy, without the sleep shaken out of him.

And, well, it was almost dawn. Linux was prepared. Windows had slept well, got up, and stood in his corner. The seconds checked the weapons, agreed they were acceptible, and gave them to the duellers. The sun rose: two shots were fired, almost simultaneously. There was a winner.

The pain was unbearable. Linux felt the blood mixing with his piss. He could hardly move. Windows had won, and booted. The only consolation was he knew there would be another chance tomorrow; it is hard to kill bits and bytes and, after all, he did lose a couple of times a week. Whenever that stupid user wanted to play games or test his website in that awful web browser...

Re:Risky?

[jdbear]

I've thought about dual booting, but never did. I've got a big system, with one boot disk for Winders, and one for Linux. My /home file system is on a RAID mirror, and I have an external media disk, where I store my audio and movies and such. Five drives in total, and chronically running short on space. I'll be upgrading my media disks again soon, most likely to an external RAID. All that to say, if I'm spreading out file systems to this extent, why boot two OSes from one disk? What would be the point?

I will always encrypt

[Bobb Sledd]

Being in the US, I have become so paranoid now that I encrypt everything with TrueCrypt. Whether it's MP3's, DVDs or pr0n or just simply my web browser cache, it all goes into the encrypted file. Long hard password and keyfiles, and then I also use hidden volumes.

And one big big big reason I use encryption: Usenet. I often use NewsBin to indiscriminately download all the binaries in a given group. I think this is very dangerous. And many times you get some very illegal junk you just don't want lying around -- but I can't get to it for several days to manually filter through it. ISPs get the benefit of being an ISP and not having to filter their caches for content; I do not get that same benefit. If I get caught with something I shouldn't have, it's jail time.

So if it comes up that I had inadvertently downloaded some kiddie pr0n through Usenet newsgroup (which is often mixed in with legitimate stuff), and my machine gets searched, I want some protection. And both: the things I downloaded and the things I have deleted simply CAN NOT be found.

Re:I will always encrypt

[blankoboy]

Nothing a little waterboarding can't fix. Sad but true.

Re:I will always encrypt

[Bobb Sledd]

Er... sorry, I'm not into "waterports."

ZFS Encryption

[FunkyELF]

There was a point where I wanted to build a RAID-5 system and use LUKS / dm-crypt. Seemed like too many layers, too many places for something to go wrong if one phantom bit got flipped. Once ZFS gets encryption I'll build myself a nice new file server.

Re:ZFS Encryption

[Urban Garlic]

Encryption is sort of a weird thing to want for a file server, isn't it?

- File servers tend not to be mobile, so the chances of the disk(s) falling into the wrong hands because of the physical theft of the device is fairly low.
- File servers are up all the time, so the primary means of attack is to compromise a service or application on the already-running server, and gain access to the data with that application or service's privilege level. Encryption does not protect against this.
- When file servers do go down, it's really nice for availability if they can restart autonomously. An encrypted file server would require operator intervention to supply the password.
- File servers might not be able to tolerate the performance penalty of encryption.

I'm a big fan of LUKS/dm-crypt, I use it on my laptop, but (obviously) I don't see the case for an encrypted file server.

Re:ZFS Encryption

[0x15e]

It may be a fringe use but I can see where it would be useful to have the drives encrypted so that, in case of failure, the drives can be easily disposed of or returned to the manufacturer without any privacy concerns.

Re:ZFS Encryption

[Sloppy]

File servers might not be able to tolerate the performance penalty of encryption.

Huh. I guess different people have seen different things, but in my experience, fileservers tend to have underworked CPUs. And it just becomes more extreme ever year, as CPUs double in speed more frequently than I/O devices do.

Respectfully disagree.

[seeker_1us]

The final excuse is "encryption slows the computer down too much." Whether this is true or an excuse, depends upon the user's circumstances and need for security.

a Mac version

[wiredog]

That's already built in to the Mac OS, as it should be. Just use FileVault.

Re:a Mac version

[yabos]

That's only the home folder.

Re:a Mac version

[nunofgs]

Except File Vault is known for mysteriously making your files disappear and it also does NOT provide plausible deniability security.

Oh, and you can't use File Vault to encrypt pen drives, etc.

Re:a Mac version

[fluffykitty1234]

With the disk manager you can create an encrypted disk image. Truecrypt is still better for various reason, like the hidden volumes so it's a welcome change.

Anyone using this on their Mac might want to make sure your swap is also encrypted.

Re:a Mac version

[MrTheBunny]

FileVault is not useful if, like me, you use both Macs and Windows PCs (Home and Work laptops respectively...) and would like to be able to read the same encrypted drive on both machines. And I've had a lot of warnings about losing your data when using FileVault. I'm not the one who's going to take chances on that.

Ooooopsss

[ClooD]

Where is the "I lost my hard drive password" link?

missing file

[sciguy125]

I tried to compile it, but it's missing TravelerDiskWizard.h. I was really looking forward to playing with this thing...

Re:download link NOT

[treak007]

If you'd take a moment and actually LOOK at their Sourceforge entry, you'd not have posted this If YOU would have taken a moment to actually look at their Sourceforge page, you would realize the page also includes the details of the 5.0 release and in fact has answers to some of the questions that are being asked in this thread.

Performance?

[Anonymous Coward]

Hi, this might be a non-issue in the era of fast personal computing, but how slow does the system become in comparison to one without disk encryption? I'd love to do this on my laptop, but I don't want to do it if it's at the expense of major performance issues. It's a core 2 duo with 1 gig RAM, and I think a 5400 RPM drive, so with that in mind, how much of a performance hit are we talking?

Re:Performance?

[jrwr00]

This should be Known

My system is a AMD x2 64 (Black Ed / 3Ghz) Running WinXP Pro SP2 with 2gb of ram

Converted A 2 Hour dvd before encryption, and a did it again after

Before: 1 hour 15min 21Sec
After: 1 hour 16min 39Sec

Converted to XVid with MEncoder

No real slowdowns here, All i could see is it was using my other core a little bit more (like 4%)

Recovery CD

[MT628496]

I'm not sure whether I like the idea of encrypting my entire disk. I don't really like the idea of not being able to boot a live CD to fix something should the need arise. Unless I'm misunderstanding the features, it won't be possible.

I know it doesn't happen often, but there is not anyone here that hasn't at least once screwed up something on his system and needed to boot a livecd to fix a configuration file. With total disk encryption, what do you do? You're boned, as far as I can see and I don't think that I really like the idea.

As I'm writing this, the thought pops into my head that "you can probably just enter your passphrase from the live environment while trying to mount the filesystem". Is this how things actually work? It's a genuine question and I'd appreciate not being modded down for asking it. Of course someone probably will.

Re:Recovery CD

[TyIzaeL]

I was thinking the same thing. Full hard-disk encyption would cause me trouble if I wanted to use something such as BartPE (one of my favorite bootable utilities) to rescue some files or manually restore some registry keys. Maybe the volume can/should be mounted like a TrueCypt file when it is not loaded as the system drive.

Re:Recovery CD

[Armando_Mcgillicutty]

I'm not sure whether I would like software that claimed to encrypt my drive, but simply allowed anyone with a live CD to boot and access my data. I should hope it's not possible, if it is, they need to go back and start over.

Re:Recovery CD

[minion]

I'm not sure whether I like the idea of encrypting my entire disk. I don't really like the idea of not being able to boot a live CD to fix something should the need arise. Unless I'm misunderstanding the features, it won't be possible.
 
I think TrueCrypt is awesome for Windows, especially now that it has whole disk encryption. But, I do not use TrueCrypt for anything Linux based.
 
I use LUKS/dm-crypt. I'm sure if you google for it, there is some info on how to do this, but I encrypted my root partition, and modified 'mkinitrd' so it included the necessary things to prompt for password, de-crypt and mount my encrypted volume.
 
Now my Linux install is encrypted (all but the /boot partition, because initrd needs to be unencrypted). But, since I'm using dm-crypt, I can boot with things like Knoppix and view my files should SHTF.
 
M.

Re:Recovery CD

[Xenoflargactian]

TrueCrypt requires that you burn a Rescue Disk before encrypting your boot partition. It saves a 2-meg ISO to 'My Documents' and gives you links to free burning software. It won't let you proceed without the burned CD in the drive. The rescue disk can be used to restore the boot loader (which has the password-encrypted keys, etc) in case of corruption, but it also has a 'Decrypt entire disk now' option. If you need to boot from a BartPE, you can decrypt your whole disk, then boot from the BartPE.

They've really thought this through. I've gotta hand it to the people at Truecrypt.org. I'm impressed, especially considering this is the first release of their whole disk encryption product.

Re:Recovery CD

[Anonymous Coward]

The whole disk encryption process requires the creation of a recovery CD that can be used to decrypt the drive in the event of drive problems. In XP, I haven't actually found a way to skip this recovery CD feature.

Re:Recovery CD

[Anonymous Coward]

you could decrypt the whole disk (yes it's an option from the boot cd), then boot your rescue cd, then reencrypt the volume? I saw the options when I used it last night to encrypt my home workstation (at least one of them...)

Re:if truecrypt.org is still down

[compro01]

i find that statement awfully funny, as the download link then downloads it from to http://truecrypt.sourceforce.net/

Hibernate? And Error: Insufficient Memory

[paulhar]

The documentation that comes with the system encryption is sparse. I ran through the tests on my RAID-0 laptop and at boot time I get "ERROR: Insufficient memory" (I've got 2GB... and a 64 bit CPU) so it failed.
Additionally the documentation is very sparse when it comes to features like Windows Hibernation; it implies in the docs that it disables hibernation but who knows :-/

Forums are down so can't see the rest of the users screaming (assuming they can boot, of course...)

Re:Hibernate? And Error: Insufficient Memory

[Cement]

Actually, the docs are pretty clear about this (from http://www.truecrypt.org/docs/hibernation-mode.php): "Note: If your system partition/drive is encrypted by TrueCrypt, the TrueCrypt driver automatically prevents Windows from hibernating the computer (for information on how to encrypt the system partition/drive, see the chapter System Encryption)."

Re:Hibernate? And Error: Insufficient Memory

[Anonymous Coward]

I have the same thing happen on my compaq v6000z laptop with a 80 GB hdd and 2GB of ram with a Turion64 x2 processor

Why no Windows 2000 support

[mikapc]

It would be nice if they added windows 2000 support for encrypting the entire drive. I don't understand why truecrypt supports windows xp but not windows 2000 as they are very similar kernels. Anyone know anything about this?

Important because Windows litters data

[RenHoek]

This is very important because Windows puts data everywhere. In pagefiles, in the registry, in the NFS journaling information, in history lists, in the prefetch profiles of executables..

The list goes on and on.

Most of these files are in the Windows main directories and cannot be moved off to a drive that you mount when the system is done booting.

Whole disk encryption avoids all this trouble and is thus a lot better for all non-expert security users.

Not sure it matters

[PRMan]

Hmm, maybe you should have thought about that before making a public, written confession... ;)

Re:Not sure it matters

[Bobb Sledd]

What can I say. I needed the karma.

My use of Truecrypt

[Anonymous Coward]

I've been using TC for years and one of the best uses is for my removeable HD backups.
I have a 500GB external USB drive. I installed TC in traveler mode on it which uses autorun prompting for the passphrase to mount the encrypted drives it contains. I then run a few bat files that basically consist of robocopy scripts to backup various network shares and local files to the mounted volumes. I unmount the encrypted partitions and set the portable drive back on the shelf until the next week

My thinking is now I have backups of my important data and the data is encrypted. If the drive is stolen or if it fails and I have to send it back to Western Digital, I know my data is safe. Using TrueCrypt allows "portability" and flexibility. I can mount this portable drive and its encrypted volumes on any Windows or Linux machine using local versions of truecrypt. For my Truecrypt volumes that are less than 9GB, I can burn the "volume" file to a DVD and have another complete backup of the entire volume that I can mount with any instance of Truecrypt on any computer. TrueCrypt truely is amazingly flexible. I am very interested in trying the new features.

LUKS

[nguy]

Linux is getting a standard for encrypted partitions called LUKS. I would expect that in the next major release of Ubuntu, SuSE, etc. you can plug in an encrypted USB drive and it just works.

LUKS? Ubuntu?

[nguy]

What's the relationship between TrueCrypt and LUKS? LUKS seems to be the new standard for encrypted partitions under Linux.

Also, TrueCrypt is open source and seems quite mature; why isn't it part of Ubuntu? Are there license issues? Technical issues? Political issues?

Re:LUKS? Ubuntu?

[N7DR]

Also, TrueCrypt is open source and seems quite mature; why isn't it part of Ubuntu?

Why do you think it's not part of Ubuntu? According to synaptic, it's part of the "Base System" in my 64-bit Kubuntu gutsy installation.

Re:LUKS? Ubuntu?

[TheLink]

It's not part of Ubuntu in a useful way.

Here's what it takes for it to be a real part of Ubuntu:

On a default install, EVERYONE should get a truecrypt container file that's of a fair size (maybe relative to the HDD size with a max limit, and min limit - unless the drive is really too small then it's not installed), with a random password.

Now truecrypt becomes far far more useful to everyone, because everyone now has plausible deniability.

All that marketing bullshit about hidden partition vs dummy partition is stupid, if the default install doesn't come with container files, and you create some, that bumps you up the list of "people to waterboard" or "ask nicely for all their passphrases".

Whereas if the default install came with encrypted container files, they can't harass every ubuntu user.

Naturally it has to be done in a way so that:
1) The container file access times and modified times aren't changed.
2) The container file(s) or their contents are never backed up automatically by the system or indexed etc. Otherwise the risk of people finding out that you are using crypto goes up - they just have to get hold of your backups and do some comparisons and then your quality of life goes down.
3) Using the container file is easy.

If people want to backup the container or files from the container, they must really use their brains otherwise they might have problems later on...

(I submitted this suggestion to ubuntu some time ago, not sure if they will do it - Ubuntu might get banned in some countries, or at least the default edition with crypto might get banned).

Anyway enough for now - bedtime...

Re:LUKS? Ubuntu?

[nguy]

I don't see it.

$ apt-cache search truecrypt
$

http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=truecrypt&searchmode=filelist&case=insensitive&version=gutsy&arch=i386

What's the package called?

Time Machine

[Valdrax]

Yes, as the article clearly says.

More importantly, is it compatible with Time Machine? I'd love to not have my backup drive be a security risk.

DriveLock: Full Discosure Required

[Anonymous Psychopath]

It is well known that DriveLock can be broken. It is also well-known that breaking it is beyond the capability of 99.9% of laptop thieves. This is a fair risk/reward trade-off for all but the most sensitive data. I don't think it's well-known at all. DriveLock certainly doesn't say so on their web page. Every DriveLock user should be presented with, at a minimum, a click-through message stating that there are well-known methods of defeating DriveLock that are more practical than those required to defeat strong encryption, and that the methods used by DriveLock are only designed to prevent your data from being disclosed in the event of a casual theft aimed at your hardware, and not at your data. Not buried deep in the EULA, either.

As referenced in another reply, http://technocrat.net/d/2007/3/9/15796this user was obviously not aware that DriveLock can be very easily bypassed if the persons taking your hardware have access to a clean-room facility.

Lastly, your definition of sensitive data might be different than mine. Without full disclosure, how can I be expected to make an informed decision about the strength of protection required?

Re:DriveLock: Full Discosure Required

[Lord Ender]

When I say "well known," I mean "well known among infosec professionals," which would be the people making decisions about these things at most companies.

On performance & chained bootloading...

[DigitAl56K]

I would like to see a performance comparison. Contrary to what you might believe (most products being based on AES, at least by default), there seems to be quite some scope for optimization. Here is one online comparison.

I'd like to see someone benchmark TC FDE versus something like Compusec, which seems to be leading in the aforementioned comparison.

Additionally, I'll comment that this does not take away "the final excuse". There is way too much software jumping all over the bootloader these days. I use a version management product called Rollback RX, for example, that lets you roll your drive (as Windows sees it) back in time to previous snapshots, and I'm pretty sure that installing TC FDE on this drive would kill Rollback.

It's about time that there was some standard for chaining bootloader software so that I didn't have to choose one or the other.

TrueCrypt was already out for mac

[Gm4n]

This seems to have been overlooked by the writers of the article and by others, but truecrypt was already supported on OSX: http://www.osxcrypt.org/ My question is which of the two is preferable.

Re:TrueCrypt was already out for mac

[LionMage]

Well, a quick glance at the OSXCrypt site reveals that these folks are aware of TrueCrypt 5.0, and they provide a brief comparison of the two:

Some little difference in TC and OSXCrypt must be taken in account:

• OSXCrypt is a kernel module, and not based on MacFuse. That gives the project a really different approach.
• The OSXCrypt Framework is based on the paradigm of implementing a modular kernel module that can be used with OTHER cyphers. Implementing dm-cryppt on mac, for example, is now trivially easy.
• The GUI is coming even here, thanks to the efforts of a volunteer.

So the decision of which to use is probably a matter of which porting approach you find more palatable. Sounds as though they each have strengths and weaknesses, and the GUI currently only exists on TrueCrypt currently (based on my reading).

Ummmm, no

[Sycraft-fu]

I have some more big objections:

1) Performance. Encryption isn't free, it takes a lot of computation. You can pretty heavily load down a CPU doing a lot of disk access on an encrypted volume, and there's lots of situations where that's not ok. For example I do audio/video editing and that involves lots of large files (like multiple 15gig video files) as well as processor intensive effects. Adding crypto to that would really drag down performance, and potentially make much of the things you can do realtime have to be done offline.

2) Data recovery. What happens in the event of a partial drive failure? We have this happen all too often at work. Something goes nuts on a drive and it isn't readable by normal means. However, we can get it to work with recovery tools and get some or all of the data back. What do you do when it is encrypted? Does Truecrypt provide the tools to mount the encrypted volume from the recovery software?

And please, don't start with the "Well they should have had a backup!" crap. Of course they should have, but they didn't. We live in a real world, not an ideal one, and tech support has to support the real one.

3) Stupid user syndrome. You telling me you've never had a user forget their password? Ever? Well we do here, again all too often. So what happens then? Truecrypt is truly secure symmetric cryptography, meaning that there are no backdoors, there are no hidden override keys, etc. If the user forgets their password that's it, you are done. Unless it is a simple enough password to crack with a dictionary attack or the like (in which case the crypto is kinda useless) you are fucked. There is no recovery.

So it is cool and all, and I certainly can see uses for it (any system that deals with classified data, for example). However this idea that now everyone should encrypt everything is stupid.

Re:Ummmm, no

[myowntrueself]

And please, don't start with the "Well they should have had a backup!" crap. Of course they should have, but they didn't. We live in a real world, not an ideal one, and tech support has to support the real one.

Duh

'not having backups' is not supportable. End of story.

If they don't have a backup then thats not 'a supported configuration'.

This is the real world, not an ideal one, and tech support can only realistically support that which *is* supportable.

Re:Ummmm, no

[GodKingAmit]

3) Stupid user syndrome. You telling me you've never had a user forget their password? Ever? Well we do here, again all too often. So what happens then? Truecrypt is truly secure symmetric cryptography, meaning that there are no backdoors, there are no hidden override keys, etc. If the user forgets their password that's it, you are done. Unless it is a simple enough password to crack with a dictionary attack or the like (in which case the crypto is kinda useless) you are fucked. There is no recovery. Wrong. You can make a backup of the volume header with a known password and use that to "reset" the password.

Appears that it can

[Fencepost]

I'm not actually using it yet, but two quotes from the "System Encryption" page of the manual:
<blockquote>TrueCrypt can on-the-fly encrypt a system partition or entire system drive, i.e. a partition or drive where Windows is installed and from which it boots (a TrueCrypt-encrypted system drive may also contain non-system partitions, which are encrypted as well).</blockquote>

<blockquote>Note that TrueCrypt can encrypt an existing unencrypted system partition/drive in-place while the operating system is running (while the system is being encrypted, you can use your computer as usual without any restrictions). Likewise, a TrueCrypt-encrypted system partition/drive can be decrypted in-place while the operating system is running. You can interrupt the process of encryption or decryption anytime, leave the partition/drive partially unencrypted, restart or shut down the computer, and then resume the process, which will continue from the point it was stopped.</blockquote>

The thing that I don't see addressed by this is situations where you have separate boot and data drives where information on the data drives is required during system boot but the drive has not been decrypted yet. Not sure if there is (or can be) support for that.

Re:Appears that it can

[imsabbel]

Thats exactly my point:

I installed it, and tried it, but i _cannot_ encrypt my E drive without completely emptying it first.

Re:if truecrypt.org is still down

[Hal_Porter]

I find that statement awfully funny, as the download link then downloads it from to http://truecrypt.sourceforce.net/

Yeah but they add &password=opensesame to end of the URL to make it secure.

Re:if truecrypt.org is still down

[Hal_Porter]

Whenever you see security people saying things like this do the following thought experiment.

HE MAN goes to helpfulmirror.com to download security software. But unbeknownst to HE MAN, SKELETOR actually runs helpfulmirror.com and hosts backdoored versions of the software.

You may need to adapt it, but always think "Am I talking to a helpful stranger or am I talking to SKELETOR pretending to be a helpful stranger"

Re:if truecrypt.org is still down

[base3]

Which was of what use when truecrypt.org was down?

Mod parent down.

[TheLink]

Mod parent down - fake/squat link.

Re:Mod parent down.

[compro01]

whoops. typos are fun. should be sourceforge, not sourceforce. further proof using preview isn't foolproof.

though i wasn't even intending to make it a link.

Re:Mod parent down.

[Anonymous Coward]

I hope you don't take it personally.

If one day I make a typo that links to goatse I hope I get modded down ASAP.

TrueCrypt in Ubuntu?

[Anonymous Coward]

What is the name of the package? In my 64-bit Ubuntu gutsy install, I don't see anything.

Nothing on:
http://packages.ubuntu.com/gutsy/base/

that looks like TrueCrypt either.

I have found TrueCrypt to be 100% reliable.

[Futurepower(R)]

For almost exactly 3 years, I have found TrueCrypt to be 100% reliable. I don't notice any difference in speed between a TrueCrypt encrypted file or partition and a normal NTFS file or partition on Windows XP SP2.

Leaving your computer on? It is easy to dismount a TrueCrypt volume. Just click on the TrueCrypt icon in the system tray, choose which to dismount and click on the dismount button, or choose dismount all. TrueCrypt -d X dismounts volume X from the command line.

The documentation says that it is better to make an encrypted file than make a separate NTFS partition and encrypt the entire partition. The speed seems the same. It is easier to back up the encrypted file on a DVD. Backing up an entire special partition requires the use of backup software like Acronis, which is more steps and requires dealing with the sometimes crazy behavior of Acronis.

Re:I have found TrueCrypt to be 100% reliable.

[jdbear]

Yeah, I've been using Truecrypt for about three years, too. Never had a problem with it. I did lose one password, but that's my fault, not TC's. It wasn't a big deal, since it was a "travel disk" anyway. I just reformatted and set it up with a new password, then reloaded my data. Always keep a backup. :-)

Not Slashdotted

[cicho]

Ladies and gentlement, we present to you... the Iran Effect!

We break our backs cutting six freaking undersea cables, and I swear they're HUGE like this, in as many days, and all you can think is /. effect. Harrupmph.

(Upside: at least nowe we have a bearing on who the authors of TrueCrupt are.)

Re:if truecrypt.org is still down

[Culture20]

This is why HE MAN should always check the digital signature of the downloaded file to make sure it's from MAN AT ARMS, the security software writer (assuming HE MAN has MAN AT ARMS' public key through other means; he should always assume the pubkey found at helpfulmirror.com is SKELETOR's).

Even if HE MAN downloads the software from manatarms.com, he'll need to verify it somehow; SKELETOR might have intercepted the transmission of data and altered it with his evil magic, implanting an ETERNIAN HORSE into CASTLE GRAYSKULL.

Not anytime soon.

[Ayanami Rei]

For whatever reason, the author of TrueCrypt wrote his own implementation of AES. This means even if someone put up the cash to apply for a cert, it'd probably take much longer to get anything other than assurance level 1 than most people are willing to wait.

In any case it costs a lot of money and they only test binaries which makes anything that links into a kernel difficult unless it's only a library core common among implementations which is linked at install time or something.

It's a real pain. :-(

Most people are fine with FIPS-compliant but not listed, and not many government types use anything but windows on laptops, so you're kinda screwed there being one of very few who need it.

Junction points?

[Butterspoon]

Still no option to mount a TrueCrypt volume on an NTFS junction point, alas.

PGPdisk has had this for ages. Means you don't have to expose to all and sundry who can see your machine that another drive has just appeared.

Would very much like to see this in the next version.

TrueCrypt forum down

[Anonymous Coward]

It looks to me as if the forum has been down for a couple of weeks. Are the TrueCrypt users happy? What are their issues?

I have been using TC at work for a while now and think it is a very good piece of software. Thanks guys!

Problem with TrueCrypt 5.0

[abadent]

the Problem i found is:
if you encrypt your Windows System drive / partition
EVERY User on the system is able to decrypt the System partition without entering the Volume password and as any user on the system (administrator, power user, user, ...). if the partition is NOT longer ENCRYPTED every user which has access to the box is able to read every file of the hard drive, not only the files to which his account might have access to.

i personally think this is a big security issue, if you setup an restricted account on your box and leave your unlocked computer alone, everyone is able to permanently decrypt your system drive

Re:Problem with TrueCrypt 5.0

[gnoshi]

So what you are saying is that it is a security risk that all users of the computer need to be able to decrypt the system partition?

If the user doesn't have the password for the system partition, they can not boot the system at all. That isn't a security risk.

If the complaint is that when the system is running the drive is decrypted, then I think you misunderstand disk encryption. I mean, for a non-system partition it would be nice to be able to limit which processes can access the partition, but for a system partition that is likely a bit problematic. That, and multiple users on the same system logged on simultaneously will be sharing a kernel anyway, so longing to specific processes wouldn't help.

Fundamentally, what it comes down to is this: Yes, when the partition is mounted it gets decrypted as required by anyone who has access to the partition.

Re:Problem with TrueCrypt 5.0

[abadent]

this problem affects MS windows versions (xp, 2003)
if an user is logged in as an not admin user (power user, user) he is able to decrypt the encrypted drive/partition without entering the appropriate password, if some let his WS/Laptop unlocked every person which has access to the "box" is able to decrypt the system partition (with the currently logged on user, even an resticted account), reboot the machine and boot maybe knoppix and readout all data stored on the system drive

the problem does not affect Windows Vista with enabled UAC

i think the problem should be solved by requiring admin rights and asking for the volume password

regards abadent

WARNING! Don't use it on a untrusted system

[Anonymous Coward]

I found a vulnerability which allow a malicious running in the context of an unprivileged user to crash the system and even potentially gain SYSTEM / root privileges. I already found it in TrueCrypt 4.3 and reported it, yet it didn't get fixed. I then tried to publish it in the forums, which was already down at this time. I recently (some minutes ago) reported this vulnerability on version 5.0 again, and hopefully they'll adopt my suggested fix. Until then, sadly I can only recommend you to not use TrueCrypt, since there's no workaround for this problem expect for patching the code and recompiling.

I hope you understand that I'm not going to publish the vulnerability here until the guys got the chance to fix the issue, even though I must admit that my claims sound a bit unsupported.

FreeOTFE is not much better, but the most serious vulnerability I found there only allows to permanently block the system with non-terminatable processes. CrossCrypt didn't work for me, but you may try your luck there as well. PGP Desktop Workstation is also OK so far (version 6.5.3 fixed all vulnerabilities I found in there). For Windows users, there's also http://freed0m.org/?index=dcrypt, which claims to be compatbile with TrueCrypt 4.3a. I didn't test its security yet, and the pre-boot stuff didn't work on my test machine, but if you have an old TrueCrypt container it might be a good alternative.

Re:OT -- what's the state of flash encryption0251?

[Anonymous Coward]

I have a usb stick with Elcomsoft System Recovery Pro that I use to hack Active Directory accounts on windows 2003 domain controlers. Can I use this new version of truecrypt to encrypt the entire drive so no one can figure out what is on it if I get caught? How much overhead does the encryption have? Will it slow down the time it takes to crack NTLMv2?

This breaks remote access

[Anonymous Coward]

I don't like anything that requires a password to be entered before the network is configured. If gaining this additional security means that I can't reboot the machine remotely, I don't want it. I shouldn't have to be physically present in order to get networking up and running to enable remote access.

This is the same reason I don't use a BIOS startup password (of course, BIOS passwd is useless anyway), nor Windows XP's syskey setup (Start > Run > syskey).

Purchase Support for Enterprises?

[Anonymous Coward]

Does anyone know of anyone selling truecrypt support for enterprises that are too afraid to roll open source without it?

code audit by professionals

[unger]

afaik, the truecrypt code has never been audited for security issues by professional cryptographers. does anyone know if i'm mistaken?

if the code has never been audited doesn't it seem a bit irresponsible to recommend truecrypt?

Re:if truecrypt.org is still down

[Anonymous Coward]

Whenever you see security people saying things like this do the following thought experiment.

HE MAN goes to helpfulmirror.com to download security software. But unbeknownst to HE MAN, SKELETOR actually runs helpfulmirror.com and hosts backdoored versions of the software.

You may need to adapt it, but always think "Am I talking to a helpful stranger or am I talking to SKELETOR pretending to be a helpful stranger"

Holy fuck you're stupid! Do you actually say that He Man shit out-loud around co-workers? Did you even notice that the URL your are complaining about points to SOURCEFORGE?

(Mods: Gimme a double-scoop of "Flamebait" with some "Troll" sprinkled on top)

No it doesn't... not yet anyway

[VokinLoksar]

I spent this evening trying to get it to encrypt a clean install of Windows XP SP2.

First, there is a problem with creating a recovery CD. If you try to burn the image TC gives you with Alcohol 120% or PowerISO, it will not work. Alcohol burns it, but validation fails. PowerISO doesn't even want to burn that image. You have to use InfraRecorder that their website links to. I have no idea what they are doing with that image, but there is no reason why I should have to go out and get some other piece of software to do the same thing as Alcohol or PowerISO.

That's not the major problem though. So far, I could not encrypt my drive. The process goes to about 21% then dies with a "Data error (cyclic redundancy check)." Very descriptive, as you can tell. I just finished running checkdisk to see if this could be caused by bad disk sectors - nope. The hard drive is perfectly fine. I'm not the only one having the same problem. There are a number of people on wilderssecurity forums that have the same issue.

I have that 21% of the disk encrypted, and pre-boot authentication works fine... now if it could only work for the entire disk. The other thing I found out is that apparently encrypting your system drive will disable hibernation. Not a great thing for my laptop (Fujitsu P7010, in case you were interested). I could live without hibernation for a while, assuming that it will come eventually in a later release. The encryption problem is another story.

Hard drives can be unlocked for $49.95

[AviN]

The following service permits you to unlock a password protected hard drive for $49.95:

http://www.hdd-tools.com/products/rrs/

I doubt 99.9% of laptop thieves are incapable of finding and using this service.

Re:Hard drives can be unlocked for $49.95

[Lord Ender]

If that product works at all, it only works on drives which have serious design flaws. Not all drives have these design flaws (as is stated on their site).

Re:Hard drives can be unlocked for $49.95

[AviN]

Where on the AFF website do they say some hard drives do not have these design flaws?

Re:Hard drives can be unlocked for $49.95

[Lord Ender]

"Unfortunately, these drives cannot be unlocked by a software since there are lot of security measures implemented by these manufacturers. These drives can be unlocked only in a lab by performing some soldering work and using external devices."

http://www.hddunlock.com/support/faq/

Re:Hard drives can be unlocked for $49.95

[AviN]

I overlooked that. Thanks for providing the reference.

Truecrypt MAC seem to be destroying user's volumes

[Anonymous Coward]

Ok, long story made short: TC on MAC was released more than a month ago by some guys (Italians I think) after two years of waiting for the MAC version.

The project for the fork is named OSXCrypt (www.osxcrypt.org) and aims to create a multi-cypher Framework for MacOs. It was funded by netizens and released a functioning copy via command line as a Kernel Module, instead of the user-space MACFuse one of TreCrypt. Nothing so different, but maybe faster and more steady...
It's sleek and rock solid, despite the statements of being beta, and I'm telling this after a month of INTENSE use in our firm.

After that the TrueCrypt team HAD to do something and released the new MAC version, but Forums have been taken offline and a lot of people is reporting volume corruption and lost data.

Sarcastic as it may seem users are using OSXCrypt site as repository for the problems, since here is NO WAY of contacting Truecrypt Team.

I get the strong feeling that TrueCrypt 5.0 is sort of an unfinished product that has been delivered to "silence" the other one. I may be in error (and probably I am) and I really think the developers of TrueCrypt are a real divinity of the Web, but for the time on my precious data on MAC will use OSXCrypt, waiting for a next release of TrueCrypt or, at least, some sort of Forum reopening and/or support.

Don't take me wrong, I'm really happy of TrueCrypt and of the developers. Really.

The comments of people losing data are here:

http://www.osxcrypt.org/2008/02/06/truecrypt-50-is-out/

and OSXCrypt can be downloaded here:

http://www.osxcrypt.org/download

Hope this may help...

Alternative to compusec

[Przemo-c]

This is the first free alternative to CompuSec as for encrypting your system drive. But one thing is pretty strange to me... if it's possible to encrypt the system drive while the system is working why isn't it possible to encrypt other partitions /discs that way without wipeing them out? I havent tried truecrypt under linux (the other drive) but my friend told me that i can practicly encrypt whole drive (except of /boot) i wonder if i'll be able to use the first drive under linux too. With compusec i've gone through partialy damadged disk ... half encrypted damadgetd boot loader etc and as long I had password and encryption keys (or in event of partial enctyption rememberd how far has it progressed) i was able to repair or recover my data. i have to read about some procedures of recovery in such cases on truecrypt... wich has way better documentation than compusec ;]