Sunday, April 5, 2015

How paranoid would you like to be today?

I've been working on new backup practices for myself. I can't say that I am finished, but I've at least thought about the encryption aspect a bit.

Encrypt my backups? Why would I want to do that? For starters I can hand an encrypted backup to someone else to store for me: A friend in Baltimore, my parents in Europe, the bank's vault, a lawyer's safe, etc. As soon as the disk is encrypted, I don't have to worry about them finding things I don't want them to find. Like my draft autobiography that may talk about them in a way they don't approve of. Or whatever.

So how should I do it? That brings me to the topic of this post. The process really depends on how paranoid I want to be, doesn't it? For starters it would be good if the disk I am using actually worked. Luckily there's a neat tool for that: badblocks. Study the man page for a bit and you come up with something like this:

badblocks -s -v -w -c 16384 -t random /dev/sdX

Note that this performs a destructive test (-w) so you'll lose all the data on the drive! It also fills the disk with random garbage (-t random), probably a plus since that'll make it a little harder to reverse-engineer things from the encrypted disk. (Note that this took about 15 hours for a 1 GB disk attached via USB2. Sheesh.)

Wait, that's a good point. A decent rule of thumb when it comes to cryptography is that you want the encrypted data to look random. But now the question becomes whether the "random" that badblocks uses is "random enough" to blend in with my encrypted data. How paranoid should I be about that? Turns out that badblocks just uses the C library, probably not cryptographically sound...

Of course help is on the way in the form of shred, a program often used to securely delete files. Now I can choose my source of randomness, /dev/urandom say. So we could use something like this:

shred --iterations 1 --random-source=/dev/urandom --verbose /dev/sdX

Great! Or is it? Don't get me wrong, the randomness is fine now, probably good enough even after just one pass, but I've at least doubled (more likely "increased by an order of magnitude" I'd guess) the time I have to spend on prepping the disk. After all, badblocks already did part of this job, right? I am probably not that paranoid. (Some of my friends might disagree?)

Even if I were that paranoid however, we have completely ignored another problem so far: We've assumed that disk drives are dumb and contain no data except for what we write on them. And that's decidedly untrue! Modern disk drives are moderately sophisticated computers in their own right and they store all kinds of data in places that a "normal write" can't ever get to. But luckily most disk manufacturers have added a S.M.A.R.T. feature called "Secure Erase" that should (in theory!) allow you to completely erase a disk back to its factory defaults. You can check out the details here but it turns out that using this feature through USB has a good chance of bricking your disk permanently.

So if I was that paranoid, I'd have to first move the drive onto an internal SATA port, then perform the "Secure Erase" process using hdparm, then perform the badblocks test, then shred the drive, and finally move it back onto the USB port.

Too. Much. Trouble.

That's what I decided anyway. I guess I am really not paranoid enough for this modern world? I am sure some people need to be this paranoid. They shouldn't have to be in a free society, but sadly that's not what we live in.

But before I get too political I'll just go back to my little backup project. I'll try to write another post tomorrow that describes the rest of it, i.e. what's needed after the disk is finally prepped according to your paranoia level.

Update 2015/04/06: I had forgotten the most basic trick to achieve a random fill that "blends in" nicely with the encrypted stuff you'll eventually store. Just create an encrypted disk, fill it up with whatever you want through the encryption layer, /dev/zero or /dev/urandom or whatnot, then start from scratch with the "real thing" as it were. Should "blend" very well. Of course it'll still take way too long for my level of patience...


  1. My main problem with encrypting the backup drives is that I'm afraid I will not be able to retrieve my backup if there are single block failures on the disk. I use mobile USB disks and store them outside the apartment in order to protect them against thieves, fire, etc.

    1. You seem to say that any single block failure would be fatal, I don't think that's how it works. Of course I may be horribly wrong about this, please correct me. But it's my understanding that you're screwed completely only if the header block that contains the key gets hosed. If that survives and some other block dies, well, you may lose parts of a file, but you should be able to get most of the rest back. I keep header block backups for the unlikely eventuality that I get an error right there.