Encryption is the application of cryptographic techniques to encode data so only authorized users can read the information. With the ubiquity of UNIX-based operating systems like Linux, BSD, Solaris and Mac OS X, users of these operating systems have ready access to a slew of different encryption options, giving them the ability to protect their data and communications from prying eyes.

While many options exist for other platforms, like Windows, this article focuses on Mac OS X and will hopefully provide some basic information on how you can learn to encrypt and decrypt your own personal data from the command line. Most of what will be discussed also applies to Linux and other UNIX-like operating systems. We’ll also go over the fundamentals of Secure Shell (SSH) and how you can use it to transfer data that is encrypted, end-to-end, between your computer and any servers you have access to communicate with.

Encrypting Files

First, let’s take a look at three different options that allow for the encryption and decryption of your files; two of which are built into Mac OS X and a third that’s available as a free download of Open Source tools. Almost everything we’re going to cover requires you use command line access to your computer, provided by Terminal.app or any other terminal-capable applications. You’ll find Terminal.app in /Applications/Utilities/ Fire it up and you’re ready to roll.

.ZIP

You may already be familiar with “zip”, a lossless means of archiving files, originally developed by Phil Katz of PKWARE. Chances are good that at some point you’ve either downloaded a “zip” archive on the Internet or created your own zip archive for upload or transmission to someone else. In Mac OS X’s Finder.app, the option to “Compress” a file or directory creates a simple archived .zip file which is unencrypted and can be opened by anyone with a copy of said archive.

However, over time .ZIP has become more robust and from the command line, has an added feature of being able to create a password-protected archive. This archive can then only be opened by someone with knowledge of the password used to create the archive. Creating such an archive is simple and can be done as follows:

To encrypt a file with ZIP, use the following format:

zip -r --password [yourpasswordhere] EncryptedZipYouAreCreating.zip FileOrDirectoryYouWishToEncrypt

As an example, if you’re in your home directory and have a directory called “foo-data” that you want to create an encrypted ZIP archive of named “encryptedstuff.zip”, setting it up with a password of “Pupp13s4ndK1tt3nZ”, you would issue this command:

zip -r --password Pupp13s4ndK1tt3nZ encryptedstuff.zip foo-data/

In order to decrypt the archive and open up the contents, you simply run “unzip” on the archive, which will then ask you for the password needed to decrypt the archive.

unzip encryptedstuff.zip

Provided you enter the correct password, it will create a directory called “foo-data” and populate it with the contents of the original “foo-data”. If you do this from the same spot where “foo-data” already exists, unzip will ask you if you want to overwrite the existing foo-data, or rename the unzipped directory to something else.

The symmetric encryption algorithm used by ZIP isn’t very strong and is vulnerable to dictionary attacks. ZIP encryption may prevent your average computer thief from accessing data you’ve encrypted, but it won’t stop a dedicated, knowledgeable attacker or a large federal agency from breaking the encryption.

As such, you’re probably better off using something more capable to protect data you really want to keep to yourself.

OpenSSL

OpenSSL is a software library used by other applications to provide secure communications between computers. It’s used by a variety of other software like web servers and browsers in order to allow encrypted connections between them.

When you see the little lock icon indicating that the store you’re buying something from is a “secure connection” between your browser and their server, OpenSSL is most likely providing that security “under the hood.” OpenSSL also has a set of command line tools you can use to encrypt your own data on your computer and it offers a variety of algorithm options for this use.

Let’s go over a couple of options for encrypting and decrypting files with “openssl”, the binary installed with the OpenSSL software library. The two variations will show use two different encryption algorithms; AES 256 and Blowfish.

In order to encrypt a file with AES 256, you issue the following command from your shell in Terminal:

openssl enc -aes-256-cbc -in unencrypted_file -out encrypted_file.dat

To use the Blowfish algorithm, you would issue the command as follows:

openssl enc -blowfish -in unencrypted_file -out encrypted_file.dat

In both examples, “unencrypted_file” would be the name of the file you want to encrypt, while “encrypted_file.dat” would be the name of the encrypted file that results from the process. I’ve chosen the suffix of “.dat” somewhat arbitrarily; you can name this encrypted file whatever you wish, as it doesn’t really matter what the file name is.

In order to decrypt a file encrypted with AES 256, you would issue this command:

openssl enc -aes-256-cbc -d -in encrypted_file.dat > unencrypted_file

To decrypt a file encrypted with the Blowfish algorithm, the command would look like this:

openssl enc -blowfish -in encrypted_file.dat > unencrypted_file

