Slashdot Mirror

Google: windows encrypted drive + "I'm feeling lucky".

Here's what I got:

http://www.truecrypt.org/

I'm OK with "Ask Slashdot" being used to gather the collective experience of the techies that like to hang out off-hours here at /. - but.. this?!?

Something that could be addressed by a moment or two spent at Google or even (god's sake) Bing is a WASTE OF HITS. But maybe that's the plan - get droves of angry techies to bitch about the lameness of the stories, delivering ad impressions?

Crazy like a fox?

I'm on to you, Cmdr Taco, if that is your real name!

Full Disk Encryption

All computers with sensitive information should have partitions entirely encrypted with TrueCrypt. Then a stolen computer would yield no information.

TrueCrypt can encrypt even the OS partition.

From Cornell's weak excuses, June 2009 Data Theft - Frequently Asked Questions, a quote: "In June, 2009, a Cornell-owned computer that contained a large amount of administrative data was stolen. Our review of a current backup of the files on the system revealed that confidential personal data for about 45,000 current and former staff and students, and some dependents, had been present."

TrueCrypt is so fast that there is no noticeable change in speed of the computer.

TrueCrypt

If you're really, really serious about these things, maybe you could work super-diligently to prevent leaving any clues as to that hidden volume's existence.. odds are something's going to bite you in the behind somewhere though.

You mean something like this, perhaps?

Sorry, I forgot to add a reference for the quote in bold. Here it is:

http://www.truecrypt.org/docs/?s=hidden-volume-precautions

Wow, the quality of Slashdot has really been going down lately. Now any random fraud can submit his misleading material and it gets accepted to front page just because it sounds interesting? Is this actually tabloid or serious news for nerds who understand what the talk about?

In short, this is yet another lame attempt to make money by posting bogus claims about a popular product.

First, hidden volumes are the only kind of steganography that TrueCrypt offers. Second, if you read the TrueCrypt documentation, you'll learn the following about hidden volumes vs. dynamic:

On Linux or Mac OS X, if you intend to create a hidden volume within a file-hosted TrueCrypt volume, make sure that the volume is not sparse-file-hosted (the Windows version of TrueCrypt verifies this and disallows creation of hidden volumes within sparse files).

Furthermore, when I try to create a dynamic TrueCrypt volume, TrueCrypt displays a big warning saying that dynamic volumes are insecure. That's right. Insecure.

So again, I demote this story as total and utter bogus motivated by the vision commercial gain.

I thought one feature of TrueCrypt was the ability to have two passwords. One password unlocks your "non-secret" data. The other password unlocks your "secret" data in a hidden volume.

http://www.truecrypt.org/docs/plausible-deniability

The point is both sets of data are stored in one big binary blob. It'll all look like one big fat encrypted mess. In fact, if you are not careful, your non-secret data can overrun your secret data.

To get around this "randomness" problem, after creating your non-secret partition, fill the partition completely with something (copy a few public domain books over and over until the partition is full). All the "randomness" will be gone with encrypted data. Then delete everything and put back in just the smallest amount of non-secret data you need to store in order to appear legit. The "randomness" is still there, as only the FAT entries are deleted, but all the encrypted data is still filling up that whole binary blob.

Now, create your secret partition and use it. Be sure to use it just short of the non-secret data's amount (as they fill from the opposite end), otherwise your non-secret partition will be corrupted.

This link helps with the graphics:
http://www.truecrypt.org/docs/hidden-volume

The one downside is that the non-secret side, if it fills up with too much data, will override your secret side. That's why your have backups and this is just for transport anyway, right?

I thought one feature of TrueCrypt was the ability to have two passwords. One password unlocks your "non-secret" data. The other password unlocks your "secret" data in a hidden volume.

http://www.truecrypt.org/docs/plausible-deniability

The point is both sets of data are stored in one big binary blob. It'll all look like one big fat encrypted mess. In fact, if you are not careful, your non-secret data can overrun your secret data.

To get around this "randomness" problem, after creating your non-secret partition, fill the partition completely with something (copy a few public domain books over and over until the partition is full). All the "randomness" will be gone with encrypted data. Then delete everything and put back in just the smallest amount of non-secret data you need to store in order to appear legit. The "randomness" is still there, as only the FAT entries are deleted, but all the encrypted data is still filling up that whole binary blob.

Now, create your secret partition and use it. Be sure to use it just short of the non-secret data's amount (as they fill from the opposite end), otherwise your non-secret partition will be corrupted.

This link helps with the graphics:
http://www.truecrypt.org/docs/hidden-volume

The one downside is that the non-secret side, if it fills up with too much data, will override your secret side. That's why your have backups and this is just for transport anyway, right?

Disclosure to a 3rd party is suicide as your atty-client confidentiality could be lost (what happens if the 3rd party gets subpoenas?). Losing data is suicide because it shows a lack of due diligence. Use paper. It works. or burn to 2X archival CDR and THEN use paper. whatever floats your boat.

I think that might be resolved by encryption, like plausible deniability.
Then again, if client/attorney relationship is a problem, and the client is paranoid, have him encrypt the documentation himself with his public key, send it to you encrypted further with your public key, and store it somewhere. This way, the only way to access those backups will be by asking both for the private keys, and no one can tamper with the actual content indipendently of the other.

http://en.wikipedia.org/wiki/Deniable_encryption
http://www.truecrypt.org/docs/?s=plausible-deniability

What is wrong with the TrueCrypt license?

Quoting from the section about making your own modifications to TrueCrypt and calling it by a different name: "Note: TrueCrypt and the TrueCrypt logos are trademarks of the TrueCrypt Foundation. The goal is not to monetize the name or the product, but to protect the reputation of TrueCrypt, and to prevent support issues and other kinds of issues that might arise from the existence of similar products with the same or similar name. Even though TrueCrypt and the TrueCrypt logos are trademarks, TrueCrypt is and will remain open-source and free software."

Basically, the license says, "You can do anything you like except 1) engage in fraud using the TrueCrypt name, and 2) make TrueCrypt code non-free."

If there is anything objectionable, I don't see it.

Oh good, so now I need a special driver with which to decrypt my hard drive, so it won't work with the Linux or BSD kernels.

I would buy such a product (encrypted HDD or encrypted SATA/SAS [RAID] controller) if it were completely open (as in GPL-compatible) firmware, open specs, and solid assurances of fair play with respect to patents, etc. Especially if the encryption/decryption is performed on a dedicated chip so as to keep resource costs from growing.

... and battery back-up (like other hw RAID controllers), confirmed writes via journal for data integrity, ... hmm, I have some high demands. Maybe I'll just stick with TrueCrypt.

Do you mean something like this?

http://www.truecrypt.org/docs/?s=plausible-deniability

Which is many encryption products implement plausible deniability (the "hidden" operating system feature in TrueCrypt, for example). Re-enable your 5th amendment rights by "unlocking" the public operating system for all to see while remaining silent about any hidden partition. In such a setup the "hidden" operating system should only be accessed for the necessary operations; all other business should be conducted on the public operating system in order to preserve plausibility (i.e. having a public operating system that is clean and never used might lead to further questions because that is less plausible, particularly if the laptop has obviously been used with worn keys and other physical evidence). The use of our knowledge and wits is the last defense that we have against those who seek to overpower our individual freedoms.

I'm not using TrueCrypt yet, but I've been looking into it for a potential future netbook purchase.

It seems that you can have a secondary key (of sorts). You encrypt the drive and backup the header, which will be encrypted with your password. Then you can supply the machine to the user and have them create a new password. Then if they forget their password you can repair the header with your copy. You can find this in the TrueCrypt FAQ (search for the word enterprise)

Which works great until they are out in the field and don't have the rescue disk. And even if they did, do you really think you can talk them through the process of recovery? Would you even want to try? Much better to use a product that supports remote password resets by a challenge-reponse setup.

Read the license again.

You may copy and/or distribute This Product, provided that You do not modify This Product (for terms and conditions for copying and distribution of modified versions of This Product, see Chapter III) and provided that You do not include This Product in another product forming Your Product (except as permitted under Chapter III)

Truecrypt is not free software and security problems have been noted in the past. Only free software should be trusted.

Proceed with caution!

Just because you're using AES-256 doesn't mean that you are using a FIPS 140-2 certified implementation! In fact, according to TrueCrypt's documentation, they do not have such a certification. http://www.truecrypt.org/docs/?s=compliance-with-standards

The means that if you are encrypting data for the purposes of meeting a state or federal regulatory requirement, Truecrypt may not be sufficient. I know that the current interpretation of the NY Security Breach Notification law is that if it isn't FIPS 140-2 certified, it isn't encrypted.

You (I mean the general "you") need to be careful and seriously analyze who you trust your data with. Nobody knows who is behind TrueCrypt and they have a reputation for stifling criticism and dissent. That makes me leery, as even subtle flaws in an encryption system can render the system useless.

I would be hesitant to protect information for which I have a fiduciary responsibility in their hands.

I -love- truecrypt but I wouldn't suggest it for a whole enterprise without being able to answer the question "How do I recover the key to this workstation when the employee dies unexpectedly of a heart attack?".

TrueCrypt's FAQ discusses this. See the question beginning "We use TrueCrypt in a corporate..."

I'm not using TrueCrypt yet, but I've been looking into it for a potential future netbook purchase.

It seems that you can have a secondary key (of sorts). You encrypt the drive and backup the header, which will be encrypted with your password. Then you can supply the machine to the user and have them create a new password. Then if they forget their password you can repair the header with your copy. You can find this in the TrueCrypt FAQ (search for the word enterprise)

I've used both truecrypt and compusec, and for a corporate environment only compusec is acceptable. Truecrypt does not provide a master password you can use to quickly reset a password when the user forgets.

That's not true. Restoring access to a container or partition with a forgotten password is quite easy if you do one extra step when creating the container. From their FAQ:

Q: We use TrueCrypt in a corporate/enterprise environment. Is there a way for an administrator to reset a volume password or pre-boot authentication password when a user forgets it (or loses a keyfile)?

A: Yes. Note that there is no "back door" implemented in TrueCrypt. However, there is a way to "reset" volume passwords/keyfiles and pre-boot authentication passwords. After you create a volume, back up its header to a file (select Tools -> Backup Volume Header) before you allow a non-admin user to use the volume. Note that the volume header (which is encrypted with a header key derived from a password/keyfile) contains the master key with which the volume is encrypted. Then ask the user to choose a password, and set it for him/her (Volumes -> Change Volume Password); or generate a user keyfile for him/her. Then you can allow the user to use the volume and to change the password/keyfiles without your assistance/permission. In case he/she forgets his/her password or loses his/her keyfile, you can "reset" the volume password/keyfiles to your original admin password/keyfiles by restoring the volume header from the backup file (Tools -> Restore Volume Header).

Similarly, you can reset a pre-boot authentication password. To create a backup of the master key data (that will be stored on a TrueCrypt Rescue Disk and encrypted with your administrator password), select 'System' > 'Create Rescue Disk'. To set a user pre-boot authentication password, select 'System' > 'Change Password'. To restore your administrator password, boot the TrueCrypt Rescue Disk, select 'Repair Options' > 'Restore key data' and enter your administrator password.
Note: It is not required to burn each TrueCrypt Rescue Disk ISO image to a CD/DVD. You can maintain a central repository of ISO images for all workstations (rather than a repository of CDs/DVDs). For more information see the section Command Line Usage (option /noisocheck).

The actual FAQ has many of those terms linked to other help files for more info: http://www.truecrypt.org/faq.php

They don't mention it explicitly, but this process does not require any computation/decryption on the actual data. It will be very fast to execute no matter how large the container is.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...

I think you're going to find most people advising you to choose TrueCrypt which boasts:

• Creates a virtual encrypted disk within a file and mounts it as a real disk.
• Encrypts an entire partition or storage device such as USB flash drive or hard drive.
• Encrypts a partition or drive where Windows is installed (pre-boot authentication).
• Encryption is automatic, real-time (on-the-fly) and transparent.
• Provides two levels of plausible deniability , in case an adversary forces you to reveal the password: 1) Hidden volume (steganography) and hidden operating system . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.

