Applied Cryptography

For Vim users, the simplest way to encrypt something is to open it in Vim and use :X and enter a pass phrase. Save the file with :w as normal and the file will be encrypted:

If you’re interested in a strong encryption, use this.

To always use this, put this in your ~/.vimrc.

The default cryptmethod is zip which is compatible with Pkzip’s encryption method. Note that this encryption method is breakable by a mildly motivated attacker. If it’s really important, use blowfish.

To remove any Vim encryption, use set key= and then :w the file.

See :help encryption for other exciting details.

To for other tips on using Vim securely, see my Vim notes.

PGP, or "Pretty Good Privacy" is the classic piece of software which applies strong encryption to anything that needs it with a particular emphasis on email. Don’t let the name fool you, the privacy is more than pretty good, it is superlative. There were patent and export regulation issues surrounding the original PGP, so the good folks at GNU went ahead and resynthesized the functionality from scratch and created GPG as a drop in clone unencumbered by any legal nonsense. GPG stands for "Gnu Privacy Guard". The GPG website is here.

For email applications, see my specific notes on PGP/GPG

To encrypt a file without using keys or any of the trust infrastructure GPG is capable of, use the --symmetric flag (the short option -c does the same thing).

GPG can handle many fancy cryptographic protocols. It’s default is probably fine for all normal people doing normal things, but if you want some real tin foil hat excitement, it can’t hurt to specify that GPG use AES 256 bit encryption. To do that, simply include --cipher-algo AES256 as an option.

To decrypt, just run gpg with the encrypted filename as the argument. It will know what to do.

Note that "DOS executable (COM)" just means that the system has no idea what this file is. That’s good.

This also works using pipes.

I like ccrypt. This is a replacement of old fashioned Unix crypt. I think it can be installed easily on Macs with brew. Unlike Unix crypt, the algorithm provided by ccrypt is not symmetric, i.e., one must specify whether to encrypt or decrypt.

On CentOS and presumably Red Hat, the easiest file encryption utility to get working is mcrypt. Apparently mcrypt uses a symmetric encryption algorithm for both encryption and decryption.

Here is the normal operation.

This will produce a file named the same as the original but with a new extra .nc extension (I don’t know what the "n" is for). Note also that while it asks for some password minimum assurances, if you know what you’re doing and want a simple password, it works fine.

Use mcrypt -d filename to decrypt.

Here is a way to use streams to get pretty much the same effect.

With this technique you can run it through compression and/or archiving or whatever and take complete control of the resulting name or destination. There are options to the mcrypt program executable that can do much of this. Here is an example of this being very useful. In this case, it is difficult to get the mcrypt executable on the target machine. Here was the solution.

The trick here is to use keys with empty pass phrases or, as shown here, use the -f option to specify a file which contains the pass phrase. This prevents both programs from asking stdin for user input.

If the cryptsetup command seems missing it can simply be obtained with sudo apt-get install cryptsetup.

Note that the --debug option goes far beyond the --verbose option and is worth using sooner than later when troubleshooting.

Start by creating a volume that is organized for LUKS and password locked with your password which you will define in this step. This command will hose anything already here, so this is a one-time only kind of operation.

You can create an encrypted volume over another virtual device. This would live in /dev/mapper when it’s open. When it’s not open, it’s just fuzz on the underlying partition or logical volume.

This can be done on top of LVM partitions as shown here.

Once you have the underlying volume configured for cyrpto, you need to open it by creating another higher level virtual device that you can actually interact with. You supply a passphrase here.

Now you can use this volume like normal.

Now you want to protect the partition from unauthorized use, close it. The paritition unnervingly disappears, but the underlying partition remains with your data encrypted.

To see if a partition is actually something that can be opened into a decrypted partition, use the isLuks sub-command.

To see more of the details of what is stored in the LUKS header try the luksDump sub-command.

Note that this wants the actual raw block device, not the LUKs volume if it has been opened.

Resizing a crpyto partition over LVM (yikes!). It can be done: see here.

Need to change a passphrase on a LUKS volume? This should behave sensibly.

Note that you can add additional keys. You will need one of the working keys.

