Tinkering with file encryption

Storing files overseas or “in the cloud” has become somewhat of an issue lately with spying activities of various nations. I think we’ve just seen the top of the iceberg, but at the same time I hope I’m wrong. In any case, cheap cloud storage is just to good to give up just because of unethical practices by governments. And although I think I don’t have much to hide, I’d like to keep my files private and only share when I decide it is appropriate to share any of them. That should be part of basic human-rights and therefor non-negotiable, but apparently some governments think and act otherwise. I’m sure a lot of people are wondering on how to protect their data, and so am I. This post is about basic file encryption.

Local file storage is practically always running low, and storing files in the cloud seems ideal: it’s available wherever I need it, and I don’t have to worry about disk replacements and offline backups. One big downside of cloud storage is the time needed for up- and/or downloads. Second: Most free cloud storage limits files up to a certain size, up to few Gigabytes. TrueCrypt is documented to work, despite those drawbacks, but I took a different approach: Simply encrypt the files and upload. As I don’t need to access my files on any device, I find it perfectly acceptable to first download and decrypt them before I can use them. This clearly may not be the case for everybody.

Suppose I have a bunch of files that I want to upload. Encrypting every file with one and the same password over and over again is not really secure. In fact, any password that I may think of is very likely to be weak, even when it is unique for each file. It would be better to have a password that is not only unique, but random, long and strong, that can quickly be generated. It wouldn’t be realistic to memorize those random passwords, and certainly not for every single file. The most obvious solution to that problem would be to store every password in an encrypted password file.

After some tinkering on the command line with OpenSSL, which on the command line just is a big bunch of nifty encryption functions, this can be done fairly quickly. This is how you generate a random string of characters, base 64 encoded, so that it only contains printable characters:

openssl rand -base64 30

File encryption can be done like this:

openssl enc -a -z -aes256 -k <random> \
    -in ~/Pictures/DSC_1509.JPG -out ~/jpeg.enc

…And decryption likewise:

openssl enc -d -a -z -aes256 -k <random> \
    -in ~/jpeg.enc -out ~/dsc_1590.jpg

Putting all this together resulted in the following two shell scripts, filecrypt and filedecrypt.

As in the previous command line examples, both scripts use 256 bit strong AES encryption, which is currently considered one of the most secure encryption algorithms. The password used for encryption is a 1024 byte long random string. That secret is stored in a password file. The password file contains the name of the file, the password, two different “fingerprints” (a cryptographic checksum; a hash value or message digest) of the original file, and one of the encrypted file. The latter is used to match the password in case the filename was altered. The checksums can be used to verify the decrypted file, just in case you want to double check that you got your original file back. 

The password file is also encrypted with AES 256 and a generated random password, although it is not that long as I assumed the password file to be stored locally.

Here’s how to use both scripts: Download them, make them executable by opening a terminal and ‘chmod +x’ on both files. Both scripts have a manual built in, which you can view when executing them (in a terminal) with the -h parameter.

Epilogue

When I started to play with encryption and files I tried different ways of generating the password used for encryption. The two scripts in this post were the most usable results, although both still contain bugs and may not handle filenames with special characters properly. But from a usability point of view this is still nowhere near perfection: The scripts would benefit from an integrated in “encrypt and upload” & “download and decrypt” function. Second: The trustworthiness of OpenSSL has recently become debatable, and although fairly well documented should perhaps be tested to be really sure. Perhaps LibreSSL can fill this gap some day. Third: This is still command line work, a GUI is a requirement these days. If you think you can fix this, then please do so. And please share the result!

Some may still want to share files, but use encryption anyway. This can achieved with these scripts as well, but may be somewhat of a hassle: You will have to share the password file and the password that protects it. Sharing that file may be difficult, which you would typically do without any cloud service. Sharing the password even more so…

This entry was posted in Crypto, FreeBSD, IT Security, Mac OS X, Shell script and tagged , , , , . Bookmark the permalink.