Tag: Security

A New GPG Key

May 30, 2018 » Geek

It’s been 12 years since I created my first GPG key and 11 since I’ve created the one I actually use. That is far too long, so I decided to create a new pair and deprecate the old. In 2013 I started this process, but I didn’t follow through and I’ve since lost access to those keys. I know where they are, but the machine died so I need to hook up it’s HDD and pull the keys out.

Regardless, it is time for new ones, and I did some reading to get a real plan for this. I would generate a new, strong key offline, with a subkey for each capability. The subkeys would go onto a smart card, in my case a Yubikey 4. The primary key material would go to offline backup to keep it safe.


Nothing in this post is new or novel, but rather collected from many other posts. I’ve tried to link to any relevant posts below each section, and I encourage you to read these sources. Any mistakes I’ve made I would be glad if you send me an email (GPG encrypted of course ;) to point it out.

Yubikey Configuration

After I ordered my Yubikey, I had to configure it. The Yubikey docs expect a fair amount of knowledge before you start, but the steps are pretty simple when you understand it. Basically, it boils down to:

  1. Change the Admin PIN
  2. Change the PIN
  3. Set a Reset Code
  4. Fill in optional metadata

Plug in your card and proceed as follows:


Generating Keys

Next, I created my keys. Be sure you set up a clean environment for this, ideally a random directory in /tmp, better still on a ramfs of an offline, live CD machine. But that’s a bit drastic for my use case.

You’ll want a good base config file in there too.

With the directory in place, I can create a primary key, option 4. 4096-bits is as strong as GPG allows right now, and I set it not to expire because I will be keeping offline and it should be ok to revoke manually if needed.

Now it’s time to create subkeys. There are four capabilities that a PGP key can have.

C is for Certify

Your primary key will have the capability of Certification. Certify is essentially the ability to sign other keys. A key with Certify can be “parent” to subkeys, create new subkeys, and edit existing ones. You also need this capability to sign another users public key.

S is for Sign

A key with the Sign capability can sign files and messages, allowing others to verify their integrity.

E is for Encrypt

A key with the Encrypt capability is used for encrypting files. Simple.

A is for Authenticate

An Authentication key is generally used for SSH authentication.

Generating the subkeys is a bit tedious, but so it goes.

The authentication key requires E X P E R T M O D E. Git gud.

That’s it! We’re in business.

  1. https://spin.atomicobject.com/2013/11/24/secure-gpg-keys-guide/
  2. https://www.linode.com/docs/security/authentication/gpg-key-for-ssh-authentication/
  3. https://gist.github.com/abeluck/3383449
  4. https://alexcabal.com/creating-the-perfect-gpg-keypair/
  5. https://gist.github.com/graffen/37eaa2332ee7e584bfda


Before we do anything else, we need to back that thang up.

I’m choosing two methods: backup to a USB key that will live in a fire safe (who has a safety deposit box these days?), and a printed backup in case the USB key fails. Ideally these two articles would not be co-located.

First we export the keys and move them to the USB stick. The export-secret-subkeys output is less important than the export-secret-key output as it doesn’t contain a viable certification key, but would be useful as a “middle tier” of backup that wouldn’t expose your primary key to risk.

Now, we could take these ascii armored keys and just print them, but that’s a lot of bytes to pray for OCR to recognize. Instead, we can use a piece of software called Paperkey which strips out everything but the most secret parts of the key and gives you something much shorter to type in.

Still not fun to type it all in, but it’s better and this is a last ditch sort of thing anyway.


Backups you don’t test aren’t backups, they are hopes and dreams. So let’s try recovering from our paperkey output!

  1. http://www.jabberwocky.com/software/paperkey/

The certificate revoke you, secret key!

While not required, we can generate a revocation certificate while we still have the primary key on this machine.

Throw that onto your backup drive too while you’re at it.

  1. https://www.hackdiary.com/2004/01/18/revoking-a-gpg-key/


Ok. Everything is generated, we have a good backup, we are ready to transition. To indicate that this key is your new key, you can sign it with your old one, then send it up to the keyservers in the sky (if you’re into that)

  1. https://www.apache.org/dev/key-transition.html

