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.
