Roland's homepage

My random knot in the Web

Using encryption

Privacy is a basic human right. However, there are those that would violate those rights. Encryption is a way to keep such people out of your data.


When I started writing this page, it was about how to use encryption on FreeBSD. During the writing process I realized that a lot of what is written here is applicable on other systems like Linux and OS X as well, so I changed the title. :-) Those pieces that are specific to FreeBSD are marked as such.

What is encryption?

Encryption is a process that uses an algorithm to transform information so that it becomes unreadable for anyone who does not have a key to the information. It is a part of the discipline of cryptography.

Why use encryption?

Basically, I use encryption to protect my privacy. In this age of networked and portable computers it has become relatively easy for someone to peek in the files stored on your computer/laptop/netbook, especially if they are lost or stolen.

According to Article 12 of the Universal Declaration of Human Rights, your privacy is a right:

No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.

For us Europeans, this is codified in Article 8 of the Convention for the Protection of Human Rights and Fundamental Freedoms.

In my opinion sharing knowledge is a very good thing, as is giving back. That’s why I release the source code for own my programs under the simplified BSD License. It is also the reason that I wrote and maintain these pages; in the hope that they are useful to others as software and information provided by others has been useful to me.

But my data is nobody’s business unless I choose to share it!

A note on choosing passwords

Encryption software requires a password or -phrase and/or a token to decrypt material so you can use it. It is important that these passwords remain secret, and they should not be easy to guess.

  • When using a password, use at least eight characters but preferably more.
  • Do not only use lowercase letters. Also use at least one or more capital, digit and punctuation character.
  • A password of randomly generated characters is probably best, but these can be hard to remember. Use these e.g. for online banking services, and keep them in your wallet or in an encrypted file protected by a password that you’ve got in your head. A good way to generate these random passwords is e.g. openssl rand -base64 12.
  • If you must write a (long, random) password down, keep it like you would anything else of value; i.e. in your wallet or in a safe.
  • If you don’t want to use a random password, choose a word or phrase that has a special meaning to you, but is not obvious or easily traceable by someone else. Names and birth dates of loved ones, relatives and pets are therefore not suitable.
  • Do not use one single word that can be found in a dictionary!
  • Do not tape a note with your passwords to your monitor, or hide it under your keyboard!
  • Do not re-use passwords for anything you value.

What kind of encryption to use


Although it is not a topic that will interest users, the choice of encryption algorithm used is important.

My recommendation would be that you only use encryption algorithms that are publicly available and have been thoroughly tested by cryptographers. If the security of an encryption algorithm depends on it being kept secret (that is called security through obscurity), it’s not very good. And more important, nobody can tell. E.g. read Bruce Schneier’s essay about openness in security, and his May 2002 newsletter about Kerckhoffs’ Principle.

So for now, stick with algorithms like AES, serpent, blowfish or twofish.

Colin Percival has created a new key derivation function called scrypt, as well as en encryption routine based on it. He has published a paper (pdf) on it at the BSDcan‘09 conference. He estimates;

On modern hardware and with default parameters, the cost of cracking the
password on a file encrypted by scrypt enc is approximately 100 billion
times more than the cost of cracking the same password on a file encrypted
by 'openssl enc'.

He bases this argument, as far as I can deduce from the slides (pdf) from his talk at BSDcan‘09, on the fact that openssl uses MD5 as a key derivation function, and by his estimate scrypt is 2³⁷ (1.37·10¹¹) more expensive to attack than MD5. While I cannot evaluate his claims, as I am not a cryptographer nor mathematician, Colin holds a B.Sc in mathematics and a doctorate in computer science, and is well known as FreeBSD Security Officer. So I suspect he knows what he is doing.

Disk encryption against hardware loss or theft

If you lose a laptop, or if your desktop is stolen, your data is accessible to everybody unless you use disk encryption.