To The Smart Card Robin!

I'm Batman

Moving the keys onto a smart card helps protect them. They won’t exist on your filesystem anymore, only on the card. That means they can’t be read out and stolen by a malicious process, but you can still use them by providing your smart card pin and key password.

Keep in mind, this is a one way trip. Make sure your backups are really, truly in place. We want to move our Signing, Encryption and Authentication keys onto the card. The Certification key we will only store offline, as mentioned before.


Hold onto your butts.

This is it. The big moment. Take out that smart card, secure your backups, and let’s delete our primary key material.

Now you can have gpg create key stubs for all the keys on your smart card.

Now when we list keys, we see that our primary key has a # next to it, showing we don’t have access to that secret key. The subkeys have a > next to them showing they are stubs for the keys on the smart card. Success!


That’s it. There is, of course, more to do, like setting up git signing, SSH access, etc. But the new keypair is created, and it’s on the Yubikey, so that’s all for now.

Update: Git Signing

Turns out git signing is a cinch. Just throw a couple items into your git config and it’s automatic and transparent.


Tells git which key to use for signing, unset it just uses the default key.


Makes it sign all commits by default, instead of passing -S to every git commit.


By default, git won’t show you if a commit is GPG signed. You can see it with gpg log --show-signature, or you can set it as default with this config option.

It makes signed commits much chunkier, so be aware of the reduced screen real estate.


This is the only one I am not setting by default. If you have it enabled, all merges that include unsigned commits will be rejected. This really only works if everyone in your organization is signing all their commits.

  1. https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
  2. https://git-scm.com/docs/git-config

Update: One-Touch Actions

By default, with the smart card in, GPG will happily sign and decrypt things after you enter your PIN the first time, with no further interaction from you. The Yubikey offers a mode where these actions require a touch on the key to complete, which I like because it makes the action more explicit without requiring me to remove the key between operations.

To enable this, you need a special script, yubitouch.sh. To make it work with my GPG Tools install, I had to hard code the path to gpg-connect-agent (/usr/local/MacGPG2/bin/gpg-connect-agent) and my admin PIN, since pinentry wasn’t working and I didn’t want it in my bash history.

Now, when GPG needs to sign something, my Yubikey flashes at me until I touch it and give my permission. Neat.

  1. https://developers.yubico.com/PGP/Card_edit.html
  2. https://github.com/a-dma/yubitouch
Tags: , ,

Password Generator Alfred Workflow

October 9, 2014 » Geek, Life

I love pwgen for passwords. They are simple and strong, pharmacy but it can be a pain to kick over to the terminal whenever I need one.

So, mind I made a super simple Alfred Workflow for this.

Basically, you type in “pw”, “pwgen” or “password” and it will generate and copy a 40 character password into your clipboard/open app.

You can use the “secure” option to generate stronger, less memorable passwords, and you can pass a length option as well.

Download it here: pwgen.alfredworkflow

Hashes Are Not *$&%@! Magic

September 27, 2012 » Geek

I’m going to get on a programming soapbox real quick and cover a topic that seems to confuse some people.

Hashes Are Not *$&%@! Magic

Some people seem to think that swapping out a secret with a hashed version of that secret makes it all safe and cozy, but that’s simply not true.

Yes, cryptographic hashes are a very important part of digital security, for a number of good reasons, but they have to be applied in a manner which takes the whole system into account.

The impetus for this work was a login integration I recently updated, because some other developer foolishly applied hashes.

Essentially, we were cross-posting a login form on one website to another. Nothing fancy. Ignore the lack of CSRF control.

The New Form

But the new form would need a change. Instead of sending the username and password, we would send the username, and an MD5 hash of the concatenation of username and password.

Now, I’m sure when this idea was implemented, it was sold as a way to authenticate the user, without exposing their password in plaintext (note that they don’t use SSL). Brilliant!

Yes, it does obscure the plaintext password, but it is not any more secure.

You see, they didn’t think about the system as a whole, they were just focused on obscuring the password.

All that happened here is a substitution of shared secrets.

Previously the server compared the username and password it has on file to what was sent in. Now it compares the username and the hashed password to what it has on file. Do you see what we did? We’ve simply swapped the secret of the plaintext password for the secret of the hashed password. I can still intercept your form submission over the wire and steal your credentials.

