OpenPGP - the next generation of keyservers

A while back there was talk of encryption at HLB and possibly getting together for a key signing party like we used to do in the old days.

I looked into setting up a SKS (synchronising key server) under docker but it appears that’s an old fashioned idea and most of those projects are five to eight years old and have been abandoned.

The modern approach is to separate non-identity and identity information and link only one key to an email address. For authentication a confirmation email is sent to your email address to authorise the public listing of your key.

keys.openpgp.org runs hagrid. It’s possible to build hagrid from the gitlab repository. However openpgp does not encourage local instances and does not federate for two reasons.

  1. "Federation with open participation requires all data to be public. This significantly impacts the privacy of our users, because it allows anyone to scrape a list of all email addresses.
  2. Servers run as a hobby by casual administrators do not meet our standards for reliability and performance."

I managed to get a local instance of hagrid running but could not hook it up to my mailserver to send the confirmation emails and hence it is of no practical use.

In any event I have activated enigmail in thunderbird and have set signing as my default mode. You can also find me on keys.openpgp.org and on tor for the privacy focused.

I’m definitely keen to play with this a bit more within the group. I’ve used Kleopatra as a frontend for key management in the past, but have since moved away from other large commercial email service to ProtonMail. I didn’t specifically move there for PGP support, but PM does almost everything I need without having to integrate other tools (e.g., Kleopatra) into the workflow. This has also had the nice side effect of dragging the other users at @ samedomainname (i.e., my family) kicking and screaming into the land of PGP, whether they realise it or not.

PM does have several annoying quirks, but one I frequently run into is that it won’t import keys with an expiry date (baffling!). Your key from keys.openpgp.org has an expiry date, so I can’t send you encrypted mail from PM. I’ll send you an [unencrypted] email and see whether it magically works the other way if you were to send me an encrypted reply. I suspect it won’t, but perhaps that’s a roundabout way for me to import keys with an expiry date.

Years ago I also set up the subdomains and paths with 301 redirects to automatically pull the public keys for anyone at @ mydomainname from ProtonMail via WKD, in addition to publishing manually on keys.openpgp.org. The idea is that a user’s public keys should get automatically detected and downloaded by any GnuPG/OpenPGP based client with WKD support, so any emails to @ samedomainname from any other PGP user should be encrypted (or at least the sender is offered the option) without having to exchange public keys first. My setup has never been properly tested, but passes various validators online so I suppose it should work? If WKD and PGP ever becomes more widely supported by one of the bigger email players, then it might help to reduce some of the friction of exchanging keys. The cynic in me thinks that it’ll never happen because it’d scuttle the business model of [large email provider] being able to read users email and sell advertising…

They’re all a very powerful and long standing set of tools which are grossly under utilised, so it’d be great to play with the various implementations and iterations of this within the HLB group.

I have had dozens of GPG keys over the years and have made all the more recent ones time limited.

If the key is valid it seems illogical to disallow it and maybe that’s something to do with not opening old emails on web based mail servers where the encrypting key has expired. It is not quite a self destroying message but it’s getting closer. :face_with_tongue:

However, I note from your private correspondence, that ProtonMail will import my public key when a mail is sent either signed or signed/encrypted.

Enigmail has a long history with thunderbird and the current setup with openpgp is probably as seemless as it gets.

Works for me. :winking_face_with_tongue:

Beyond experimentation purposes, I’ve only ever used keys with an expiry date when the email address attached to the key itself had a limited lifetime (e.g., working with a particular organisation for a set period of time). Key expiration only protects signing of future “documents”. An expired key can still be used to decrypt anything signed with that key, but it can’t be used to sign future items. I don’t set expiries as a matter of course any more, as if the key is compromised then signing things in the future is the least of my worries. Your own mileage may vary, but that’s where I landed with it personally when I started to play in PGP land.

Definitely. Thanks for the experiment. It’s good to know that there’s a workaround to import a key with an expiry date. The expiry date is shown, so the ability to manage it is there, but the “proper” import method doesn’t support it. A bit bizarre, but at least I’ve got a way around it now!

I’ve not used Enigmail, but have heard that Thunderbird plays really nicely with PGP from other people, so I’m not surprised it’s seamless!

Ah yes, with enigmail it did seem less of a hassle to setup PGP encryption than previously and almost seamless.

I’ve been playing with Mailvelope, which is a chrome extension for Gmail.

I reckon i’m also ready with my public key, so i imagine we’ll be handing a thumb drive around on Thursday night.

Following on from our discussions last night, I can confirm that enigmail gpg does not support signing other users’ keys. (See thread above about openpgp’s concern with spam and leaking one’s social graph.)

I did manage to sign Belfry’s public key with gpg on the command line. That is not practical for everyday use and I do not intend to upload the signed key to a SKS keyserver such as pgp.mit.edu.

OpenPGP is simply trying to associate a key with an email address. It makes no attempt to authenticate the user per se. It is up to the sender to satisfy herself that Trusted User owns trusted@user.com.

Would you be able to email the signed key back to me? Thanks for not distributing it - and I have no intention of doing so myself - but I’m really curious to see what the signed key looks like and how it differs from my regular PK.