This is one of the oldest practical problems in encryption, and the reason that groups handling PII use full-disk encryption and encrypted VM; even if the OS wasn't archiving your plaintext for you (and really, what else do you expect it to do?), there's probably 10 other ways your plaintext is persisted after encryption.
I would expect it to archive the ciphertext? Honestly, it sounds like TrueCrypt should warn Win7 users about the feature and maybe even hook into it if possible.
Of course it is, but by storing the backup versions on a hidden partition as implied by the article, Win7 is clearly violating what the user intended to be the storage policy for the file. Had they instead stored backups on the same partition, then a full-disk encryption program would also encrypt the backup. Here, the user is expecting a behaviour (the file is expected to be encrypted), and Win7 is violating that expectation. That's why I said I expected Win7 to archive the ciphertext.
This is precisely what SimpleBackup does with my encrypted directory under Linux. Since the encrypted store is mounted as a loopback via encfs and fuse, SimpleBackup only sees the files the ciphertext that encfs uses to generate the plaintext view. So, to the best of my knowledge, Linux/encfs/SimpleBackup act as I expect them to, backing up only the ciphertext.
I think you might have an unreasonable expectation of how well (mostly) userland encryption should work.
Win7 is doing its job; TrueCrypt is only doing part of its job; and I'm guessing that unless you shoulder a lot of the job you think EncFS is doing for you, your plaintext is sprayed all over your hard disk (seriously: image the drive and scan through it in a fast hex editor).
Most files bounce all over the place before they ever see the AES block function. Did you mail it? Did you PGP or S/MIME encrypt the file when you mailed it? Oops: you probably gave up your plaintext to a forensics tech.
And we could get into swap, etc. No, it's not airtight, and I know that. I'll just say that the archival feature goes beyond this level of leakage. Whereas most, if not all, of what you mention is at least contained in a single partition and in swap, and thus can be protected by full-disk encryption, creating a new hidden partition to store secret backups is violating expectations quite badly.
I choose to use a secure directory rather than full-disk as part of a security/performance tradeoff, and so I know that there are temp files and caches and swaps all over the place (though GnuPG is setuid so that it can lock pages in memory, thus preventing them from going to swap-- an attacker would have to freeze my RAM to get to my keyring). Most of these, though, should at least be manageable. I can see them and interact with them.
I do agree that in some sense TrueCrypt isn't doing its job, but I argue that's because their expectations have also been violated. Do the API specs make it clear that data written using those APIs may be copied off-partition without user interaction? If not, then the TC team would have to find out the hard way, then scramble to workaround this poor design decision.
GPG and PGP both make tempfiles, as do many of the email integration systems that use PGP, but I'm not here to help harden your idiosyncratic Linux setup, only to explain that your expectation that the OS designers are going to make 3rd-party crypto packages a priority is unrealistic.
If you need crypto-level assurance for your machine, you use full-disk encryption --- or at the bare minimum you turn off system restore points and use secure deletion software. People who harden Win64 professionally know to do this stuff, just like people who harden Linux setups professionally know the rest of the problems with your EncFS system.
I'm a security person, and not a Windows user, and I prefer the Win7 approach over the "whatever makes TrueCrypt easier to write" approach.
Granted this is a parable to prove a technical point, but encryption and steganography issues aside, NO professional investigative journalist would risk keeping such sensitive material at home. It's kept at the office, or rotated across multiple safe deposit boxes, multiple safehouses, or, at the bare minimum, an offsite dead/dry dump--NEVER at home.
Additionally, why did he even open the door in the first place?
If they have a warrant, and if the information is valuable enough, let them expend time, effort, and resources to physically break in while the critical files are scrubbed (i.e. securely deleted with multiple over-writes).
If he's paranoid enough, these days, it will never be permanently stored on hard disk media in the first place. Instead the project files will be on easy-to-destroy and physically tiny flash media.
If the information is valuable enough (especially with corporate backing and 'sources' laws protections in the U.S.) it's worth the risk fighting an obstruction of justice charge.
If you are ever going to commit a crime, don't use a computer. If you do, you will get it caught. It's that simple.
If someone has a warrant to seize your computer, and you encrypt it's contents, you can be compelled to remove the encryption. If you don't, then you have committed obstruction of justice, and you are going to go to jail anyways.
Strong encryption will protect against the case where someone has your computer, but not you. However, if they have both you and your computer, its not going to protect you.
Also, are you sure that the Windows 7 hidden partition is used for the Volume Shadow Copy Service? My understanding is that it's only used for storing system files, not user documents.
Your user documents (and their backups) should be stored on the system volume (not the hidden partition), and hence should be covered by your encryption software.
I had no idea that Windows 7 - which I use - had this functionality. Looking at this from the other perspective, I think this article does a better job at marketing this feature (restore previous versions of documents easily thanks to Windows Restore) better than Microsoft ever has.