I don’t have to prove I know the password, I have to prove I know the secret.

Zero gain, and you’ve added complexity.

MD5, lol

As a bonus, they picked MD5, probably because it’s been implemented many times, there is a JavaScript version readily available, and it tends to be one of the first hashes people learn about, due to it’s age.

But MD5 is weak. And we have the salt, if you can call it that, in the username. An old 2Ghz P4 can try about 20 Million hashes a second, and throwing a modern GPU at it you can test several billion hashes a second. If we want the plaintext password, we can get it unless it is reasonably large (7+ characters) and fairly complex (at least one non-alphanumeric character).

(╯°□°)╯︵ ┻━┻

For an extra thought, consider how they must be storing these passwords. Either there scheme has always been MD5(CONCAT(username,password)) or they are storing them in plaintext and are (hopefully) migrating to hashed.

Linux Encrypted Laptop

January 25, 2008 » Geek

This post will (try to) explain how to set up a working system of hard drive encryption on a Debian system, in this case sidux. I’m going to outline the specific course of action I took to set up my own laptop, but will try to provide generic enough instructions alongside that to help the reader adapt it for themselves. Please excuse the wild tense changing and poor overall writing style, I’m not that good at this stuff.

This post is not aimed at the novice Linux user. I’m not going to hold your hand, so be comfortable with the command line and competent enough to get your system back if you screw up along the way. Also, do not skip the backup step! Finally, this is (obviously) not a wholly original and independent work, I owe a great deal to the sources I’ve listed at the bottom. Enjoy!

The Context
I run Linux on my laptop and I want to encrypt the important parts of my hard drive because there is a lot of my personal life on there. Most specifically I’m interested in my passwords, many of which I store in firefox Iceweasel for convenience, and my financial data which is in the form of KMyMoney files and pdf receipts.

Here’s the layout of my disk, and yes I know I have outrageous sizes on some of these partitions, I just like to have breathing room. Please see [1] for a good guide to partitioning.

/dev/sda1 ntfs /windows 40.00 GB
/dev/sda2 ext3 / 15.00 GB
/dev/sda3 EXTENDED
    /dev/sda6 swap 509.81 MB
    /dev/sda7 ext3 /tmp 1.00 GB
    /dev/sda8 ext3 /var 5.00 GB
    /dev/sda9 ext3 /home 39.51GB
    /dev/sda5 fat32 /winshare 9.98 GB
/dev/sda4 ext3 /data 121.88 GB

What we need to encrypt on there are: /home, /tmp, /data and /swap. I’ll be treating the /windows and the /winshare as dirty and never let anything important touch those partitions, I rarely boot into XP for anything but school work anyway.

The Tools
You’ll need a very few pieces of software, and possibly a piece of hardware. For the software side you just need “cryptsetup” and possibly a partitioning tool if you want to change your layout. You’ll also be needing some spare hard drive space to hold your existing data if you have any. I used an 80 GB external drive I had on hand.

I’m using an existing system as my base, so I have to copy off my /home and /data partitions. Once we are backed up, it’s important to write down somewhere the /dev names of the file system. I made a little table, like the one above, by using gparted.

Now I’m going to go down to run level 3. This is just to minimize noise on the system. We need to unmount /home, /data and /tmp. When unmounting file systems, you might get something like the following error:

This just tells us there is an open file descriptor on /tmp, we can see who has it with:

Now in the above example it is obvious that I did not go down to run level 3, X11 and kde are still running. So just weed out the open files and then unmount them when there are none left.

This is where that /dev table you made earlier (you did make it right?) comes in handy. Be sure that you are backed up, because this is the point of no return. Setting up an encrypted partition is dead simple. As root you’ll want to run:

Where /dev/sda9 is your /home partition. I encourage you to go read the man pages for cryptsetup [2]. I just went with the values on a post I found [3].

Now we need to open and format that, so we use cryptsetup to open it:

This is going to create a mapper device called “chome” in /dev/mapper/chome. You don’t need to call it chome, I just do it to keep track of whats what.

