PGP stuff

My keys

Here’s a list of all OpenPGP keys released in my name, and their status.

7B9F12B9B5EF0DA1: Active

This is my current personal-use key, which I generated in 2022 and use for pretty much everything I use PGP for. I finally have a master key secured well enough that I don’t expect to ever worry about it, and therefore have set it to never expire. I do have an expiration date for the subkeys since I intend to regularly rotate them to obtain some measure of forward security.

If you want to communicate with me using PGP, this is the key you should use unless I’ve personally instructed you otherwise.



91A835DAC5689324: Compromised

I created this key for work at my previous job, on an office computer I didn’t own, and never used it for anything. I no longer have any access to the private key, and while it was probably just erased I cannot rule out that someone might have kept a copy.

Don’t use this key for encryption, don’t trust anything signed with it, and please alert me if you do ever see something signed with it.



51AB6B04EA6C3A35: Superseded
This is my previous key, which I created when the one I created in 2011 was close to expiration and I felt it was time to replace it. After creating it I felt that using NIST curve ECC was possibly a poor choice, and also that I ought to have better security for my master key than I had previously practiced, so I decided to let it expire but did not get around to creating a new key until 2022. I have barely used this key at all, and you shouldn’t use it either, but in case you find an old signed document from me you may still find it useful to retrieve it.


73B68566BFBC8D95: Superseded

I created this 4096-bit RSA key in 2011, and it is still the most-used of any of my keys, as well as the most-signed, having made it into the so-called strong set when I attended a key-signing event in 2013.

I made a number of questionable decisions with this key due to inexperience. One of these was generating a single master key to be used for all purposes, which necessitated copying my private master key to every device on which I wanted to sign or decrypt anything. Another was that I used it to a lot of other keys based on very weak verification, and so certifications made with it before 2013 should not necessarily be trusted. A third was backing it up to a cloud storage service, trusting in the security of the passphrase itself (which, to be fair, is and always was quite strong). It’s also ridiculously huge and the version of it available on old SKS keyservers has many redundant self-signatures due to my misunderstanding of how keyservers worked when I was managing it. Still, it did the job I needed it to do.

I have retired this key, and keep the private key only on a secure encrypted backup in case I find some old backed-up data that I need to decrypt. I am still making the public key available in case you need it to verify a signature on an old document or file.



56DFCDF8BFBC8D95: Forgery

This is not actually my key at all, but a forgery created as part of a proof-of-concept attack. In 2014, to demonstrate the insecurity of relying on short (32-bit) key IDs, Richard Klafter and Eric Swanson created and published the Evil32 archive containing short-ID lookalikes for the entire PGP strong set. Unfortunately, someone then released all of these lookalikes onto the public keyservers, where they remain today. Mr. Swanson was considerate enough to push revocations for all of these keys to minimize the damage, but the revoked key does remain available.

I have no criticism for these researchers, who rightly gave a public demonstration of a major security flaw in existing PGP implementations. And it was probably inevitable that someone would be trollish enough to upload the proof-of-concept keys to the SKS pool, so while it’s annoying I can’t really get too worked up about it. I am disappointed only in the SKS infrastructure itself, a dinosaur of a system which is fundamentally flawed in its willingness to accept and redistribute arbitrary uploads without verification while making them impossible to remove. This very flaw was ultimately SKS’ undoing, years later.



BAE750AFCC56CAC9, 50EA36F4DCA42F7B: Lol

I created these keys in 2003 when I first got curious about cryptography, had no idea how to use them, but somehow managed to push them to the SKS pool before I presumably wiped them from existence the next time I did something dumb with my computer. On the one hand, I wish I could scrub them from the keyservers; on the other, they are the only reason I still have a copy of my high school yearbook photo , which I included as a UAT.

I don’t really need to tell you not to use these, since they don’t have encryption subkeys anyway, but I can at least tell you not to bother importing them if you find them somewhere.

Certification practice statements

From time to time I certify the keys of others; these documents (well, this one document for now) explain what exactly I am certifying when I do so, and my criteria and process for certification.

Whenever I make a significant change to my policy, my plan is to mark my existing CPS as superseded and put up a new one, rather than replacing it, so that it remains clear not only what my policy is now but what it was for any keys I have signed in the past.