Bolt-On Security the Linux Way

As longtime readers know, while I try to stay knowledgeable on the many sub-disciplines of information technology, my passion is for information security. Since it’s been a while since I’ve contributed any InfoSec know-how, I wanted to rectify that. I couldn’t have timed this realization better because (as you’ll see) the techniques on display are perfect for protecting your deluge of tax season documents.

In this piece, I aim to provide a range of simple but effective options for encrypting a small number of files. In particular, these options are salient for use cases like tax filing, where users are sending sensitive documents to recipients with an unknown degree of technical proficiency. Fond as I am of PGP, I’ll bet you your refund check that your accountant doesn’t know the first thing about using it.

Before going further, I’ll note that all of these file encryption techniques require you to use an additional channel for transmitting shared secrets, primarily passwords. The file will be sent through one pre-agreed channel, while the means of decrypting it will be sent via another.

There are too many viable auxiliary channels to enumerate, but just make sure that you take reasonable steps to pick one that isn’t easily compromised. The fact that you are using an additional channel is itself protection against the file’s compromise: without it, sending an encrypted file and its decryption password on the same channel creates a single point of failure. Using two channels requires two successful attacks by your adversaries to fail.

Let’s start at the lowest complexity (and security) technique and go to the highest. Some later entries are for the hardcore security types, but there’s something for everyone.

Encrypted ZIP, CLI style

My life changed forever when I learned that I could encrypt ZIP archives. What makes ZIP encryption so useful is the sheer ubiquity of ZIPs. Practically every system can process ZIPs, and all those that do can handle the encryption.

The interface for decrypting them is breathtakingly simple: the user clicks on the ZIP, a window pops up prompting a password, the user enters the password, and the ZIP commences extraction (assuming the password is correct, of course). This makes ZIP encryption ideal for transferring files to recipients whose technical competency can’t be ascertained.

There’s a graphical interface for zipping files, sure, but the command line interface (CLI) kicks the ease and efficiency of the process into overdrive. You literally run the “zip” command with the “‐e” flag, the name you want the archive to have, and one or more existing files that you want to encrypt and compress, all delimited by spaces:

zip ‐e archive file1 file2

Once you run the command, a prompt will ask you to enter and confirm a decryption password. Write it down because that’s what you’ll need to share with your recipient to open the ZIP. You can shred/incinerate the paper later, just write it down.

There are some technical points worth covering. First, the original files are not altered. The “zip” command automatically compresses and encrypts copies. Second, the names of zipped files are readable when opening the archive even before decryption. Therefore, the encryption won’t protect any sensitive filenames against anyone who obtains the ZIP, password or no.

Assuming you’re okay with these caveats and have performed the above steps, the last step is to send your recipient the file and the password by separate means. An attacker needs both pieces, so make it as hard for them to do so as reasonably possible.

OpenSSL: Not Just for Browsers Anymore

For those who want security that’s a cut above the humble encrypted ZIP’s, you can whip out OpenSSL. For Linux users, their system puts this in easy reach with the pre-installed “openssl” package. Like with encrypted zipping, you can encrypt your file using OpenSSL with a single command:

openssl aes‐256‐cbc ‐a ‐salt ‐in file ‐out file.enc

Let’s break that down.

• “aes‐256‐cbc” is the cipher being used. Unless you have strong opinions about ciphers, use that one.
• The “‐a” flag encodes the output to base64, which is important if we want other programs to play nicely with the encrypted output file. The alternative is a binary file, which email services and other programs flag as a security risk (ironically, in this case).
• The “‐salt” flag adds a random value to the mix to decrease the chance that an attacker who knows something about your encryption practices can break it. “openssl” also warns you to never ever not use salt, so there’s that, too; and,
• As you sharp readers can intuit, “‐in” specifies the input file and “‐out” sets the target output filename. You can technically name your output file whatever you want, down to the file extension. However, just make sure not to name it the same as the input file, or your output will overwrite your input.

On running the command, it will ask for a password twice. Again, record this somewhere so that somebody can decrypt your file. Decryption is just as easy. Just hold the salt and pass the “‐d” flag for decryption. Obviously, this time the encrypted file is the input, and a decrypted filename is the output:

openssl aes‐256‐cbc ‐d ‐a ‐in file.enc ‐out file.new

Again, you can name the output file whatever you want. Just like with the encrypted ZIPs, you will want an appropriate secondary channel for transmitting the decryption password.

For Overachievers, There’s Always PGP

Geared toward the real InfoSec nerds out there who don’t mind extra work (and have friends who don’t, either), there’s PGP. These steps, therefore, assume you and the file’s receiver know how to work it. I won’t get into those details here, but fortunately for you, I already did previously.

To use PGP file encryption, the recipient needs to have a PGP key pair. Technically you don’t, just to send the file. But if you expect a file in return securely, you’ll need to have a PGP keypair yourself.

Unlike with encrypted ZIPs and OpenSSL, where the sender performs the encryption and then transmits the file and shared secret to the recipient, with PGP, the file recipient must send the sender their public key before any encryption can happen. If the sender wants to sign the file, they’ll need their own keypair so they can give the recipient their public key.

Intricate as this dance is, there’s one big advantage: its asymmetric key structure makes exchanging keys way safer since attackers can’t break your encryption from the public key. This affords you flexibility in your key exchange. You could both upload your public keys to a key server and call it a day.

If you’d prefer if the whole world didn’t know you have PGP keys, you can trade public keys over another encrypted platform. Of course, if you really don’t want your public keys touching the internet, you can exchange them in person. Then again, if you could do that, then why not just exchange your file at that point?

With all that out of the way, it’s time to actually encrypt. There is a stream of flags to decipher here:

gpg ‐o outfile ‐e ‐a ‐r recipient infile

• The “‐o” flag and its associated “outfile” specify the filename of the finished product. Name it however you want, but I suggest including a suffix to remind you it’s encrypted.
• The “‐e” flag directs GPG to do an encrypt operation.
• The “‐a” flag makes GPG encode the encrypted output in base64, just as that flag does in “openssl”.
• “‐r” and its “recipient” determine whose public key gets used. This is important because PGP uses a public key whenever it encrypts, and only the holder of the public key’s sibling private key can decrypt that encryption. Specify the recipient by their public key’s associated email address. Finally, you have to point to the file to be encrypted.

The decryption command is much simpler:

gpg ‐o outfile ‐d infile

The recipient passes the “‐d” flag for decryption, chooses what to call the output, and sets the input. That’s it.

Between these three techniques, you have everything you need for hours of cryptographic fun…and sound sleep knowing your files are safe. Happy ciphering!