I don’t mind doing this when I feel like I need a new key because my old one is too complicated or hard to type. Better to leave that as an option too in case I get confused about what the status is.

Imagine you’re making a backup of something every day to 7 drives, one for each day of the week; on Monday, you plug in Monday’s drive and start the back up script; on Tuesday, you do the same for Tuesday’s drive, and so on. The host you’re plugging these into every day is not being turned off and you’d like for it to remember the passphrase for all the drives (which will share the same one). The only thing you’re concerned about is if someone breaks in and steals everything, you want to ensure that they can’t see any of the data. This means that the key can be floating around in the live system, but you want to have it encrypted when it returns from a power cycle. How can this be done?

The strategy I’m going for involves using one of the "key slots" of LUKS. A LUKS protected volume can be opened with one of 8 (I think, 0-7 at worst, maybe 0-31 now for LUKS2) slots. This allows you to basically have 8 ways to open the drive (e.g. 8 different admins with their own passwords). In the main slot, I would just put the ordinary passphrase as normal. But then we’ll add a new slot that will be accessible with a key. To do this, start by generating the key.

This will be just like typing a long random 512 character passphrase. But since we want this to be opaque to someone who steals the system, it itself needs to be encrypted. To do this I’ll suppress my misgivings and used GPG. If it’s good enough for package management, well, I guess it’s better than OpenSSL (which also can work for this). The dd generation can be piped right to it.

The pinentry-mode just prevents it from trying to use some PGP keys lying around or something like that; we want it to just prompt for a passphrase. If all goes well, this should make a (binary) file called /tmp/drivekey.gpg.

Now that you have this random thing encrypted with simple symmetric GPG, anytime you point gpg at this it will want you decrypt the gpg part and it will ask you for the gpg passphrase you just used — perhaps with a GUI form box — or it will dig into some agent and see if it already knows what to do. Either way, here is a strategy that can work. The trick is sending the decrypted key right into the LUKS opening process. But first you need to create a normal LUKS system that can be opened with an annoying passphrase. So format it as such and use a master passphrase that will be like your emergency access.

So it turns out that it doesn’t quite work to just pipe the decrypted GPG encrypted key into cryptsetup when adding a key. I actually deeply explored this with the developers and it really doesn’t look like it’s possible. You have to decrypt the PGP encrypted file to use it as a key file when adding another slot. So given that must happen, it makes sense to do that using the encrypted volume. This way the insecurity of having the plaintext version floating around (even briefly) is lessened by the fact that it’s already on the target volume (i.e. if attackers can get at this, they’re already done).

Now prepare the key.

Now that those are setup, you can use this in the future when you connect it by opening it like this.

Now you should be able to use this key-file or the normal LUKS password. If the GPG agent showed up to work, then you only have to do this once per boot. If the power is cycled (e.g. all the hardware stolen) then everything is once again locked down.

Remember that this is putting a bonus key in slot 1 and that it is probably smart to keep the main old fashioned one in slot 0. If for some reason you need to recreate this extra key file to replace the one you’d created (e.g. you lost it, but still remember the slot 0 passphrase) you can clear a slot with luksKillSlot.

Then just recreate it and luksAddKey as needed.

Here’s the new way I’m trying with the slot 0 passphrase and then the slot 1 key encrypted with symmetric gpg. This prepares a new drive and will erase it!

To set up an encrypted volume just do something like this:

Note that I just copied and pasted a block of text here since typing that is kind of onerous. However, don’t go crazy. Truecrypt doesn’t bother clearing the buffer so that when your program ends, you’ll get a ton of garbage on the command line.

If you don’t use the --quick option it will take 6 or 7 hours to set up a 1TB USB drive. With the --quick option it will say that it’s 100% done and proceed to seem like it’s hanging. What it’s really doing is a mkfs.ext3 /dev/mapper/truecrypt1. And that can take quite a while too.

To mount a TrueCrypt volume, I just used the interactive mount command which went like this:

To unmount do this kind of thing:

I couldn’t easily time the setup for TrueCrypt because of all the interactive (type 320 characters, etc) hand waving. But whatever it was, it was no worse than LUKS. If you don’t specify the --quick option, you’re looking at almost two orders of magnitude more.