... but i am concerned about overhead and speed penalties.

Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.

I wouldn't recommend waiting that long, however.

Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.

I do not know for certain but I do not believe there is a painless push-across-the-network way to do this ... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.

I don't see how this standard can receive wide acceptance. It seems to be designed only for very unusual requirements.

First, if the main CPU doesn't do the encryption, another CPU of equal speed must be provided. Otherwise the encryption and decryption will be very slow. That means double the power and heat dissipation requirement.

Second, read this from the ComputerWorld article: "When a USB drive is unplugged, or when a laptop is powered down, or when an administrator pulls a drive from a server, it can't be brought back up and read without first giving a cryptographically-strong password. If you don't have that, it's a brick. You can't even sell it on eBay."

Does that mean a lost password causes a complete loss of hardware?

TrueCrypt is FAST. It is FREE. It is OPEN SOURCE.

Would you trust a hidden encryption system? The U.S. government has established that it can act in secret, and put executives in prison if they don't cooperate. How would you establish that there is no hidden system to decrypt the data?

Third, read the specifications. They are poorly written.

"... the key is never visible to the CPU at any time..."

If the CPU is used to decrypt, the key must be available to the CPU. Anything that happens in the CPU must use the registers of the CPU.

It can be arranged that the password is never seen by the main CPU, but that requires another CPU, which may also have vulnerability.