Disk encryption means that the information as written to disk is encrypted. Before the filesystem on the encrypted disk or partition can be used, the key is supplied to the operating system enabling it to decipher the data. The consequence of this is that if your computer is running and the encrypted disk or partition is in use, the data is accessible. So if someone were able to gain access to your computer while it is running and the encrypted filesystem is in use, that attacker can read it! (Note: This implies that you either have to lock your computer or remove the encrypted filesystem or shut down the computer to keep the data safe if you are not using the system. It also implies that it it important to keep unauthorized people from getting access to your computer.) This is why this method of encryption is most usefull in case of hardware loss or theft.

Disk encryption with FreeBSD

FreeBSD comes with a flexible framework that allows you to encrypt whole disks or FreeBSD partitions. The different methods are covered in the disc encryption section of the FreeBSD Handbook. Since I use FreeBSD primarily for my desktop and laptop and not as a server, I am mostly concerned with securing the user data under /home. My method is to put /home on a separate partition and encrypt that with geli. In order to use this, it must be built into the kernel or loaded as a module. This is explained in the manual page. Since encrypted partitions (or rather their device nodes to be technical) are recognizable by the system, the FreeBSD startup scripts know to ask for the password for this partition before trying to use it.

Another use is backup disks. Harddisks with a USB connection are extremely convenient as a backup medium because they are faster and easier to work with than DVDs or tapes. But because they are easily lost or stolen, I encrypt those as well.

When using a new disk, you first have to slice it with fdisk (This is called partitioning it in the PC world), then use bsdlabel to create the labeled BSD partitions. This is covered in more depth in my installa page. I will use a USB connected backup disk as an example.

For backups, I use an external hard disk with a USB connection. This device uses the umass driver, which in turn needs the scbus and da devices. If I plug this disk in, a device node is created. I’ll use da0 as an example, but it could use another number if there are other da devices in use. This disk has a single BSD slice, divided into two partitions. The first 20BG partition (da0s1a) is for the dumps of /, /usr and /var. The rest of the disk is a geli(8) encrypted partition (da0s1d.eli) to store data from /home.

fdisk -I /dev/da0
bsdlabel -w /dev/da0s1
setenv EDITOR /usr/bin/ee
bsdlabel -e /dev/da0s1

The EDITOR variable is set to a somewhat friendlier editor (ee) then the default vi! Next, the slices are made with the second bsdlabel command.

# /dev/da0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a: 20971520       16    4.2BSD     2048 16384 28528
  c: 488392002        0    unused        0     0         # "raw" part, don't edit
  d: 467420466 20971536    4.2BSD        0     0     0

We now have a partition called /dev/da0s1d that we want to encrypt. The first step is to fill this disk with random data. This will deny any attacker knowledge of which parts of the partition are actually in use.

dd if=/dev/random of=/dev/da0s1d bs=32k

You can experiment with larger block sizes. Last time I timed this, it took about an hour to fill 120 GiB this way.

Next, use geli to prepare and attach the partition;

geli init -l 256 /dev/da0s1d
geli attach /dev/da0s1d

This will initialize /dev/da0s1d for use with geli with a 256-bit key (using the AES algorithm) supplied by a passphrase. The second command will create the device node /dev/da0s1d.eli, which provides access to the unencrypted data. These commands have to given as the root user. Next we will create a filesystem on this device using newfs, and mount it.

newfs -U /dev/da0s1d.eli
mount /dev/da0s1d.eli /mnt/backup

After this, the filesystem is ready to be used. The geli init and newfs steps only have to be carried out once. But attaching the geli provider and mounting the filesystem always have to be done once before using the filesystem. As I mentioned before, the eli suffix on a device when used in /etc/fstab enables the startup scripts to make sure that the encryption device is attach-ed before use. But if you want to do it by hand, use:

geli attach /dev/da0s1d
mount /dev/da0s1d.eli /mnt/backup

After you’re finished with it:

umount /mnt/backup
geli detach /dev/da0s1d

Disk encryption on other systems

Mac OS X also comes with en encryption feature called FileVault. It significant limitations as discussed on the Wikipedia page.

