Hacker News new | past | comments | ask | show | jobs | submit login

Encryption isn't magic. To the OS, a file is a file is a file.



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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: