More GPG services UX problems: Keybase complication, GreenAddress and the expired key

I have expressed some doubts on Keybase last year, but I kept mostly “using” the service, as in I kept it up to date when they added new services and so on. I have honestly mostly used it to keep track of the address of the bitcoin wallet I’ve been using (more on that later).

A couple of weeks ago, I got an (unencrypted) email telling me that “chris” (the Keybase founder) “sent me a message” (more likely that they decided to do another of their rounds of adding invites to people’s account to try to gather more people. Usually these messages, being completely non-private, would be sent in the clear as email, but since Keybase has been trying to sell themselves as a secure messaging system, this time they were sent through their secure message system.

Unlike most other features of the service, that can be used by copy-pasting huge command lines that combine gpg and curl to signal out of band the requests, the secure messaging system depends on the actual keybase command line tool (written in NodeJS, if I got this right). So I installed it (from AUR since my laptop is currently running Arch Linux), and tried accessing the message. This was already more complicated than it should have been, because the previous computer that was set up to access Keybase was the laptop I replaced and gifted to a friend.

The second problem was that Keybase also decided to make encrypted file transfer easy by bundling it with messaging. Effectively making conversations a shared encrypted directory, with messages being files. This may sound a cool idea particularly for those who like efforts like Plan9, but I think this is where my patience for the service ends. Indeed, while there are sub-commands in keybase for file access, they all depend on using a FUSE (filesystem-in-userspace) module, and the same is true for the messages. So you’re now down to have to run a GPG wrapper, as well as a background NodeJS service on your computer, and a FUSE service to access files and messages.

I gave up. Even though trying to simplify the key exchange for GPG usage is definitely interesting, I have a feeling Keybase decided to feature-creep in the hope that it would attract funding so that they can keep operating. zCash first, now this whole encrypted file-share and messaging system, appear to be overly complicated for the sake of having something that you can show. As such, I explicitly said in my profile that any message sent through this service is going to be a scream into the void, as I’m not going to pay attention to it at all.

The second GPG-related problem was with GreenAddress, the bitcoin wallet I signed up for some months ago. Let me start with a note that I do not agree with bitcoin’s mission statement, with its implementation, or with any of the other cryptocurrencies existence. I found that Thomas wrote this better than me so I’m not going to spend more words on this. The reason why I even have a wallet is that some time ago, I was contacted by one of my readers (who I won’t disclose), who was trying out the Brave browser, which at the time would compensate content creators with bitcoin (they now switched to their own cryptocurrency, making it even less appealing to me and probably most other content creators who have not gotten drunk with cryptocurrencies). For full disclosure, all the money I received this way (only twice since signing up) I donated back to VideoLAN since it was barely pocket money and in a format that is not useful to me.

So GreenAddress looked like a good idea at the time, and one of the things it let you do is to provide them with your public key so that any communication from them to your mailbox is properly encrypted. This is good, particularly because you can get the one-time codes by mail encrypted, making it an actual second factor authentication, as it proves access to the GPG key (which in my case is actually a physical device). So of course I did that. And then forgot all about it until I decided to send that money to VideoLAN.

Here’s where things get messy with my own mistakes. My GPG key is, due to best practices, set to expire every year, and every year I renew it extending the expiration date. Usually I need the expired key pretty quickly, because it’s also my SSH key and I use it nearly daily. Because of my move to London I have not used my SSH key for almost a month, and missed the expiration. So when I tried logging into GreenAddress and had them send me the OTP code… I’ll get to that in a moment.

The expiration date on a GPG key is meant to ensure that the person you’re contacting has had recent access to the key, and it’s a form of self-revocation. It is a perfectly valid feature when you consider the web of trust that we’re used to. It is slightly less obvious as a feature when explicitly providing a public key for a service, be it GreenAddress, Bugzilla or Facebook. Indeed, what I would expect in these cases would be:

  • a notification that the provided public key is about to expire and you need to extend or replace it; or
  • a notification that the key has expired, and so further communication will happen in clear text; or
  • the service to ignore the expiration date altogether, just as they ignore whether the key was signed and counter-signed (preferred).

Since providing a public key directly to a service sidesteps most other trust options, including the signing and counter-signing, I would expect the expiration date to also be ignored. Indeed, if I provided a public key to a service, I expect the service to keep using it until I told it otherwise. But as I said there are other options. They are probably all bad in some ways, but ignoring the expiration date does not appear to be obviously wrong to me.

What does appear totally broken to me is sending messages that contain exactly this text:

Warning: Invalid pgp key detected

Which is exactly what GreenAddress did.

For reference, it appears that Facebook just silently disables encryption of email notifications when the key expires. I have thus uploaded the extended key now, and should probably make a good reminder a month before the expiration to keep securing my accounts. I find this particularly bothersome, because the expiration date is public information, if you use the same key for all communication. Having a service-specific key is probably the most secure option, as long as the key is not available on public keyserver, but it also complicates the securing up of your account.

What does this tell us? That once again, making things usable is an important step to make things really secure. If you have to complicate people’s lives for them to jump through hoops to be able to keep their accounts secure, they’re likely going to drop a number of security features that are meant to protect them.

My thoughts on Keybase

Keybase is one of a series of new services that appear to have come up in the wake of the publication of Snowden’s document, and the desire for more and simpler crypto technologies. I may disagree with the overall message attached to the Church of Snowden (Jürgen phrases it much better than me), easier crypto is something I’m generally happy with.

Unfortunately I’m not sure if Keybase’s promise of making GnuPG easier and at the same time keep it safer is actually being maintained. It appears to make it easier, at least under certain conditions, but I disagree with it staying just as secure, particularly if you follow their “default flow.”

The first problem that comes to mind is that they even suggest you to upload your private key to their system so that you can use the browser for interacting with it! I hoped they were kidding me, but no, it seems like that’s an option, actually the first of three options when you try to do anything at all with the website.

The second is the fact that for a lot of the features to make even remote sense you have to use the command line at that point, either through their tool or through a combination of curl and gnupg. It might seem strange that I’m complaining at both ends, but it’s because I would have preferred for them to provide, say, a Chrome extension that interfaces with gnupg, than a command line tool. Even more so when you realize that the command line tool depends on NodeJS, and it includes a -TSR- background service.

The command line tool is also not great. Indeed when you try to log in with it, by default it’ll use pinentry, which, if started with a DISPLAY environment set, will use the graphical version (in my case, Qt.) The graphical version do not allow you to paste, which makes sense for the passphrase of a private key, or the PIN of a smartcard (if you save those in a password manager in the same system, there is very little protection provided anyway, you can leave them unkeyed.) But if you’re trying to access a service… significantly less so. I worked this around by unsetting the DISPLAY environment variable and using the console Pinentry, and just paste the password in Konsole.

But it goes more interesting when you start noticing things that are significantly broken. Keybase requires you prove access to the key you want to mark as yours, which is the obvious thing to do, and that’s good. Unfortunately they don’t seem to cope well with the idea of key expiration. From what I read in various related issues the reason is that they think key expiration is an useless concept thanks to Keybase. That may be the case if you have no other environment, but I’d think this is a myopic point of view. By the way it doesn’t matter if you extend your expiration date in time, you still have to re-prove it to Keybase because you don’t seem to be able to provide them with an updated copy of the key (like you would with a normal keyserver.)

Once I got access to my account back I managed to re-prove my website; this was needed because I moved providers (long story) for the blog and everything, and so the proof (which for whatever reason I forgot to add to the git repository I store my website on) went… poof. Unfortunately it was a bit more involved than just generating a new proof. Mostly because the fetcher that should verify said proof does not actually respect the HTTP standard requirements and provide no Accept header, which meant ModSecurity kicked it out. You’d expect that a service that is all about security and trust would at least be able to implement the protocol correctly.

To finish this off, I really dislike the “limited invites” options in general. I understand why that’s needed, but it just feels a bit useless to me, particularly when, just because I logged back in, the system granted me more invites — with the “cute and whimsical” notion that it’s the founder of the service to “grant” you those invites. Heh.

All in all, I don’t have much real use out of this system. I signed up because it was suggested it’s a nice way to prove my identity but I don’t feel it’s any better than the Web of Trust, and I’m not saying the WoT is good.

Oh well, if it takes off I’ll be there, if not, I have only spent a minimum amount of time on it.