Slashdot Mirror

The source code is available here:

http://www.truecrypt.org/downl...

Nothing to stop anyone anywhere from looking. And I don't see how a " NSA letter " , even to someone in the USA, would stop them from exercising their first amendment rights and writing whatever they wanted, or from adding comments to the code and posting them somewhere, etc.

"Windows XP does not support any encryption that's still considered secure."

Not only is it not secure, it has been EXTREMELY buggy. People have lost their files to Microsoft's encryption bugs. Also, the U.S. government believes it can force executives to do anything it says, and keep that secret from taxpayers.

It is best to use only GPG and TrueCrypt for encryption, or other open source software. Open source software is much more difficult to manipulate.

With the rise of deniability features in data-at-rest encryption products, I'm not sure how this is going to work in the real world. Wouldn't be hard to use these technologies for communications too.

I have so many I use a master password list written in a simple text document that is in two places. My main machine and a flash drive both protected by Truecrypt. The flash drive actually has a small binary on it so the computer I use it on does not have to have Truecrypt installed on it for me to use it. It supports Windows, Macintosh, and Linux. http://www.truecrypt.org/

if not set up correctly I would tend to agree.

What does the set up have to do with it? If the backdoor is built-in already, it's built in. Right?

Page 15 of the PDF mentioned...

What is a backdoor?

A method to bypass data encryption or security.

Blah blah blah

"Currently available for major encryption software - Microsoft
BitLocker, FIleVault, BestCrypt, TrueCrypt, etc." - the paragraph is a direct quote.

------------- True Crypt shouldn't of been added/listed -----------------

First TrueCrypt hasn't been backdoored. The fact they even mentioned it I figure
if it's setup up wrong it can be accessed, or worry you.

