Ask Slashdot: Simplifying Encryption and Backup? 148
New submitter FuzzNugget writes "A recent catastrophic hard drive failure has caused me to ponder whether the trade-off between security and convenience with software-based OTFE is worthwhile. My setup involves an encrypted Windows installation with TrueCrypt's pre-boot authentication, in addition to having data stored in a number of TrueCrypt file containers. While it is nice to have some amount of confidence that my data is safe from prying eyes in the case of loss or theft of my laptop, this setup poses a number of significant inconveniences." Read on below; FuzzNugget lists some problems with this set-up, and seeks advice on a simpler system for backing up while keeping things locked down.
FuzzNugget continues: "1. Backup images of the encrypted operating system can only be restored to the original hard drive (ie.: the drive that has failed). So, recovery from this failure requires the time-consuming process of re-installing the OS, re-installing my software and re-encrypting it. Upgrading the hard drive where both the old and new drives are still functional is not much better as it requires decryption, copying the partition(s) and re-encryption.2. With the data being stored in large file containers, each around 100-200GB. It can be come quite burdensome to deal with these huge files all the time. It's also a particularly volatile situation, as the file container is functionally useless if it's not completely intact.
3. As much as I'd like to use this situation as an opportunity to upgrade to an SSD, use with OTFE is said to pose risks of data leaks, cause decreased performance and premature failure due to excessive write operations.
So, with that, I'm open to suggestions for alternatives. Do you use encryption for your hard drive(s)? What's your setup like and how manageable is it?"
backup orthogonal to encryption (Score:5, Insightful)
Aka: you are doing it wrong. First think of backup: you have a machine, and you copy its contents to another drive. Ok. Easy. Now take a breath, and use OTFE for the original hard disk, and now add OTFE for the external drive/media. There. The backup has NOTHING to do with encryption. If you have forced yourself into a backup solution which requires encryption integration to the point that it only restores to a specific hardware, you are failing hard time, precisely for the reason backups are for when you don't have the original hardware.
Again, separate backup from encryption. I mean, next you will want an integrated internet/remote backup and you will cry us a river? Compartimentalize each function and then you can mix them freely.
What problem are you trying to solves? (Score:5, Insightful)
aside: "OFTE" seems to stand for "On The Fly Encryption" - an initialism I hadn't heard used by IT folks before ... but anyway....
Why aren't you backing up your files from one encrypted volume to another, at the file level? It sounds like you're doing block level backups of your container files. Do you not trust your backup computer to have those volumes open and decrypted at backup time? Dealing with block-level diffs isn't an easy way to approach the problem, but you could look at mirroring a copy-on-write filesystem, or a dedicated backup application that does its own block diffs and maps for incrementals.
I use LUKS on linux for my backups, and then the backup drives go offsite. But the backup computer is allowed to access the files while the backup is running - which isn't a problem for the risks I'm trying to defend against. If you can't trust your backup computer, another approach is to run Windows as a VM and handle your backups with linux, which has a lower intrusion rate.
Your comment is so epically stupid..... (Score:4, Insightful)
...that it almost becomes a work of art. I want to just sit and admire it and try and tease out the nuances of idiocy and subtle details or inanity that lurk within the depths of its stupidity, in hopes that I'll reach some new plateau of understanding as I gain insight into the essential nature of the moron of the species.
alas, time is short, so I'll have to return another time to bask in the aura of this commentator's ignorance.
Crashplan is awesome. (Score:4, Insightful)
A few more words about Crashplan.
Crashplan markets itself as a competitor to things like Mosy and other purveyors of managed remote backup. But Crashplan is distintly different than all these others in a way that is unbeatable. Namely, you don't have to use their archives to store your data. With crashplan you can target any disk as backup storage. This could be an external disk connected by USB 3.0 or one over at your freinds house (they run crashplan too), or you can use crashplans servers. They sell the app not the service if just want to use it with your own disks or a freinds.
The difference here is what happens when you need to restore. With any other service (like Mosy) you are hosed. How the heck are you going to recover a terrabyte from the remote storage to your local disk over the internet????? Not going to happen. FOr a fee Mosy will burn DVDs and mail them to you. But that assumes you know what date you want the back up for. If you are trying to recover from some slow disk corruption or a trojan you want to inspect the backups first to find the latest possible date before the corruption started, then you want to add back the newer files you can salvage. That's not going to happen with the DVDs you have sent to you.
But crash plan is different. You just drive across town to your freinds house and pick up the drive. Mount it locally and find all the files you need for the backup. Just like what you would like to have! perfect.
If crashplan would just solve their Java memory management issues it would be perfect. when you launch it it starts off with 100MB but a week later it's up to a gigabyte of memory use. Fortunately it seems the Virtual Memory manager is able to page out most of this when it's not active, but java programs are such out of control pigs.
Re:backup orthogonal to encryption (Score:2, Insightful)
(2) Install a SECOND hard drive for your private data. Just data.
(3) Use full-drive encryption on that drive. You will have to enter a (preferably long) password when you log in, but that's the biggest hassle.
(4) Back up your encrypted drive. There should be little if any need to back up your OS and software.
(5) Regularly clear your logs and caches.
Alternatively, you could create large encrypted volumes on an unencrypted hard disk, and just back those up as needed. That helps eliminate backing up empty (but encrypted) space. You don't even need backup software to do this: periodically just copy your encrypted volumes to another drive.
That may seem like a hassle, but it's nowhere near the kind of hassle you are describing. I don't believe in locking myself into software that is picky about how to handle backups. These methods are robust, and really not very much trouble.
Overkill (Score:5, Insightful)
Do you live in an underground bunker, with automated blast doors and multi-layer security? I doubt it. Does anybody really care enough to defeat such measures to get into your house? I suspect you're like the rest of us, with standard locks and maybe an alarm system or a dog, or both. That is sufficient to deter all but the most determined criminals. And if anyone is determined enough, your extra security won't stop them anyway.
Your data isn't that different. Nobody is really after your data, at least not to the point of being willing to spend serious money and time getting into your system. The real threats are things like malware (which won't even be slowed down by your encrypted drive), or somebody snooping around on your hard drive after stealing your laptop (when actually they are more likely to want to just sell it).
Common sense is the best protection for most of us. Don't save passwords in an unencrypted file. Use a non-trivial password to log on to your system. Hang on to your stuff. You get the idea.