At present, it looks as though TrueCrypt is very attractive. It's open source, a necessary quality for encryption methods. Hardware-assisted encryption would not be open source. TrueCrypt can and does use methods of preventing boot-time attacks.

From the TrueCrypt documentation: "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)."

That means that TrueCrypt system partition encryption is available to existing systems, a huge advantage, since any organization has existing systems.

All TCHunt does is look for random data. If you append 100MB of /dev/urandom to a file and run TCHunt, it will "recognise" it as a TrueCrypt volume.

This is not a secret. This is how encryption works. Obfuscating your data inside a apparently plaintext structured format is called stenanography and is another subject entirely.

The changelog is here

Discussions on using CVS and other version control are scattered throughout the forums without apparent quoshing by the admins. Yes, old versions of the source are not available - unless you already downloaded them, of course.

The MD5 hashes changing for the installer was just that - they rebuilt the installers with some of the new setup (like offering the option to disable the pagefile) from the version 6 installers, but the binaries inside remained identical. Doing this is rather poor practice because it raises this sort of question, but hey, you trusted the first file signed with their PGP key, why not the second? The TCHunt guys have an archive of old TrueCrypt versions, but they won't let you download them now for bandwidth reasons ; it might be illuminating to pick through the various MD5 versions and compare the actual binaries installed.