I reinstall OS's a lot, I had a TrueCrypt volume but after switching OS's it never would
show again. (I didn't try to recover it).

Given it's the opposite of back dooring, but I lost a lot of work in the process. That's when
I felt I should RTFM. One needs to be very careful with TrueCrypt, NTFS isn't that secure, and
TrueCrypt will tell you that, In fact a lot of precautions are required

----- Not back doored by reading memory block ------

A recent /. article mentioned TrueCrypt was back doored by reading a memory block.
http://it.slashdot.org/story/1...

A post and link by MidSpeck negated the claim:

"Still working as intended
by MidSpeck (1516577)
While good to know these types of attacks exist, TrueCrypt's security model is still holding strong. http://www.truecrypt.org/docs/... "

Which states, "TrueCrypt does not:
Encrypt or secure any portion of RAM (the main memory of a computer)."

----
True Crypt needs to be audited to set matters straight once and for all.

A lot of disinformation is being released to where one doesn't know what to believe.

While good to know these types of attacks exist, TrueCrypt's security model is still holding strong. http://www.truecrypt.org/docs/security-model

Xoring and mod-256 summing give the same output (basic crypto arithmetics). The documentation correctly says that TrueCrypt does use 2000 iterations in PBKDF with ripemd ( http://www.truecrypt.org/docs/header-key-derivation ). The other points are simply irrelevant.

Long story short: someone doesn't like truecrypt.

Not open source? The source is available for download here.

You can't compile it yourself. You have no idea what is in the source.

You certainly can compile it yourself; I built it on my old Linux iBook G4 (PowerPC), since there were no binaries available for that platform. As has been discussed above, it does have a weird license, but it is absolutely open source.

Grandparent probably refers to Open Source Software, which is a formally defined term. It's not enough that you can merely read the source, you have to be able to redistribute it and any changes, too.

It's not open source.

Not open source? The source is available for download here.

You can't compile it yourself. You have no idea what is in the source.

You certainly can compile it yourself; I built it on my old Linux iBook G4 (PowerPC), since there were no binaries available for that platform. As has been discussed above, it does have a weird license, but it is absolutely open source.

Given all of this, plus the problems with TrueCrypt authorship etc. I think the best course of action is replacing with a free implementation, maybe starting with something like this?

Ah, I see the current TrueCrypt license has undergone substantial changes since the early days. Looks like a complete mess to me :/

All typos in the writeup aside, the TrueCrypt FAQ states:

In addition to reviewing the source code, independent researchers can compile the source code and compare the resulting executable files with the official ones. They may find some differences (for example, timestamps or embedded digital signatures) but they can analyze the differences and verify that they do not form malicious code.

If so, why would it cost $16,000 to do that? Heck, I bet somebody would do that, and also do "a full security audit" of the source code, for free.

When I used to use TrueCrypt years ago, I assumed someone had already done that. But I never found any proof, so I stopped using it. Will the $16,000 maybe be used to pay someone to do that formally and publish the results?

Strangely enough, nobody seems to be calling attention to the fact that this slideshow confirms TrueCrypt has been backdoored (second slide, page 15). Is it possible to get a degree in applied mathematics without meeting the NSA's recruiting arm?

I didn't read it as there being a backdoor for TrueCrypt -but one being available, and there is if you don't use it correctly.

I started using TrueCrypt and back doored it myself without knowing.

I encrypted one data partition to test it out; but if the OS partition isn't encrypted your not hiding anything,
especially Windows where everything you do is listed in multiple places. Thats just one of many precautions.

I found this after I dug a bit deeper into TrueCrypt (Read TFM). IMPORTANT: If you want to use TrueCrypt, you must follow the
security requirements and security precautions listed in this chapter. http://www.truecrypt.org/docs/security-requirements-and-precautions

The TrueCrypt FAQ http://www.truecrypt.org/faq links to Operation Satyagraha

http://yro.slashdot.org/story/10/06/26/1825204/fbi-failed-to-break-encryption-of-hard-drives
"the FBI has failed to decrypt files of a Brazilian banker accused of financial crimes by Brazilian law enforcement,
after a year of attempts" "Truecrypt and the other unnamed. 256-bit AES was used"

http://en.wikipedia.org/wiki/TrueCrypt#Operation_Satyagraha claims "They enlisted the help of the FBI, who used dictionary attacks"
-real high tech stuff.

Strangely enough, nobody seems to be calling attention to the fact that this slideshow confirms TrueCrypt has been backdoored (second slide, page 15). Is it possible to get a degree in applied mathematics without meeting the NSA's recruiting arm?

I didn't read it as there being a backdoor for TrueCrypt -but one being available, and there is if you don't use it correctly.

I started using TrueCrypt and back doored it myself without knowing.

I encrypted one data partition to test it out; but if the OS partition isn't encrypted your not hiding anything,
especially Windows where everything you do is listed in multiple places. Thats just one of many precautions.

I found this after I dug a bit deeper into TrueCrypt (Read TFM). IMPORTANT: If you want to use TrueCrypt, you must follow the
security requirements and security precautions listed in this chapter. http://www.truecrypt.org/docs/security-requirements-and-precautions

The TrueCrypt FAQ http://www.truecrypt.org/faq links to Operation Satyagraha

http://yro.slashdot.org/story/10/06/26/1825204/fbi-failed-to-break-encryption-of-hard-drives
"the FBI has failed to decrypt files of a Brazilian banker accused of financial crimes by Brazilian law enforcement,
after a year of attempts" "Truecrypt and the other unnamed. 256-bit AES was used"

http://en.wikipedia.org/wiki/TrueCrypt#Operation_Satyagraha claims "They enlisted the help of the FBI, who used dictionary attacks"
-real high tech stuff.

How To Securely Store Transmit Data

Encrypt your whole fucking drive. Don't use Bitlocker or any hard drive manufacturer's built in shit that stores the key anywhere.

For instance: http://www.truecrypt.org/

How To Securely Transmit Data

Encrypt it your fucking self before you send it. Send the key separately, securely.

For instance:

Install 7zip
Right click the file you want to transmit
Click "Add to archive..."
Archive format: 7z
Compression level: Whatever you need / want (I almost always use Ultra)
Compression method: LZMA2
Enter a secure password
Encrypt file names if you want
Click OK

Then distribute the file however you want. Transmit the password to the recipient in person only.

Something even more similiarly related might be Truecrypt with it's "plausible deniability" using hidden volumes. http://www.truecrypt.org/docs/plausible-deniability

You could have just checked their web site...
I, however, did it for you since you seem to have some challenges using these computer/internet thingys.
http://www.truecrypt.org/docs/issues-and-limitations
"There are currently no confirmed issues."

Maybe you don't understand how truecrypt works?

TrueCrypt can help. Put your encrypted hard drives somewhere else in your luggage.

Very bad advice indeed. These things can be found in the luggage searches, and then they have clear signs of deception and can give you the special treatment.

TrueCrypt can help. Put your encrypted hard drives somewhere else in your luggage.

But the real issue is U.S. government corruption. Officials do what they want. The rule of law and human decency no longer matters.

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

Note that the free TrueCrypt offers encryption using 2 or more different encryption methods, with different keys for each method. They call it cascade encryption. Unfortunately, that term is used also for encryption using 2 or more keys with the same encryption method.

"He should have encrypted his computer."

I think it would have been good enough if he just encrypted the data. It is really hard to use an encrypted computer.

You know can encrypt the entire hard-drive, including the operating system, and the computer is still easily usable - if you know the password.

So, a Truecrypt Hidden OS would be extremely useful since they dont _KNOW_ you have the hidden OS (unless you were stupid enough to talk about it after you were arrested).

Well, AES-256 is readily available but I guess only the Feds and the accused know what was used.

Anything that is worth it's salt (pun intended) will cause grief for any person trying to decrypt the data. There's lots of tools out there, just go look at a few.

I would recommend looking at TrueCrypt http://www.truecrypt.org/ and OpenPGP http://www.openpgp.org/ first.

Yes, I know there's lots of tools out there, that's why I asked the question. I've looked at a few, but I don't know which ones are so difficult to crack that the FBI was willing to try to get the judge to compel the defendant to reveal the key and risk having the judge rule that the defendant is within his rights to not reveal the decryption key. It seems like if the FBI secretly had the ability to break the encryption, they would have done that instead of risking that the judge would rule in the favor of the defendant. Though I guess it's possible that they *did* break the encryption and know what's there, but were looking for a way to make the evidence known without revealing that they cracked it.

Well, AES-256 is readily available but I guess only the Feds and the accused know what was used.

Anything that is worth it's salt (pun intended) will cause grief for any person trying to decrypt the data. There's lots of tools out there, just go look at a few.

I would recommend looking at TrueCrypt http://www.truecrypt.org/ and OpenPGP http://www.openpgp.org/ first.

+1 to this. I have a setup similar to the OP's (albeit with different software) and it has no impact at all on my backups, which I take in exactly the same way as I would were the system not encrypted, i.e. they access the files using the ordinary file system API and copy them to a different location (where they are, of course, reencrypted). I suppose the decrypt-compress-reencrypt cycle involved here is a little inefficient, but it doesn't seem to be a huge issue in reality.

As for increased number of write cycles, it's all down to the software you use. If the driver will emulate an SSD and pass through the 'trim' commands, you won't see any problems. At least some OTFE packages can do this. Truecrypts docs suggest that at least some configurations will work, although it does warn that using it means attackers will be able to potentially identify empty sectors. This means its use is incompatible with hidden volumes, but nothing in OP's description suggests he was using them.

"TrueCrypt is open-source and free software. The complete source code of TrueCrypt (written in C, C++, and assembly) is freely available for peer review..."

http://www.truecrypt.org/docs/?s=source-code

Encryption software needs to be inspectable and verifiable in order to be trusted with anything worth protecting. Closed-source software burned into the firmware of a USB drive does not meet that requirement.

That said, somebody make a programmable USB drive with open source encryption that can be flashed to it (probably with a fused write protect) and *that* would be a compelling product.

Use TrueCrypt to create an encrypted volume within the USB drive.
Best Case Scenario: USB drive provides an additional layer of cryptographic protection.
Worst Case Scenario: Attackers find out easy-to-break USB drive was only the start of their headaches.

Seems like a win-win to me.

FIPS 140-2 to be more specific. There are plenty of free options.

Are there? Last time I looked into FIPS 140, it was the case that only certain software versions were validated by NIST, and none of the validated incarnations were either free-beer or free-libre.

Even the folks behind Truecrypt "To our best knowledge, TrueCrypt complies with the following standards, specifications, and recommendations...", before failing to mention FIPS 140 at all.

Indeed, looking again at the list of validated FIPS 140 wares, it does seem to be lengthy, but it is mighty specific and I do not see a single instance of anything free-as-in-beer, let alone "plenty of free options."

The only thing that stands out is that Red Had has had some OSS software validated as being FIPS-140, but only when installed according to their posted Security Policy, which seems to require RHEL, which is not free.

So. [citation needed], and stuff: If you've got the goods, give 'em up. (And no, "To our best knowledge" is not a defense against a HIPPA violation: It either is validated to FIPS 140(-2), or it is not.)

** Before a key can be erased from RAM, the corresponding TrueCrypt volume must be dismounted. For non-system volumes, this does not cause any problems. However, as Microsoft currently does not provide any appropriate API for handling the final phase of the system shutdown process, paging files located on encrypted system volumes that are dismounted during the system shutdown process may still contain valid swapped-out memory pages (including portions of Windows system files). This could cause 'blue screen' errors. Therefore, to prevent 'blue screen' errors, TrueCrypt does not dismount encrypted system volumes and consequently cannot clear the master keys of the system volumes when the system is shut down or restarted.

Keys for non-system volumes are securely wiped from memory on dismount, which is automatic as part of the restart / shutdown procedure.

I don't think that it is interesting that someone has figured a way to hack a running computer that they have physical access to.
However, the hibernation file inspection hack had bothered me, or rather didn't bother me after I read the document.

Check out http://www.truecrypt.org/docs/hibernation-file

from the link:
Note: The issue described below does not affect you if the system partition or system drive is encrypted* (for more information, see the chapter System Encryption) and if the hibernation file is located on any of the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data are encrypted on the fly before they are written to the hibernation file.

When a computer hibernates (or enters a power-saving mode), the content of its system memory is written to a so-called hibernation file on the hard drive. You can configure TrueCrypt (Settings > Preferences > Dismount all when: Entering power saving mode) to automatically dismount all mounted TrueCrypt volumes, erase their master keys stored in RAM, and cached passwords (stored in RAM), if there are any, before a computer hibernates (or enters a power-saving mode). However, keep in mind, that if you do not use system encryption (see the chapter System Encryption), TrueCrypt still cannot reliably prevent the contents of sensitive files opened in RAM from being saved unencrypted to a hibernation file. Note that when you open a file stored on a TrueCrypt volume, for example, in a text editor, then the content of the file is stored unencrypted in RAM (and it may remain unencrypted in RAM until the computer is turned off).

Note that when Windows enters Sleep mode, it may be actually configured to enter so-called Hybrid Sleep mode, which involves hibernation. Also note that the operating system may be configured to hibernate or enter the Hybrid Sleep mode when you click or select "Shut down" (for more information, please see the documentation for your operating system).

To prevent the issues described above, encrypt the system partition/drive (for information on how to do so, see the chapter System Encryption) and make sure that the hibernation file is located on one the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data will be encrypted on the fly before they are written to the hibernation file.

Note: You may also want to consider creating a hidden operating system (for more information, see the section Hidden Operating System).

Alternatively, if you cannot use system encryption, disable or prevent hibernation on your computer at least for each session during which you work with any sensitive data and during which you mount a TrueCrypt volume.

* Disclaimer: As Windows XP and Windows 2003 do not provide any API for encryption of hibernation files, TrueCrypt has to modify undocumented components of Windows XP/2003 in order to allow users to encrypt hibernation files. Therefore, TrueCrypt cannot guarantee that Windows XP/2003 hibernation files will always be encrypted. In response to our public complaint regarding the missing API, Microsoft began providing a public API for encryption of hibernation files on Windows Vista and later versions of Windows (for more information, see the Version History, section TrueCrypt 5.1a). Since version 7.0, TrueCrypt has used this API and therefore has been able to safely encrypt hibernation files under Windows Vista and later versions of Windows. Therefore, if you use Windows XP/2003 and want the hibernation file to be safely encrypted, we strongly recommend that you upgrade to Windows Vista or later and to TrueCrypt 7.0 or later.

Unfortunately secure booting is linked so tightly with vendor lockdown, tracking, and DRM concerns that I never expect it to be embraced by any open-source community. Hysteria over treacherous computing so far has been overblown. For example, the potential abuse of the unique ID features of the TPM chips were not sufficient reason for the boycott against using them when available they generated--especially if you're booting into an open-source OS.

It's pretty ridiculous that software like trusted grub isn't in mainstream Linux distributions, while Windows booting is easy to protect using the TPM with BitLocker. I boot my Linux/Windows Thinkpad using the Windows boot loader specifically because it resists evil maid attacks better when I'm traveling. The hysteria isn't limited to Linux; the same indefensible arguments are made by TrueCrypt. That acts as if TPM provides no protection against physical attacks, which is ridiculous if you look at how much work it takes to hack one.

Do I have to?

Would you like to start backpedalling now, or should I just make up some extra caveats about enterprise management and vendor support contracts for you?

Even better, from the TrueCrypt FAQ:

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

Yes. Note that there is no "backdoor" 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).

It is not stupid by any means, the system stores information all over the place. It would be to hard to try and encrypt each one by itself. It is far easier to just encrypt the whole thing. You would be surprised how little of a hit you take in performance. I used TrueCrypt for a good while and I never notices any slow down at all. Encryption like AES are extremely fast.

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), hibernation files, swap files, etc., are always permanently encrypted (even when power supply is suddenly interrupted). 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 too.

