Posted
by
CmdrTacoon Wednesday February 06, 2008 @09:52AM
from the wear-a-condom-people dept.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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)

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/15796 [technocrat.net]this 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?

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?

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.

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.

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

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

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.

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

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 [truecrypt.org]

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.

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 jus

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.

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 enou

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

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

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

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.

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.

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!

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.

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.

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.

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 g

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.

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.

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.

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

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 vo

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.

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

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

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

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"

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.

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 i