If someone is concerned about back doors, they can audit the code, and build it themselves. (don't respond to this with the Ken Thompson compiler back door proposition). Undoubtedly there are people that do this, although they are not equipped to sign their builds with the TC foundation PGP key.

As a popular encryption soft, I have no doubt it comes under scrutiny. I might trust it a mite more if it was signed by Bruce Schneier's key though :-)

Because pre-boot system partition encryption only works on x86/x86_64 and only for Windows.

What' is this then ?

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

Source Code ?

I have not compiled it [...]

I have. It works.

Uuuhhh.....Maybe I missed something here, but how exactly is TrueCrypt Not "open source"? When I pick downloads at the bottom of the page it has a nice link that says source code, which you click and it take you to this page which says, and I quote "The complete source code (in C, C++ and assembly) of the latest stable version of TrueCrypt.". So how exactly are they NOT open source? And as many folks out there that use TrueCrypt and as many security experts that recommend it I am sure that the source code has been looked over with a fine tooth comb, if for no other reason than those that would like to brag "I found a hole!". So maybe I am missing something here, but I always thought Open Source meant anyone could download the source files and check the code. Is it fake code or something?

What' is this then ?

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

Source Code ?

I have not compiled it, nor gone through it in detail, but it looks like source code to me.

D

Why not just use TrueCrypt pre-boot system partition encryption? The benefit of a hardware standard is not immediately clear to me.

Why not just use TrueCrypt pre-boot system partition encryption? The benefit of a hardware standard is not immediately clear to me.

Your honour, I once experimented with encryption, but could not understand how it worked.

A lot simpler is plausible deniability. "Oh, the password is 'omgyoullneverguessthispass'. Feel free to browse around those files." They could argue that you've got a hidden encrypted volume, but that's for them to prove at that point.

Since this is the UK you will hand over your encryption keys, have a nice day.

http://www.truecrypt.org/docs/?s=plausible-deniability

I could do with a breathalizer on my PC, but only to stop me writing regretable e-mails and postings when I'm pished.

There's no way that untrained cops could simply plug a device into a suspect's 5 year old laptop and be able to get results back in less than an hour, and that's not counting the potential modifications to the evidence caused by booting without a write-blocker, doing deleted-file recovery, opening compound files (Outlook offline storage, ZIP files, etc.) or doing signature analysis to identify obfuscated data. Don't even think about it if the suspect thought enough to use encryption.

The cops may want something like this, but it will probably be the laws of physics that prevent it and not the Constitution.

Sadly, it's simpler to make a tool that adds evidence and just post dates it. That's what they really want, because otherwise it would be hard to do their jobs.

According to US law, at least (and not always followed by US cops, I might add), whether the evidence on the secondary offense is admissible or not depends on how it was found. If a cop pulls over a car for speeding and sees an open container of beer sitting on the seat next to the driver, the open container is typically admissible. If, on the other hand, the cops raid a house looking for a stolen 62" television and, as long as they're in the house, decide to check in the toilet tank and find a stash of cocaine, that typically is not, since searching the toilet wouldn't have been part of the search for the big TV. Likewise, the original warrant would probably not allow the cops to bring along drug-sniffing dogs on a search for a stolen TV. Of course, I'm generalizing here, and am not a lawyer, but you get the picture.

Thus far, the same principles apply to computer searches. If the warrant says that the cops are looking for evidence related to illegal gambling operations on the computer, the cops are typically not allowed to search for non-related keywords (i.e. "lolita", "cocaine", etc.) unless such terms show up in documents found by the warranted search. If, in reviewing a document named IllegalGamblingProfits.doc, they see a reference to cocaine sales, the cops may have just cause to perform another search looking for cocaine. Since they've already got the computer at that point, though, they'd be better off to go back to the judge and get a 2nd warrant that authorizes the cocaine search, but given the similarities between finding the information in an admissible piece of evidence and seeing the open container in plain sight, I can see how a judge would give the benefit of the doubt in court.

I can't quite tell what the cops in TFA are asking for, though. If, on the one side, they want to be able to bring along a device that's pre-configured with the search terms for the warrant (gambling terms, from the above example), such a device would theoretically be legal in the US, since it would simply be automating the search that would otherwise have been performed by the trained analyst. If, on the other side, they want a device that identifies any illegal activity, that should be unconstitutional for 4th Amendment reasons.

All of the legal discussion ignores the technical aspects. I am a professional forensic analyst, and with relatively good hardware (dual 64-bit CPUs, 10k RPM SATA drives, 4GB of RAM, etc.) it can take hours to perform even a simple search with a small list (i.e. fewer than 5) of static (i.e. non-regex) keywords. Adding complexity in, or adding keywords, can increase the search time to days. There's no way that untrained cops could simply plug a device into a suspect's 5 year old laptop and be able to get results back in less than an hour, and that's not counting the potential modifications to the evidence caused by booting without a write-blocker, doing deleted-file recovery, opening compound files (Outlook offline storage, ZIP files, etc.) or doing signature analysis to identify obfuscated data. Don't even think about it if the suspect thought enough to use encryption.

The cops may want something like this, but it will probably be the laws of physics that prevent it and not the Constitution.

http://www.truecrypt.org/ Good luck with that.

Use Linux Mint(TM) with special additive TrueCrypt(TM) for a cleaner, fresher breath scan!

Well, PGP might have a solution, or, I have been using TrueCrypt for a while and have been pleased with it. TrueCrypt is licensed with an Open Source license (it's not GPL, but is open source), and is also free-as-in-beer.

there have been many posts saying use truecrypt, it's free, ubuntu ftw, and so on. if we're talking about home use, then by all means. i use truecrypt at home myself.

however, if you are a company, org, edu, etc, you more than likely need accountability. with free software, written by volunteers, etc, you'll typically find support from the forums, and from the developers when they have the time. open source rocks, but this is a major limitation, especially for prospective business users.

here's an example, both support/contact pages from the 2 encryption products in question:

truecrypt forums and truecrypt contact. they have no true support, as far as i know.

pgp support and pgp partners.

truecrypt is awesome, but you'll never get from them what you get from pgp. and, to the people who said "what if pgp goes away, it's closed source and you're screwed", pgp will not go away; it may be bought, sold, merged, but until we reach some utopian society where encryption is no longer necessary, pgp is here to stay.

anyway, the above links are important because: with commercial products such as pgp, you have a company, with teams of technicians, engineers, etc, all ready and willing to work with you to put together a solution for your problem. the same goes for partners and major resellers. if your company has a preferred channel through which to buy its IT gear, use them. what you get here is assistance, accountability, support, collaboration, SLAs, and so on, all the things a business of any kind typically needs. unfortunately, you don't get that from truecrypt. if your hard drive failure rate goes from 1 per month per site to 50 per month per site, who do you think will be there to fix the situation, replace the disks, and so on?

my first question for you would be, have you engaged pgp directly (as a company), or indirectly throught a business partner? if so, who is represented in these discussions? any sort of management from your department, or is it just IT? if not, i would recommend working internally to find out who is doing this project, and make sure everyone has adequate representation during all the discussions, testing, r&d, etc for this project. maybe WDE isn't for you and people in similar positions. maybe encryption for DB transactions will be sufficient. maybe you don't need anything at all.

despite what many bitter slashdotters would have you believe, most companies realize that selling the wrong solution to a client is a horrible thing, so they are typically quite eager to work with you to make sure it's done right the first time around.

so, in the end, i'd say make sure you or a representative of you and similar co-workers communicates with the project team and pgp/reseller, and that your concerns are being addressed. i guarantee you're not the first person to feel this way, and i'm sure pgp and/or the reseller have tools and procedures in place to make sure this rolls out how it needs to.

one last note. some advice above and below said to make sure your reports prove that it would cost ungodly amounts of money to keep your current productivity levels after instituting WDE. i think this is a bad idea, and like any other science project, you should see what happens, and report the results. maybe WDE would ruin your productivity. maybe it wouldn't...

there have been many posts saying use truecrypt, it's free, ubuntu ftw, and so on. if we're talking about home use, then by all means. i use truecrypt at home myself.

however, if you are a company, org, edu, etc, you more than likely need accountability. with free software, written by volunteers, etc, you'll typically find support from the forums, and from the developers when they have the time. open source rocks, but this is a major limitation, especially for prospective business users.

here's an example, both support/contact pages from the 2 encryption products in question:

truecrypt forums and truecrypt contact. they have no true support, as far as i know.

pgp support and pgp partners.

truecrypt is awesome, but you'll never get from them what you get from pgp. and, to the people who said "what if pgp goes away, it's closed source and you're screwed", pgp will not go away; it may be bought, sold, merged, but until we reach some utopian society where encryption is no longer necessary, pgp is here to stay.

anyway, the above links are important because: with commercial products such as pgp, you have a company, with teams of technicians, engineers, etc, all ready and willing to work with you to put together a solution for your problem. the same goes for partners and major resellers. if your company has a preferred channel through which to buy its IT gear, use them. what you get here is assistance, accountability, support, collaboration, SLAs, and so on, all the things a business of any kind typically needs. unfortunately, you don't get that from truecrypt. if your hard drive failure rate goes from 1 per month per site to 50 per month per site, who do you think will be there to fix the situation, replace the disks, and so on?

my first question for you would be, have you engaged pgp directly (as a company), or indirectly throught a business partner? if so, who is represented in these discussions? any sort of management from your department, or is it just IT? if not, i would recommend working internally to find out who is doing this project, and make sure everyone has adequate representation during all the discussions, testing, r&d, etc for this project. maybe WDE isn't for you and people in similar positions. maybe encryption for DB transactions will be sufficient. maybe you don't need anything at all.

despite what many bitter slashdotters would have you believe, most companies realize that selling the wrong solution to a client is a horrible thing, so they are typically quite eager to work with you to make sure it's done right the first time around.

so, in the end, i'd say make sure you or a representative of you and similar co-workers communicates with the project team and pgp/reseller, and that your concerns are being addressed. i guarantee you're not the first person to feel this way, and i'm sure pgp and/or the reseller have tools and procedures in place to make sure this rolls out how it needs to.

one last note. some advice above and below said to make sure your reports prove that it would cost ungodly amounts of money to keep your current productivity levels after instituting WDE. i think this is a bad idea, and like any other science project, you should see what happens, and report the results. maybe WDE would ruin your productivity. maybe it wouldn't...

Solution: http://www.truecrypt.org/docs/?s=rescue-disk

Truecrypt won't actually let you run whole disk encryption without creating a rescue disk.

Read the FAQ; drives usually have larger block sizes than the block size used for encryption, so there is not much difference.

If you do encrypt why use PGP? It costs money and its proprietary. Use Truecrypt which is free and open source, does whole disk encryption which according to this can sometimes actually *boost* performance. I use Truecrypt daily and its awesome. http://en.wikipedia.org/wiki/Truecrypt#Performance http://www.truecrypt.org/