http://www.truecrypt.org/docs/

they would simply make not disclosing the key to the authorities illegal

Two words: Plausible Deniability.

The main caveat here is that any hardware which has been outside of your custody even once must never be trusted again, but that's a small price to pay compared with the alternatives. The government can still get to you if they want you bad enough, but it's much more likely that small fish will escape the net and get lost in the noise. As long as the story remains plausible, nobody's going to ask too many questions of the average citizen.

AVG Antivirus for Linux â" Official Free LiveCD, DVD, USB â" daily updated virus database, latest development version, GPG sigs, includes TrueCrypt!
11 October, 2012

You may have heard about AVG Antivirus for Linux:

http://free.avg.com/ww-en/download.prd-alf.tpl-stdfull

And you may know of AVGâ(TM)s Antivirus for Linux bootable LiveCD:

http://www.avg.com/us-en/avg-rescue-cd-download

â"â"â"â"â"â"â"â"â"â"-

But did you know they also have a Live CD/DVD/USB with a daily updated virus database and the latest development version?

Did you know each release is signed with a GPG signature?

That it comes with TrueCrypt?[1]

Did you also know they provide instructions for, âoeBuilding AVG Rescue CD GNU/Linux?â

From the site:

âoeAVG Technologies will provide for each AVG Rescue CD GNU/Linux release a makefile and a AVG Rescue CD GNU/Linux package with all resources allowing you to build and customize the AVG Rescue CD GNU/Linux.â