Windows 8.1 ships with “device encryption”. If you sign in with a Microsoft account, the recovery key is uploaded to Microsoft’s servers. If you sign into a domain, that key is uploaded to the Active Directory Domain Services, so it is stored on the domain’s server. As always, there are two sides to this. It gives you the possibility to recover your key if you lose it. On the other hand, others might also get their hands on your key. Basically you’re giving the keys to your digital house to Microsoft or whomever controls your domain.

Professional versions of Windows come with BitLocker.

All of these systems are closed source, and I would hesitate to recommend them on those grounds alone. Since the code is not accessible to security researchers, it is impossible to tell which bugs and weaknesses they have.

Encrypting individual files

For extra safety, you can also additionally encrypt individual files. This means that you need to decrypt them before you can even read them. Use this for e.g. files containing passwords.


UNIX-like systems like FreeBSD and Linux usually come with a program named crypt that was originally used for this purpose. Do not use this program to encrypt your files! Its encryption algorithm has long since been broken. Use some of the alternatives listed below.


(I’m mentioning this here because it is part of the FreeBSD base system. So some of the remarks in this section are FreeBSD specific. )

The openssl program that also comes with the FreeBSD base system (see openssl(1)) is considered relatively safe at the time of writing. See also enc(1). Some tips for using openssl;

  • Read the above mentioned manual pages!
  • Use the bf or aes-256 encryption algorithms.
  • Always use the -salt option when encrypting files.
  • Do not use the -k or -pass options. Let the program ask you for a password.
  • After you have encrypted a file, erase the unencrypted original! Use e.g. the rrm program from my software page, or on FreeBSD one of the wipe ports you can find under /usr/ports/security.

As you can see, there are some things you need to keep in mind when using openssl for encryption. Since it is part of the FreeBSD base system, you can always decrypt things encrypted with openssl even on a machine without any additional programs installed. That can be a plus in case you need to restore encrypted backups to a new machine. To use openssl effectively, it would probably be better to write a wrapper script that calls openssl and takes care of the details, like this;

# Uses openssl to encrypt a single file.
# Check if the argument is a file
if [ ! -f $1 ]; then
    echo "Error: $1 is not a file."
# Append .aes to the filename to create the output filename.
# Use the AES algorithm in cipher-block chaining mode with a 256 bit key.
openssl aes-256-cbc -e -salt -in $1 -out ${outname}
# If the encryption fails, bail out.
if [ $? ]; then
    exit 1;
# Overwrite the old file, and remove it.
SZ=`du $1|awk '{print $1}'`
dd if=/dev/zero of=$1 bs=1k count=$SZ >/dev/null 2>&1 && rm $1

The fact that openssl uses MD5 as a key derivation function has me slightly worried. According to Colin Percival’s slides (pdf), this is relatively cheap to attack by brute force. So I don’t think this is the optimal solution for encrypting files.


The ccrypt program was designed as a replacement for the broken crypt(1) program. It uses the same Rijndael cipher that is used in [aes]. One handy feature is that it by default overwrites the target file with its encrypted contents. This means that you cannot forget to delete the old file. On FreeBSD it is available from the port /usr/ports/security/ccrypt.


This program uses the scrypt key derivation function mentioned above. In FreeBSD it is available from ports as /usr/ports/security/scrypt.

GNU Privacy Guard

A good program to use is the GNU Privacy Guard. One thing to remember is that this program uses public key cryptography, using a combination of a public and private key. (All the other programs I’ve mentioned before use only a private key.) This makes the gpg2 program usefull for more than just encrypting your own files, it can also be used for encrypting or signing e-mail messages destined for someone else. If you encrypt a file using another person’s public key, only that persons private key can be used to decrypt it.

This program is a good choice because of its multiple uses. It integrates well with several mail programs. There are also several frontends available to make it even easier to use.

The only downside to using this program is that you need to have your keyfiles available. But carrying your private key around is generally not a good idea; you want to keep that private (even though it is protected by a password).

For comments, please send me an e-mail.

Related articles

←  Installing Plone via the unified installer Managing configuration files  →