Nov 03, 2012

Symmetric Encryption on the Command Line

I'm a big proponent of taking personal security measures when interacting on the internet. I sign all my emails using my PGP key so you know it is from me and not a virus, spammer, or a stolen account. I encrypt my netbook's hard drive and keep a pretty tight firewall. For the most part I like to keep everything under lock and key because you just never know who might get your info and what they might do with it.

What if you don't want to go through all this work. Without a Public/Private Key you can still use Symmetric Encryption to send files and emails and store data on your computer with an increased level of security. All possible with a few utilities found on most *nix systems.

OpenSSL

Everyone has used SSL if they've gone to a site starting with https. Pretty much ever BSD and Linux flavor out there contains a /usr/bin/openssl. Typically used for generating keys for networking, we can encrypt files with just a few flags.

openssl enc -aes-256-cbc -salt -in msg.txt -out msg.enc

The following line encrypts msg.txt using a salted 256 bit AES Cipher-Block Chaining algorithm and stores the result msg.enc. Or to put it in simpler terms...the text file is broken into pieces, each being used as part of the key to encrypt the next block. This command will prompt you for a password that you must enter twice. This is your key to decoding the file so as long as both parties know to use the same key you can decrypt the message.

The output from this line is in a binary format which makes it difficult to deal with outside of just storing it on a drive. So adding a -a flag the output is stored in Base64 (i.e. text you can read) which makes it easy copy and paste into an email.

To decrypt the command its pretty much the same.

openssl enc -aes-256-cbc -d -in msg.enc -out msg.txt

The -d flags causes the decryption. And if you used Base64 then add the -a flag here too. Again, you'll be prompted for a password and out pops the decrypt message.

OpenSSL: Scripting and Options

If we want to make these actions a little more useful we can add to our .bashrc (or the rc file for your shell of choice) two functions.

function ssl-encrypt
{
  if [ $# -eq 2 ]; then
    openssl enc -aes-256-cbc -a -salt -in $1 -out $2
  else
    echo "usage: sym-encrypt <source> <destination>"
  fi
}

function ssl-decrypt
{
  if [ $# -eq 2 ]; then
    openssl enc -aes-256-cbc -d -a -in $1 -out $2
  else
    echo "usage: sym-decrypt <source> <destination>"
  fi
}

Now we can call ssl-encrypt msg.txt msg.enc which will prompt us for our password twice and we are done. I've added a little edge testing to make sure you enter only 2 parameters.

Other options are available for the algorithm used for encoding/decoding. Options are available by running openssl list-cipher-algorithms. Just make sure that the person on the decoding side knows what algorithm you selected to encrypt. You can also add the flag -z to compress the file using zlib.

OpenSSL: Pros and Cons

OpenSSL is found on pretty much every system out there so no need to set anything up. It comes with a huge range of cipher algorithms and a pretty good set of options if you want to tweak out your encryption scheme.

A half up side/half down side, the encrypted files generated by OpenSSL do not contain a Magic Byte allowing your OS to detect what the file is. This is good in the sense that it comes off as just a file of random garbage, but on the down side it comes off as just a file of random garbage. If someone gets the file and doesn't know what it is then your data is safe. If you are sending it to a friend to decrypt, they need to know that the file is encrypted, the algorithm used and the password.

GnuPG

Another option for Symmetric Encryption is GNU's implementation of PGP. Typically used Public/Private Keys for Asymmetric Encryption, GnuPG can be used for Symmetric Encryption too.

gpg --cipher-algo AES256 --symmetric -o msg.enc msg.txt

Implementing the same 256-bit AES Encryption algorithm we can create our password protected file in a single line. This makes a binary file that doesn't work well for text editors or email clients so adding the -a flag makes the output ASCII Armored.

Decryption is a little bit easier than with OpenSSL.

gpg --decrypt -o msg.txt msg.enc

No additional flags are needed to identify the algorithm or if it was compressed. Pretty simple.

GnuPG: Scripting and Options

Though the list of algorithms possible for GnuPG are slightly smaller than that of OpenSSL, the couple major ones everyone uses are provided. Additionally, compression can be performed using either zlib or the slightly better bzip2 algorithm, both allowing for compression levels.

Here is our scripts again for GnuPG.

function sym-encrypt
{
    if [ $# -eq 2 ]; then
        gpg --compress-algo BZIP2 --bzip2-compress-level 9 \
            --cipher-algo AES256 \
            --symmetric -a -o $2 $1
    else
        echo "usage: sym-encrypt <source> <destination>"
    fi
}

function sym-decrypt
{
    if [ $# -eq 2 ]; then
        gpg --decrypt -o $2 $1
    else
        echo "usage: sym-decrypt <source> <destination>"
    fi
}

I've added support to compress with bzip2 with a high compression level and ASCII Armored it as well.

GnuPG: Pros and Cons

As with OpenSSL, GnuPG is found on pretty much every Linux System out there. Some systems may not come with it pre-installed but you can find it in every repo. Depending on the build options, GnuPG has just about the same number of Cipher Algorithms available.

Unlike OpenSSL that puts no Magic Byte in the encrypted file, GnuPG (or any OpenPGP application) generates an output file containing fingerprint information about the encryption and compression used. This is good in the situation where you send a file to your friend. They can check the Magic Byte, see that it is an OpenPGP generated file and by only knowing the password, decrypt it. No need to know the compression or cipher algorithms used as that information is stored in the file. On the down side, this makes it slightly easier to first a) detect that the file is encrypted data and b) know enough information to start the cracking process. Since you are using 256-bit AES, hopefully with a good password, there really shouldn't be a worry about giving this cipher information away.

This message will self destruct in...

Whenever working with encryption its important to remember that clear text versions of your data exist and can compromise the purpose of your endeavour if found. If you keep an encrypted text file of user names and passwords, you should make sure to destroy the decrypted version after you are done using it. Most Linux systems come with the shred utility that overwrites your data and renames your file many times to attempt to remove all signs the file ever existed.

You have the option of defining the number of times random data is written to your file. I tend to use a bit of overkill on this one...

shred -vuz -n 128 msg.txt

This will write over the file's entirety 128 times, writes zeros over the data at the end to attempt to hide the shredding process and removes the file when complete.

Get out there and start hiding your data

Some additional things you could do are create scripts to tar a directory, encrypt it and then shred the files inside. Or create a password wallet that decrypts, prints to the screen and then shreds all in a single command. There are tons of places you can script in encryption to make your daily computing life a little more secure.

For the most part I tend to use the GnuPG solution because I use GnuPG for Public/Private signing of my email and source code. I also like the fact that it doesn't look like complete garbage data. If I wanted to store data in the wild and make sure no one knew what it was then I might use the OpenSSL option. In the end, both have the same algorithms and most of the same features. The important part is that you use encryption.

Commented Code ...blog