Amazing â" they provide this daily free resource and go so far as to provide instructions on how to build it yourself!

What are you waiting for? Go check it out:

https://share.avg.com/arl

â"â"â"â"â"â"â"â"â"â"-
[1] http://www.truecrypt.org/

TrueCrypt is free, and has a way for administrators to recover the encryption key if the user happens to forget it. The admin simply sets up TrueCrypt on the user's device, gives them a default password and copies the header. The user then changes the password to their own password.

From the TrueCrypt FAQ:

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

Yes. Note that there is no "backdoor" 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).

Centrally generated keys in the combination with smartcards works perfectly... You can even have several shared keys on a single smartcard....
Sure the user will have to remember his/her password, but the encryption-keys can always be recovered by IT..

http://www.truecrypt.org/docs/?s=keyfiles

1. Secure location on non-networked computer, where all smartcards are initialized...
2. User gets new smartcard and inserts into computer.
3. User gets to select a 5 digit PIN or a full-featured password, whatever your requirements are.
4. Computer starts to initialize the encrypted partition with keys from smartcard.
5. Small application will download updated private/shared keys from AD/LDAP etc that are encrypted (per user key). Smartcard will get the encrypted data and decrypt and install the new certs by itself...

scenarios:
1. User looses laptop. - disk encrypted.
2. User looses laptop with smartcard still inside.. employee gets yelled at for a few minutes for not following the policy. Data still secure, as long as the smartcard physically secure, since it will require the PIN to decrypt and give out the real encryption key.
3. User looses smartcard - IT initializes a new smartcard. User plugs in the new smartcard that downloads and reinitializes the card with the previously stored keys... Might go for a re-encryption depending on how the card was lost.. (broken/thrown away by accident/stolen)