There’s some merit in giving the output encrypted file an innocuous name, like “recipes.doc” or something else that would appear to be a boring file that someone wouldn’t automatically assume contains any interesting data. It might be overlooked by someone scouring your hard drive for “important” data that you saw fit to encrypt, in order to prevent their prying eyes having access to it.

The method we just documented will require a password or passphrase be entered at the time of encryption, then re-entered for verification. Provided you and anyone you want to have access to the file, know the password or passphrase, your file will remain secure. However, it will only be as secure as the password or passphrase, itself.

If you keep a plaintext file with the password or phrase on your computer, you can expect anyone accessing your computer may also gain access to the password or passphrase, at which point they can easily decrypt your file. If you write the password or passphrase on a post-it note and keep it in your desk drawer, your security level has dropped as well.

Both AES (Advanced Encryption Standard) and Blowfish are symmetric block ciphers that utilize a single “secret key,” which in our examples is the password or passphrase you create when prompted. A more secure method of encrypting a file with OpenSSL would be to use a public/private key pair to generate the encrypted file. While we won’t be going into that in this article, we’ll definitely cover it in the future, along with some other more complex techniques for encrypting and securely transferring data.

GnuPG

The Gnu Privacy Guard, or GnuPG, is an open source software library built as a free implementation of the OpenPGP standard encryption suite. It doesn’t ship with OS X, but installation of the tools is straightforward enough and well documented at the GnuPG site. It exists for Windows, OS X and Debian Linux, as well as a slew of other operating systems.

GnuPG tools installed on OS X integration with the Apple’s Mail application, allows for user-friendly (well, relatively user-friendly) public/private key generation, implementation and propagation. GnuPG also installs command-line tools that allow for encryption of files from a terminal session, much like we’ve looked at with ZIP and OpenSSL.

In order to use GnuPG’s binary tool to encrypt a file, the syntax is straightforward:

gpg -c unencryptedfile.txt

After you’ve entered that command telling GPG to encrypt your file named “unencrypted.txt”, the resulting output will be another file named “unencrypted.txt.gpg”. As usual, you can name or rename the file whatever you like. In order to decrypt the file, the syntax is equally simple:

gpg unencryptedfile.txt.gpg

It will then require the password used to encrypt the file and will output the decrypted file in the directory you ran the command from.

OpenSSH

OpenSSH is a set of network-oriented tools focused on providing secure, encrypted communications between any two or more computers. This allows for remote administration and login, file transfer and tunneling, all with network traffic encrypted, rendering it useless for anyone who manages to intercept the data. Tatu Ylönen first created the SSH protocol in 1995 and eventually OpenSSH forked from the original SSH suite. Most SSH implementations these days are based on the OpenSSH suite, but what exactly does SSH actually do?

In the days before SSH, users that were logged into one computer could login to a remote computer using tools like “telnet.” However, Telnet passed all data between those computers in plaintext, including any passwords used to login. As a result, anyone who managed to intercept the data between those two computers could capture the user and password information, as well as any other data.

They could then use that information to gain access to systems that weren’t theirs, or outright steal data transferred between systems. Obviously, this was a problem. SSH solved this problem by using symmetric encryption between any two given servers and in the case of private/public key pairs, asymmetric encryption for authentication of a user of a system.

The most rudimentary use of SSH is to invoke an ssh session as follows:

ssh username@remoteserver

For this to work, the computer noted as ‘remoteserver’ has to have sshd running, which listens on a specified port for incoming connections from other computers. By default, port 22 is used for ssh, though it can be configured to run on other ports by an authorized administrator of a system. After the initial connection is made, a protocol is negotiated by which the connection between the two systems will be encrypted, after which the user (username) is authenticated.

Without setting up a public/private key pair, this is done by the remote server asking the user to enter the password for the remote system. If the user provides the correct password for the remote system, he or she is then granted access whatever shell access is configured for the account.

Secure Copy, or ‘scp’, is a utility for transferring files between systems under the same encrypted connections generated by ‘ssh’. The syntax for sending a file, say “stuff.zip”, to a remote computer named “whatever.org” by a user named “mns” would be as follows:

scp stuff.zip [email protected]:~/.

Again, without setting up private/public key authentication, the remote system (in this case “whatever.org”) would require user mns provide the appropriate password for account ‘mns’, at which point the file ‘stuff.zip’ would be transferred, bit by bit, over an encrypted connection. Anyone who had access to the data flowing between the two computers wouldn’t be able to reassemble “stuff.zip” in an unencrypted form, thus preventing their data from being usefully intercepted.

