[ This post originally appeared as a Facebook note. ]
Disclaimer: this goes deep into computing, cryptography policy, gross Unix fiddling with keys and the like. If computers bore you, spare yourself and just stop reading now.
I first tried out Keybase.io so that I could provide an informed opinion
for my then-CEO, at a previous employer.
I was unimpressed with the security model, but conceded that it might improve
usability enough to be worthwhile anyway.
I created an account using my work PGP key, because that was the key on my
(work) laptop and I wasn’t going to install the
keybase software on the
machine with access to my strong personal PGP key.
- “PGP” is “Pretty Good Privacy”, the only widespread personal encryption and signing tool designed for distributed trust without central authorities, the only system good enough to usually thwart powerful entities, the system which led the US government to prosecute its creator (they lost/gave-up). There was a commercial tool by this name, it’s rarely used today.
- OpenPGP is an IETF-maintained specification (“Internet standard”) for PGP, defining how the data is glued together and how it works.
- GnuPG is the dominant implementation of OpenPGP; it’s maintained in Germany
and is under the GPL software license. It has a command-line tool,
gpg. It’s currently on version 2.1.15, which matters a bit more than is normal for software today.
- Keybase: a system (with website at https://keybase.io/) for replacing the OpenPGP “no central trust authorities, use a distributed web-of-trust where everyone decides for themselves” security model with “let’s have people choose which central authorities they use for other purposes, pretend they’re good enough for strong identity, and if they can prove that they own a given account, link it. Become a new central trust authority.” Not a bad business model if they can get away with it: there’s always a lot of money to be made in fiscal rents if you can control the only central authority which matters. Original tools were written in Node.js and did nasty automatic software-updates to your local machine (this matters for something as sensitive as OpenPGP key management and handling of secret keys). Newer versions are Golang binaries, less automatic updates (and you can build from source yourself).
- Keysigning party: 99.9% of the population would not classify one of these as a party. Let’s not go there. (But they matter for getting the trust models of PGP to work … oh, nevermind).
Fast-forward to the day, early this year, when I leave that employer. I revoke my work PGP key. I go to update Keybase and … I can’t.
There are two models for Keybase: an old one (which I was on) which was strongly tied to one key, and a new model, where your key signs your login and you get device keys instead, and can replace PGP keys on Keybase. But to get from old to new, you need to be able to sign the login, and keybase won’t let you use a revoked key to do it.
This evening I tried again. I still have the private key for that work key; I can’t do anything with it for most systems, because the revocation is out there. The key’s dead. Well, mostly dead. It’s a Zombie. It shouldn’t be able to do anything unless someone invoking their local OpenPGP command decides to ignore revocation. (Importantly, my previous employer is safe and in no way harmed by my still having the private key.)
I particularly do not want to “drop” the key and all social proofs and followers. The only reason I care about Keybase at all is those followers and people using Keybase to bootstrap trust instead of going to a keysigning party. Damned cool kids, staying behind their computer screens and posting stuff online to prove identity instead of going to a party. Hey wait, that … sounds wrong.
After much hassle and exploration of
delsig in GnuPG’s
I end up going old school: export the revoked key from the secret keyring
(to have the private key there), delete entirely from keyring.
Make sure that the export is in non-ASCII form
gpg --dearmor for this, could have just avoided
-a to start with).
gpg --list-packets < dumpedkey.pgp | less to look at the individual packets.
Note: the exported PGP keys you see are just a raw sequence of OpenPGP
“packets”, one after another, usually then base64-encoded,
given a CRC and armor
In the packet listing there are comments, providing file-offsets for each packet
(and lengths, but those exclude the packet header fields).
dd to construct two extracts from the key-dump, excluding the revocation
signature and then
cat to join those together into an almost-complete dump,
missing only that signature.
gpg --import filteredkey.pgp and … we’re in action!
I can use my not-revoked key locally.
I am able to use the
keybase tool and login,
prove the login with access to sign the request (at last)
and I get automatically migrated in Keybase’s systems to the new format.
I try to import my other laptop key and: it fails.
This current laptop had one key, with comment “
Laptop & exposed” in the human
name which others see.
ECC/nistp256 and works quite nicely, thank you.
Except not with Keybase.
There are two models for adding keys:
select approach (even after coercing to “yes I want multiple keys”)
errors out, the
import demands access to the private key.
I went ahead and removed the old work key from keybase,
leaving me “keybase-keyless” and decide on a path forward.
Generate Yet Another New OpenPGP Key!
I’m certainly not generating a key inside their system,
and I’m not giving them access to a key which matters,
not after the errors I’m seeing or the levels of distrust to which I’m sinking.
This new key has comment keybase, is bog-standard
unexciting, made with
I sign my main key with this one, and vice-versa,
both using a
cert-policy-url describing the signing-policy as “self”.
I go and select this for Keybase.
I don’t. I try to. Eventually, I succeed.
There are lots of
I’m using GnuPG 2.1.15, the current branch of the tool, and Googling on the
errors, I find the tickets in Keybase’s GitHub Issues system where people
found these problems during testing.
Keybase developers decided that it only affected the test suite and didn’t
really matter in reality, so the ticket got closed.
Apparently nobody thought about interactions with adding the key for the first time.
So hey, good news!
Keybase have a test-suite comprehensive enough to catch regressions.
The bad news … let’s not rant further.
I use the
pinentry manual-edit hack of keybase’s
to specify the path to the program
gpg-agent.conf instead of
gpg.conf these days),
restart the keybase service (
keybase ctl restart),
gpgconf --kill gpg-agent and other kicks and slaps, all to no effect.
I find that there are logs!
They’re stored in binary files (leveldb) and can be “sent” to the developers,
giving me an ID to refer to, but I can’t look at them myself. Say what now?
Logs from my machine of software interacting with my private keys, which are set up so that only the software developers can see them. Software which doesn’t handle Assuan negotiations cleanly, where test failures are brushed aside, and which can’t select the key, but can (see below) import a copy of the secret key to be managed within its own ecosystem (while complaining in Issues about GnuPG’s changes to secret-key management, better isolating the keys in similar, but just much more competent, ways). On the bright side: the hubris is darkly entertaining.
In the end,
keybase --pinentry=none pgp select still failed but
keybase --pinentry=none pgp import < newkey.dumped.asc succeeded.
https://keybase.io/philpennock is now vaguely useful.
But seriously, go read Phil Dibowitz’s
pages at https://www.phildev.net/pgp/ instead, if being able to use tools to
verify the integrity of critical components of Internet infrastructure matters
Attend a keysigning at a conference, or at your workplace.
Make the web-of-trust work, in ways which let you use whatever OpenPGP
implementation you wish, with keys managed as you wish.
Avoid central control by folks who believe in pushing their software changes
out without review and having logs sent to them apparently without review.
And if you must use keybase to get to me, just look at the other signature on
the key you get, the one with my name but without keybase referenced, and use
0xD231BDA6A79FCEE0 key just to get a trust-path to
0x4D1E900E14C1CC04 - the key which matters.
I’ve tried to give Keybase a fair chance, repeatedly,
but the Fail after Fail after Fail overwhelmed me.