So.. it's not that hard hard to have simple key-management in a office either... you just have to make it simple for the people to use...

You need to have a look at truecrupt

I encrypt hd's so in the event of lost or stolen drives i know they are fairly safe.... If i had to decrypt for the cops I have no problem with the actual content... If i did well than..
http://www.truecrypt.org/docs/?s=hidden-volume

That doesn't work either. If you have unpartitioned space on your disk filled with random data then they may assume it's a hidden encrypted volume and instruct you to give them the passphrase. If it's not a hidden encrypted volume you will be unable to do that so will be jailed forever.

Better fill all unpartitioned space with zeros.

I encrypt hd's so in the event of lost or stolen drives i know they are fairly safe.... If i had to decrypt for the cops I have no problem with the actual content... If i did well than.. http://www.truecrypt.org/docs/?s=hidden-volume

First, why not use the obvious countermeasure here. When you create an encrypted volume, you should enter 2 keys, not just one. One will unlock your drive, another will appear to unlock your drive, but in fact deletes the contents of the disk entirely. Essentially it replaces the on-disk encryption keys (which is what your password in reality unlocks) with keys that are only useful for the second partition. The second partition is then enlarged to extend over the original copy. Several programs provide this ability (granted they're for-pay and not cheap, but nevertheless, your privacy is worth something to you isn't it ?). This trick is known to have worked in China (that must have taken some serious amount of balls).

