Storing multiple sensible documents in public services

Ángel Ortega

Use case

You have a rather large set of files that you want to backup into any public storage service (like Dropbox, Microsoft OneDrive, Google Drive or similar) but you don't want them to be able to see what's in them. Many of these services say that they don't take a look of what you store in their servers. Obviously, this is a lie. Also, these sites don't mind a fuck on security and users credentials leak every now and then, so your files can end on some script kiddy hard drive and you don't want these motherfuckers to have access to your data.

Let's suppose you have a folder named world-domination-plan full of JPGs of public institution blueprints, HOWTOs for home-made virus strains and the data sheets and architecture docs for your army of robots, summing up to 5GB of data or so. Let's also suppose you use Linux, what you should for many reasons.

PGP / GNUPG (assymmetric)

The easiest way is to use a personal private/public key system like GPG to make a package of your data and encrypt it:

tar cvf - world-domination-plan/ | gpg -r bigbad@example.com -e > plan.tar.gpg

This is very convenient, as no passwords are requested and can be executed as a non-interactive process from an unattended, time triggered service like cron. Of course, you must have the public key for bigbad@example.com in your keyring. Once done (this is relative fast), you can upload plan.tar.gpg to any of the crappy services mentioned above and only users having the secret key for bigbad@example.com can extract the package contents. Please take note that you don't need the secret key in the system where you create this package (so you don't need to be the big bad, only a mook).

Extracting the package is done with the reverse process:

gpg -d plan.tar.gpg | tar xvf -

In this case, the password for the secret key related to bigbad@example.com is requested, so it's an interactive process. Of course, you need that secret key in you keyring.

PGP / GNUPG (symmetric)

Sometimes, the need of having a correctly configured GPG system with the necessary secret key is not convenient or possible (like, say, you must decrypt the package in a computer that is not your own). For this case it's easier to use classical, symmetric encryption key when encrypting the data.

This is done by typing

tar cvf - world-domination-plan/ | gpg --symmetric > plan.tar.gpg

This time a passphrase will be requested twice and, if both match, used for encrypting the package. Obviously you will need the same password in the decryption process (which is, happily, exactly the same as in the previous case):

gpg -d plan.tar.gpg | tar xvf -

The passphrase used in the encryption step will be requested.

Loopback, encrypted filesystems

This is fine, but it has some drawbacks: on one hand, you have the world-domination-plan folder always there in the clear, not only when you are using them (unless you do the cumbersome dance of decrypting / using / encrypting back / deleting the folder everytime you confabulate); on the other hand, while in the backup process, you have all the data twice, and that can be a problem if the size of the files is big. Not forgetting that, in this big dataset case, the encryption process can be long.

The solution to all these is to use a regular file, but one that contains a real filesystem — as if it was an external drive — that you can mount and unmount at will. Of course, this filesystem-in-a-file will also be encrypted, so the benefits above still apply.

First you have to create a file with a size that will be enough to store your current and foreseeable data (think about this size wisely; it's not easy to resize it if you fill it). Let's say it's 6GB. Create it this way:

dd if=/dev/zero of=plan.img bs=1M count=6000 status=progress

This will create a file named plan.img (full of zeros) with 6000 blocks of 1M of size. It may take a while.

Now, using the cryptsetup tool, you must format this file as a LUKS encrypted volume:

sudo cryptsetup -y -v luksFormat plan.img

This will ask for your password (for sudo, as this is a privileged operation), an explicit confirmation (this is a destructive operation on the possible contents of plan.img) and twice the passphrase that will be used for encryption.

The following step is 'opening' the encrypted volume (take note that it's still unable to store anything):

sudo cryptsetup open plan.img the-plan

This will map plan.img to a new block file named /dev/mapper/the-plan. The passphrase used in the formatting process shall be requested.

Now you can create a filesystem inside this new block device:

sudo mkfs -t ext4 /dev/mapper/the-plan

It's ready. Close everything:

sync && sync && sync && sudo cryptsetup close the-plan

Please take note that you only have to perform this fuckton of cumbersome steps once.

The usage is similar. To mount the storage in a temporary directory:

mkdir -p world-domination-plan-tmp
sudo cryptsetup open plan.img the-plan
sudo mount /dev/mapper/the-plan world-domination-plan-tmp

The world-domination-plan-tmp folder is where you must store all your work. The root folder in this loopbacked filesystem is by default owned by root; you most probably want to change its ownership to you (only necessary once).

After working, do the reverse:

sync && sync && sync
sudo umount world-domination-plan-tmp
sudo cryptsetup close the-plan
rmdir -p world-domination-plan-tmp

You may be an evil genius, but may also be an old fart like me that cannot remember all this magical crap, so you'll automate it by creating beautiful scripts.

Now you have your portable plan.img that you can backup everywhere you want. An interesting feature is that, being a file system, the total content of the file don't change much after each usage, so it can be copied efficiently through the network by intelligent syncing tools like rsync. The GPG'ed tar files in the first examples are completely different on each session so they do not benefit of syncing copy programs.

Other remote storage ideas

If the file has a reasonable size, you can have cheap storage by emailing it to yourself to a Gmail account or similar. Or, even better, by storing it as an attachment of a Draft message in one of these webmail accounts. I've heard some primitive boogeymen communicated this way: through draft messages in a webmail account with credentials known by all of them (data do not leave the servers, so it's more difficult for James Bond's sweatshop spy network to eavesdrop them).

End notes

Dexter uses all these encryption techniques for his own world domination plan, so he can dream of new ways of inflicting pain from his warm lair without worrying about enemy agents and other fuckers.

Meet the new boss.

Remember that you don't need to be a world dominating son of a bitch to require privacy; many people will insist that you only need it if you have something to hide. Don't trust them.