Now to format it we need to do:

The file system really doesn’t matter, you can use ext2, reiserfs, whatever your heart desires. Once you’ve done that, you’ll want to close it again.

We need to repeat that process for /data, but since it’s essentially the same procedure I’m not going to run through it here.

The /tmp partition is a different story. You’ve got an existing file system on there that we need to blow away. The first way that came into my head was to use dd to copy zeros over it, like so:

That’ll probably take a while and not report in. You can force it to give you a status by stopping it, sending it a USR1 signal then restarting it. Not really a big deal though, I just waited it out.

It also might be wise to increase the block size on that, and you might not have to do the whole thing either. Again, refer to the man pages [4] if it concerns you.

Set Up crypttab And fstab
We now need to update our fstab and the crypt equivalent, crypttab. This is going to vary for everyone, but there are a few key things to note. Let’s look at crypttab first. Here’s mine, and I’ll walk you through it.

So the major things here are the target, which is what the device will be called in /dev/mapper. I picked the easy to associate: chome,cdata, cswap, and ctmp. Next is the source device, which are the partitions we messed with earlier. The key file is set to /dev/random on cswap and ctmp because those are going to be one time file systems, and the key should just be random garbage.

Finally we get to options. chome and cdata have “none” in there. This is just saying “prompt us for the password”. You could put the password in there and it would happily take care of it for you, but that seems like a stupid thing to do to me. The “luks” just tells it to use the luks extensions. cswap and ctmp both use special options. The swap and tmp options basically say “reformat this then encrypt it”. They are reformatted on boot to linux-swap and ext2 file systems, respectively. For more information check out the, you guessed it, man page [5].

Now that we’ve got the crypttab set up we need to modify out fstab. Again, I’ll show you the relevant parts of mine, and walk you through. It’s pretty simple though.

Okay, so, the basic idea is that we find the old /tmp, /home, /data and swap entries, and replace them with the mapped ones. One important item here is that you’ll want to set that last digit to a 0 on /tmp. This is what says “Hey, fsck me!” at boot time, and we don’t want to bother with a checking a brand new file system, right?

cryptdisks And cryptdisks-early
These two are the init scripts for starting up your disks. They should be in /etc/init.d, which on my system just lead to /lib/cryptsetup/cryptdisks.functions. I tried using bum to add them, but I wasn’t getting them to run before the mounting took place. I poked around on the sidux forums and found a post [6] (in German) that had another way of adding them. I don’t know if this is a Debian issue or not, but the following worked for me, as root.

Now you should be able to just reboot and be good to go. I’m not 100% on this guide as I made it after the fact, so I may have spaced off some small things. If I did, they should be very, very minor and shouldn’t cause any problems. Please do leave comments if you have an issue, I’d like to correct any errors I may have made. There are some additional sources below, please read up if you have the time. Good luck!


  1. Linux Tips – Disk Partitioning
  2. cryptsetup(8)
  3. HowTo: Setup and Benchmark Encrypted Partitions in Ubuntu
  4. dd(1)
  5. crypttab(5)
  6. Startskript “cryptdisks-early” wird zu spät ausgef
  7. Protect Your Stuff With Encrypted Linux Partitions(And Part 2)

BlowPass Has Taken Over

December 7, 2006 » Geek

So I thought that I had moved past BlowPass. I guess I was wrong. I’ve been spending every spare moment working on it. I found what I feel is a better Blowfish library at www.farfarfar.com. I still can’t implement any of the vector tests because they’re all in hex and translate into nasty characters. This means I have no actual idea if the crypt is working. I also quickly stopped trying to write my own Twofish implementation. I could handle it in C I think, but not JavaScript, I don’t know enough of it and it’s little oddities.

Regardless of all that, I’ve got my prototype AJAX down pat now (okay, AHAH) and I’m working up my own open source version of passlet.com. Here’s a nice list of features/todo’s.

  • Uses a non-proprietary algorithm (Blowfish)
  • Has AJAX-y-ness
  • Uses PHP
  • Uses a database abstraction library TODO
  • Slick animations (mootools?) TODO

You can check out the current version at http://static.velvetcache.org/projects/blowpass/demo/ to play around.