Actually, TrueCrypt offers just this sort of encrypted, hidden volume for free. You create two volumes with two keys, one nested inside the other. One key decrypts only the outer volume and it appears innocuous. There is, in theory, no way to tell there is even a hidden inner volume. The second key decrypts and mounts only the inner volume. Again, in theory, there's no way to even know of the existence of the hidden volume. Whether or not it would hold up to rigorous cryptanalysis remains to be seen, but TrueCrypt seems to be pretty respected in the encryption community and I use it quite a bit.

What you actually want is encryption software with plausible deniability features like TrueCrypt or BestCrypt. I really don't understand why more people don't know about these technologies.

like a truecrypt hidden volume?

No, the hidden volumes can still be easily found on most disk partitions. Only in Truecrypt 6 has this been addressed, and then only on certain file system versions.

Disk encryption software already supports hidden volumes. Even if this kind of decision becomes dominant case law, that won't accomplish anything. People will just start deploying volumes with two passphrases, and when ordered to give up the passphrase, giving up the one that decrypts grandma's recipe collection.

Since there's no way to prove that a second volume exists within the blank space of the first one, encryption will win the day.

Use a truecrypt hidden volume: http://www.truecrypt.org/hiddenvolume

Yeah, the "I can't recall" defense is the best option I would think if you didn't use a Plausible Deniability encryption to begin with. Seems to work well for all the business executives and political scandal co-conspirators that get called before congress at any rate.

like a truecrypt hidden volume?

Since the laws mean nothing in the US anymore. TrueCrypt goes into great detail about making a decoy OS: http://www.truecrypt.org/docs/?s=hidden-operating-system