Public/private key pairs make both ssh and scp easier to use, with only the additional step of the generation of a pair of keys. Additionally, if the public/private key pair is set up without a passphrase, proper configuration allows for user authentication without the use of a password or passphrase.

In order to generate a key pair, the ‘ssh-keygen’ tool is used. Here is an example of how to generate a key pair:

ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/mns/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/mns/.ssh/id_rsa.
Your public key has been saved in /Users/mns/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:SsRzYo9nn/sJr8lcnTcKp7GpAGr0CUTniWkkGHGJXu4 [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|+=.+ .           |
|o.=.=..          |
|. o= o* .        |
| .o. o *         |
|  .o .o S        |
|  .E+.o+ . . . . |
|   o o..  +o..o..|
|  .     .o *B....|
|         .B*+.   |
+——[SHA256]-----+

By default, the key pair is generated and saved to the .ssh directory in the user’s (in this case “mns”) home directory. ssh-keygen generates two related keys; id_rsa.pub (the public key) and id_rsa (the private key). In this example, the “-t rsa” tells ssh-keygen to use the RSA algorithm to generate the key pair. SSH allows for other algorithms to be used as well. AES, DES and Blowfish are a few options you could use instead.

The public key, id_rsa.pub, must then be put in a directory named “.ssh” within the home directory of the user account on the remote system, in a file named “authorized_keys”. An “authorized_keys” file may contain a number of public keys, but we’ll deal with that more in a future article.

Here is what the public key actually looks like:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCrZS01qKy5GuC7ayTsY9nNm7hGIQEjSBI+5y
zkInTEEHw0w+yKgjoNHaxPTsi7z27LTiFeBkAoIUSb12o2Eq5fYflbfkH+gN5dIHIy
L6eTJ3/b48v5SZ+/cgyGlVdhbZxPn5w5o3YEDFj9vhOQICrqnA6KV/qlg5EeI
/f11nw+gbSyelD5vrrhimzyNtg/N/IPeDOiYGZBpc86TLXjW9Zhx82Qa1R3Zjrz
/9WQ/2yRfXu26VNnxfaW1G0lvYLSIJSMuQbWgrL9O9S6Q8TaHrW8JnFMEM6Vx+laKj
i5CGwWa2O7TUxHwqlFdkQPG+dLfGMoBculhheutEpYkDmRrwR9 
[email protected]

Now, for this article, I’m going to show you what the private key looks like. Before I do that though, I want to emphasize that the only reason I am doing this is for demonstration purposes. The key pair I generated for this demonstration is not one I will ever use in real life and in fact, will be deleted by the time this is published.

There’s an absolutely crucial point I want to make about private keys here; NEVER, EVER DISTRIBUTE YOUR PRIVATE KEY TO ANYONE, EVER, FOR ANY REASON. The nature of public/private key pairs is such that a public key can be used to encrypt data that only the corresponding private key can decrypt. Therefore, the public key can be distributed fairly freely, but the private key should be guarded heavily.

Think of it this way; asymmetric encryption is roughly like having two keys for your home. One key allows people to lock your doors, but not to unlock them. The other key allows them to unlock your door. It’s sort of a strange analogy, but it helps to emphasize why you wouldn’t want to freely hand out keys that unlock your home, where keys that only lock it would be significantly less of a security concern.

That said, here is what a private key looks like:

-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAq2UtNaisuRrgu2sk7GPZzZu4RiEBI0gSPucs5CJ0xBB8NMPs
ioI6DR2sT07Iu89uy04hXgZAKCFEm9dqNhKuX2H5W35B/oDeXSByMi+nkyd/2+PL
+Umfv3IMhpVXYW2cT5+cOaN2BAxY/b4TkCAq6pwOilf6pYORHiP39dZ8PoG0snpQ
+b664Yps8jbYPzfyD3gzomBmQaXPOky141vWYcfNkGtUd2Y68//VkP9skX17tulT
Z8X2ltRtJb2C0iCUjLkG1oKy/TvUukPE2h61vCZxTBDOlcfpWio4uQhsFmtju01M
R8KpRXZEDxvnS3xjKAXLpYYXrrRKWJA5ka8EfQIDAQABAoIBAAy5IQcHs3K2RRKE
nKQTsXpq4d4K2yvEUN5siM+Sozpewumj1a5ehnKszjrA7XPLrTzYWu/A5QhVl+M9
tXu4HUulWT5qe/mplVgybWe+U+E/oGUxXtXtmjc6/yUKdwcbfOwIPC+nK76XMA/+
CTO8v5LU7NtmNowM3TvwjZqpRmXZWfV3xkwpVbJm6LXaRjEVyRP6ElbFGXSQev6Y
uBDT8Rxxq3NWGaiQDvVcegcObf3whcRY6TQgbcOOjtAxcVuEagcPvEJ61504qFF9
qB+h1XSvTlI0HGt3ZV5fYSg/ho/JkicKVlvOCQvyhcqOSMJ99ZxpcD4lxwohPsFA
pZ3iMD0CgYEA1vooM2DybclUImbJ1yVBBs2PKBIfp/NrNgIwz12ZO6wUf43KJ1/H
6jbLd/bn7Iu+Zp1ChP0AujlgOv8EJBNYFTBOlRmhOFLoXDTZoUhVOTUtSssJrlfQ
fIuTvhsu/9hYgfkVYgj4a5HyIftrjYl2pvCRAZsBA+IuLuqTjfRyuG8CgYEAzBn/
uU4YjluxUAeckjXoSCVG2fNQkgQ/W4so3Oqvt3kXw2gon0wLKQp7RyhNOSzr+75s
lCn2BWCKpT74Ay/uCkE5LKKrly60ogf30HdSMMdXSeQXCYg5XhXZfWzSzXgbg8xm
rIN98uAbzMZHnmMb/QafHU8VZ/88O9Fd0K8Vj9MCgYADSJTenAd359BSKjHBCH+i
w/cAzK4RGaW0kHoAYNSbVbiGbjr9OPhLuoSHE41dTpEc7h/6+gZN0dyHaie9CVKa
GD/LBTYyLwn/hosgbINouUg00T8Xm53CmTsrdyzTmZFYgt5xveNVeUgyfq2Y3tWi
HSCJ3r04OvcrnkecrnQmHwKBgHq7M5RJiuin6KLYQOWG9wvTJpzO/GchmLvCnari
kRGCBrEhhDPuNVPTkrgCWxWDltAF/SLHbMJlAFpH2DmKa9jMycW2d/psQoCgy/sW
lVzxseKj/tpjiSOzfdo3Qzf8/oatthwM4gLXkr/7h3uN23m2rp2gPZ4Q1DagOorP
jeazAoGAYEVPEEct4rcO9/vREd5V6asmYtbOgc9uLaJ5c1S+ZWBg145mt65dnnl3
t2zrxC+cAkWIGQW005xKcDBlhnX6kYTGp5DW+wv4g4LgZftJtkXoog34qpJkUkvS
W1LHcpAT4S2CsLlw5oKBpYhxVEN88erBVBSRz7UWyW6NFO+oCKo=
-----END RSA PRIVATE KEY-----

On the server side, it’s often a common practice to require authorized users gain access with the use of public/private key pairs. This allows an administrator to more tightly control access to the system to only authorized users.

How Does Any Of This Apply To You?

Encryption is your friend. Encryption may not completely protect you from entities who want to access data you may consider to be personal, secret or otherwise worth obscuring. Encrypting data you don’t want freely distributed in the event a bad actor takes your computer, or gains access to it from outside your home or workplace, makes using that information against you prohibitively costly in terms of time and effort. What sort of information might you want to protect? Tax forms, checking account details, any file with personally-identifying information, your contacts list or anything you wouldn’t just print out and hand to anyone who passed you by on the street is something you should at least consider encrypting.

I routinely make backups of various documents and data I don’t want to lose. I copy these documents to an external hard drive, or use scp to send them to a computer on my home network for storage, in the event my laptop dies. However, I encrypt all of this data, so that if someone breaks into my home (and somehow miraculously avoids death at the jaws of my twenty pound furry guardian) and swipes either one of those external hard drives, or the machine I copy the information to, they will end up with gigabytes of data that is completely useless to them. It’s bad enough to contemplate losing the physical goods; you don’t want to deal with identity theft (or worse) for months or years afterwards.

In this article, we’ve only barely scratched the surface of the subject of encryption. There are many options of varying utility that can be used to protect your data from prying eyes and the actual mathematics behind these techniques and technologies is complex and for me, fascinating. As is the history behind their development. This complexity, however, shouldn’t prevent people from using the tools that may already be installed on the computers they use on a daily basis to protect the information they need to protect. Hopefully you can use some of the techniques described, or use this article as a jumping off point to find techniques that will work to protect your own data.

Editor-in-Chief’s Note: Matthew Sharp is a Plank Owner and Life Member at ITS and goes by the username “viator.” He lives in The People’s Republic of Northern California and enjoys long range shooting, carrying heavy objects great distances and fuzzy little puppies.