Cryptography Dispatches: Hello World, and OpenPGP Is Broken(buttondown.email)
buttondown.email
Cryptography Dispatches: Hello World, and OpenPGP Is Broken
https://buttondown.email/cryptography-dispatches/archive/cryptography-dispatches-hello-world-and-openpgp/
65 comments
OpenPGP is broken in the sense discussed in this newsletter: the keyserver system interacts in a catastrophic way with GnuPG's naive key parsing code, and OpenPGP's deployment at scale depends on keyservers.
OpenPGP is broken in other ways! But this is a headline given to a particular current events story about OpenPGP.
OpenPGP is broken in other ways! But this is a headline given to a particular current events story about OpenPGP.
Then there is no need to say OpenPGP is broken.
Once you hand off the validation to a 3rd party that does nothing to validate other than a voting system of other people then you are done. You basically put your PGP keys on reddit and decided the key is valid because it made it to the front page.
PGP may be many things, but it is not broken, and saying so is blaming the tool for a obviously bad use of it.
Once you hand off the validation to a 3rd party that does nothing to validate other than a voting system of other people then you are done. You basically put your PGP keys on reddit and decided the key is valid because it made it to the front page.
PGP may be many things, but it is not broken, and saying so is blaming the tool for a obviously bad use of it.
It is obviously broken. Your objection is that it isn't comprehensively or irretrievably broken, and while I disagree, I don't have to litigate that, because the narrower sense of the word carries the article.
I don't think you can fall back on this being an "obviously bad use of the tool", by the way, since it's a pretty core use of OpenPGP. I don't use keyservers either (or didn't, when I still used PGP, which I actively avoid doing now), but I'm outnumbered by the people who do.
I don't think you can fall back on this being an "obviously bad use of the tool", by the way, since it's a pretty core use of OpenPGP. I don't use keyservers either (or didn't, when I still used PGP, which I actively avoid doing now), but I'm outnumbered by the people who do.
[deleted]
What do you use for secure communication in lieu of openpgp?
Signal or Wire, magic-wormhole. The obvious stuff.
And yet all of those bypass the hard part of validating the sender. These again trust the service.
PGP is more than simply encryption. It provides a means of trusted identity.
End to End encryption is pointless if you have no way to validate that a message came sender. Relying on automated systems for key exchange will always suffer from this problem.
PGP is more than simply encryption. It provides a means of trusted identity.
End to End encryption is pointless if you have no way to validate that a message came sender. Relying on automated systems for key exchange will always suffer from this problem.
That "means of trusted identity" doesn't work, to a first approximation nobody even attempts to use it, of those that do, a vanishing fraction "succeed", and their reward for doing so is the adoption of rickety 1990s encryption. Among practicing cryptography engineers, "web of trust" is a punch line, not a goal.
The lucky PGP users stick to the command line, which is so clunky that they'll use it rarely. The less fortunate will use PGP email clients which are so poorly thought out that they just last year managed to exfiltrate plaintext to attackers.
Signal use in the real world dwarfs that of OpenPGP; it's almost certainly many orders of magnitude.
The lucky PGP users stick to the command line, which is so clunky that they'll use it rarely. The less fortunate will use PGP email clients which are so poorly thought out that they just last year managed to exfiltrate plaintext to attackers.
Signal use in the real world dwarfs that of OpenPGP; it's almost certainly many orders of magnitude.
I am not trying to win a popularity contest. If you care about secure messaging, and want to be sure you about who you are talking to -- then you have to use something like pgp.
I don't think the number of people using something invalidates a technology's technical merits. All we now have is a bunch of people thinking they are secure to one day have a very rude awakening not if, but when their communications are compromised at for the sake of popularity and ease of use.
Most of the arguments against PGP are about clunky clients, and such, this again is not a argument refuting the technology. Meanwhile the new systems solve the ui problems by dropping the most important part of encryption -- the ability to validate.
So for me, I will stick with gpgp and the like.
I don't think the number of people using something invalidates a technology's technical merits. All we now have is a bunch of people thinking they are secure to one day have a very rude awakening not if, but when their communications are compromised at for the sake of popularity and ease of use.
Most of the arguments against PGP are about clunky clients, and such, this again is not a argument refuting the technology. Meanwhile the new systems solve the ui problems by dropping the most important part of encryption -- the ability to validate.
So for me, I will stick with gpgp and the like.
The only people who agree with you about the need for PGP in serious secure messaging are members of the PGP cheering section. They're an old and venerable social organization dating back to the pre-HMAC CFB-mode cryptography in PGP itself. I have nothing bad to say about their justified and ancient society other than that they are wrong about everything involving cryptography and that they recommend tools that get people hurt.
People who care very deeply about these problems and who have studied them more carefully than almost any message board commenter have evaluated PGP and Signal. Among secure messaging and cryptography engineers, PGP is alternately either amusing or an unfunny hindrance to progress. Signal, on the other hand, won the Levchin Prize at Real World Crypto.
Don't use PGP.
People who care very deeply about these problems and who have studied them more carefully than almost any message board commenter have evaluated PGP and Signal. Among secure messaging and cryptography engineers, PGP is alternately either amusing or an unfunny hindrance to progress. Signal, on the other hand, won the Levchin Prize at Real World Crypto.
Don't use PGP.
PGP is a protocol, there is nothing wrong with it. If you want to complain about good PGP based apps that is a entirely different argument (and it think that is what you are arguing).
Signal is not a protocol, it is a application. It uses open whisper (or some mutation of it) as its underlying protocol. That being said, you are still relying on trust provided by the signal servers that they properly authenticated your phone number. A phone number is a super weak way to verify identity. Lucky signal does provide a way to verify you are actually talking to who you are via the safety code process (in person or out of band). So the end result is Trust us first, then verify later. While most PGP applications require zero trust until verification by means of key exchange.
After all that there is nothing stopping anybody from making a application that works just as signal does but based of PGP, and being just as secure as Signal using PGP. The problem is people who understand this know that using PGP chained with a week service phone number base validation invalidates using the entire point -- so they don't. I personally think that is a mistake. As PGP is way better in the long run because it can be used for more than text chats, and video calls.
> tools that get people hurt.
People hurt them selves using tools improperly.
Signal is not a protocol, it is a application. It uses open whisper (or some mutation of it) as its underlying protocol. That being said, you are still relying on trust provided by the signal servers that they properly authenticated your phone number. A phone number is a super weak way to verify identity. Lucky signal does provide a way to verify you are actually talking to who you are via the safety code process (in person or out of band). So the end result is Trust us first, then verify later. While most PGP applications require zero trust until verification by means of key exchange.
After all that there is nothing stopping anybody from making a application that works just as signal does but based of PGP, and being just as secure as Signal using PGP. The problem is people who understand this know that using PGP chained with a week service phone number base validation invalidates using the entire point -- so they don't. I personally think that is a mistake. As PGP is way better in the long run because it can be used for more than text chats, and video calls.
> tools that get people hurt.
People hurt them selves using tools improperly.
Both of those statements are false.
There are clear things wrong with the PGP protocol. PGP predates authenticated encryption (let alone modern AEAD ciphers) and the hacks PGP came up with to authenticate ciphertext resulted both in stripping attacks and, indirectly, in the Efail attack from last year. It was also Signal's linear packet based key format that resulted in the GnuPG/SKS attacks.
Signal is a protocol; in fact, it was "Signal Protocol" that won the Levchin prize. Signal also doesn't verify identities with phone numbers.
These are just basic, fundamental factual problems with your claims. We're not even getting close to serious comparisons between the two systems; we haven't even talked about forward secrecy, compromise repair, modern primitives, complexity, and UX.
There are clear things wrong with the PGP protocol. PGP predates authenticated encryption (let alone modern AEAD ciphers) and the hacks PGP came up with to authenticate ciphertext resulted both in stripping attacks and, indirectly, in the Efail attack from last year. It was also Signal's linear packet based key format that resulted in the GnuPG/SKS attacks.
Signal is a protocol; in fact, it was "Signal Protocol" that won the Levchin prize. Signal also doesn't verify identities with phone numbers.
These are just basic, fundamental factual problems with your claims. We're not even getting close to serious comparisons between the two systems; we haven't even talked about forward secrecy, compromise repair, modern primitives, complexity, and UX.
If you need ultimate privacy and true end to end encryption , PGP is your tool. You can use over channels you don't trust, e.g. you can easily send PGP messages over Signal or other messenger you can't verify. Only people to discourage use of PGP would be gov reps, as you can choke messenger company to give you a tap to messages, but if someone uses PGP over it, tough luck.
If someone solved the UI/UX problems with gnupg, and came up with a more elegant method of exchanging/validating keys (or even just an alternate keyserver infrastructure with better properties), wouldn't that solve the problem?
Edit: how about a response instead of a downnvote, anonymous detractor?
Edit: how about a response instead of a downnvote, anonymous detractor?
EDIT: guidelines
As a note, I think there are probably better crypto technologies these days, but none of them do what pgp aimed to do, but rather we have a bunch of smaller tools that do small parts that pgp did. I am not going to send you a singed file over singal, and I think it is silly to have to use a alternative means of sending the file that will either remove the ability for authenticity, or require me to do the authentication dance again with you.
PGP suffers from bad tooling, and further suffers from the relentless onslaught of people who want fancy electron or phone apps that can only do a small % of what pgp would allow.
Final note, I think something better than PGP could exist, but nobody has made it yet. In either case, validating keys will always be a hard problem and any attempt to automate it will result in false sense of security. While end to end encryption will keep on lookers from viewing your communications -- you just might find out one day you are talking directly to the people you were trying to hind your communication from.
As a note, I think there are probably better crypto technologies these days, but none of them do what pgp aimed to do, but rather we have a bunch of smaller tools that do small parts that pgp did. I am not going to send you a singed file over singal, and I think it is silly to have to use a alternative means of sending the file that will either remove the ability for authenticity, or require me to do the authentication dance again with you.
PGP suffers from bad tooling, and further suffers from the relentless onslaught of people who want fancy electron or phone apps that can only do a small % of what pgp would allow.
Final note, I think something better than PGP could exist, but nobody has made it yet. In either case, validating keys will always be a hard problem and any attempt to automate it will result in false sense of security. While end to end encryption will keep on lookers from viewing your communications -- you just might find out one day you are talking directly to the people you were trying to hind your communication from.
> Don't use PGP.
How else do you recommend to independently establish a verifiable identity?
How else do you recommend to independently establish a verifiable identity?
Would you happen to know if you can send stuff using Signal to someone whose phone is offline? You do seem to be able to do it using Wire but I would rather avoid it as the device verification seems broken.
Sure. Messaging via Signal (or via any other modern mobile messaging app) is designed to be asynchronous and doesn't require all participants of a chat to be online at the same time.
Signal has perfect forward secrecy though. I am unsure how that could be achieved if phone 1 sends a message, the phone gets disconnected and then phone 2 connects to it.
For an explanation on how Signal achieves forward and future secrecy, see https://signal.org/blog/advanced-ratcheting/ (or https://signal.org/docs/specifications/doubleratchet/ for something more detailed).
You seem to be defending PK cryptography instead of OpenPGP.
Well, I always ignore the more grandiose claims - since there is currently no alternative for GPG, and installing Electron apps for Signal or Wire (which then use a single centralized server) really isn’t a viable GPG alternative
But even if you don’t agree with the argument that federation is dead and we truly need Electron apps (with eternally outdated Chrome instances) for secure communication, still you have to admit that PGP is arcane, the cryptography is not modern, and people by and large are ignoring the “web of trust” system. PGP needs a dramatic overhaul, at the end it won’t really be PGP.
(I am not sure if there isn’t a double ratchet system working in federated way. Jabber with OMEMO/OTRv3? Matrix? I don’t know)
But even if you don’t agree with the argument that federation is dead and we truly need Electron apps (with eternally outdated Chrome instances) for secure communication, still you have to admit that PGP is arcane, the cryptography is not modern, and people by and large are ignoring the “web of trust” system. PGP needs a dramatic overhaul, at the end it won’t really be PGP.
(I am not sure if there isn’t a double ratchet system working in federated way. Jabber with OMEMO/OTRv3? Matrix? I don’t know)
Matrix uses double ratchet crypto and is federated, yes. Encryption is not on by default yet due to UX problems, though. It's supposed to be solved soon.
I wouldn't say the web of trust aspect is broken but non-scaling personally. Key servers and others are "compromises" in a way that can lead to being compromised.
If you don't have an effectively auditible trail of knowledge to be able to tell if someone attempted trickery then it doesn't serve the full purpose - but that doesn't scale well.
If you don't have an effectively auditible trail of knowledge to be able to tell if someone attempted trickery then it doesn't serve the full purpose - but that doesn't scale well.
That's ok, pgp is also terrible to use on the command line so we can complain about that.
Yes
Isn't keybase.io trying to solve this?
They decided to bolt on sending cryptocurrency to people they haven't KYC/AML'd instead.
keybase.io also decided that PGP is terrible and made their own ASCII armor format (that is arguably much better than the horrible abomination that PGP likes to produce).
Basically unless you plug your GPG installation into keybase or do other GPG specific things, it's not using PGP/GPG at all and instead their own format.
Basically unless you plug your GPG installation into keybase or do other GPG specific things, it's not using PGP/GPG at all and instead their own format.
No, it's a choice. It's "pretty good" privacy to exchange encrypted comms via Keybase vs. plaintext. And, yes, if it were existentially important than direct key exchange would be better.
> At least at some points we need proper transactional behaviour and Sqlite implements that by talking a temporary copy of the database - not an option for large keyrings.
I don’t understand how GPG maintainers think they can implement something better (function and performance-wise) than a proper database engine. Also I don’t think GPG will ever need to handle keyring lager than 140TB [1].
[1]: https://www.sqlite.org/whentouse.html
I don’t understand how GPG maintainers think they can implement something better (function and performance-wise) than a proper database engine. Also I don’t think GPG will ever need to handle keyring lager than 140TB [1].
[1]: https://www.sqlite.org/whentouse.html
I’m pretty sure SQLite doesn’t implement transactions that way anyway. That’s a pretty bad misunderstanding of how it works. I suppose it’s easy to think you can do better than SQLite if you think SQLite is really bad.
SQLite never implemented transactions that way, neither in undo nor WAL mode.
Someone might have misunderstood how undo logging / rollback journals work. Only pages to be changed are recorded in the rollback journal, not the entire database.
Someone might have misunderstood how undo logging / rollback journals work. Only pages to be changed are recorded in the rollback journal, not the entire database.
Very nice article, I'll definitely subscribe!
> For example, it was never clear to me whether signing a key meant that I’d verified the person’s identity, or that I then trusted them to verify other people’s identities.
Signing means you verified identity. Trust to verify (also called ownertrust) is controlled by a different setting and you can trust someone to verify other keys fully or marginally (or not at all if you know someone is controlling given key but does not verify others well). See this excellent post for details: https://www.linux.com/learn/pgp-web-trust-core-concepts-behi...
> For example, it was never clear to me whether signing a key meant that I’d verified the person’s identity, or that I then trusted them to verify other people’s identities.
Signing means you verified identity. Trust to verify (also called ownertrust) is controlled by a different setting and you can trust someone to verify other keys fully or marginally (or not at all if you know someone is controlling given key but does not verify others well). See this excellent post for details: https://www.linux.com/learn/pgp-web-trust-core-concepts-behi...
I think he understands that in general. The problem is that, in practice, the "web of trust" depends on significant numbers of users trusting other users to verify still other users on their behalf, which is in practice something most people are (or should be) loath to do.
I think we need to rely on this at some point, though. If my friend Alice introduces her friend Bob to me, that's my only way of determining that when Alice is talking about Bob, it's this Bob and not a different Bob.
I actually don't think there is a problem with the concept of a web of trust per se. It's a fact of life. I think that the software doesn't help you use it appropriately. Even if Alice says that a person is Bob, I should not be fooled into thinking that it really is Bob, or that Bob is trustworthy. All it says is that when Alice talks about "Bob", she means this person who we're calling "Bob". If "Bob" then introduces me to "Cathy", we shouldn't be fooled into thinking that it really is Cathy. However, it's still very useful to know that Cathy is Bob's friend who is Alice's friend. If Alice tells me to talk to Bob's friend Cathy, I can be totally comfortable talking to the "Cathy" that Bob introduced me to.
Just to make a more concrete example, imagine that you have a problem with your software. You contact the company that supplies it and somehow determine that the person you are contacting is really operating on behalf of the company. They refer you to second line support. It would be incredibly useful to know that the second line support person you are talking to is, in fact, the second line support person you've been directed to and not a man in the middle. You don't care who that second line support person is. Maybe they aren't using their real name. Maybe they are an illegal immigrant. None of that matters to you. All you care is that they are the person you were directed to. And if they direct you to third line support, you care that the person you are talking to is the person you were directed to.
People get hung up on the wrong things with PGP IMHO. They check people's passports and include photos in their keys, etc, etc. I mean, great if you are the government trying to ascertain if a key really belongs to a citizen, but completely useless for most practical purposes. All you care about is that chain.
I actually don't think there is a problem with the concept of a web of trust per se. It's a fact of life. I think that the software doesn't help you use it appropriately. Even if Alice says that a person is Bob, I should not be fooled into thinking that it really is Bob, or that Bob is trustworthy. All it says is that when Alice talks about "Bob", she means this person who we're calling "Bob". If "Bob" then introduces me to "Cathy", we shouldn't be fooled into thinking that it really is Cathy. However, it's still very useful to know that Cathy is Bob's friend who is Alice's friend. If Alice tells me to talk to Bob's friend Cathy, I can be totally comfortable talking to the "Cathy" that Bob introduced me to.
Just to make a more concrete example, imagine that you have a problem with your software. You contact the company that supplies it and somehow determine that the person you are contacting is really operating on behalf of the company. They refer you to second line support. It would be incredibly useful to know that the second line support person you are talking to is, in fact, the second line support person you've been directed to and not a man in the middle. You don't care who that second line support person is. Maybe they aren't using their real name. Maybe they are an illegal immigrant. None of that matters to you. All you care is that they are the person you were directed to. And if they direct you to third line support, you care that the person you are talking to is the person you were directed to.
People get hung up on the wrong things with PGP IMHO. They check people's passports and include photos in their keys, etc, etc. I mean, great if you are the government trying to ascertain if a key really belongs to a citizen, but completely useless for most practical purposes. All you care about is that chain.
The kernel of the conceptual problem with this web-of-trust feature is in another Filippo post[1]: when I sign someone's else's key, it is difficult (in practice: impossible) to really know the provenance of that key. The signer could have gotten the key from a keyserver (in which case you now transitively trust the keyserver). Or they could have gotten it from a random email saying "this is my new key". You don't know; the basis for trust isn't there, or rather, to the extent it is, it's only there across strong, short paths in the graph of key signatures; it doesn't scale out to the whole "web".
https://blog.filippo.io/giving-up-on-long-term-pgp/
https://blog.filippo.io/giving-up-on-long-term-pgp/
I'm definitely not arguing against that. I think keyservers are one of the worst things to ever happen. PGP's implementation of the web of trust is hugely flawed. I'm saying the concept is still incredibly useful. I get frustrated when I see suggestions that we should abandon the notion signing other people's keys because users can't be trusted to do it properly.
I think the author of the article you link to is mostly right. Long term keys don't make much sense most of the time. A key that's signed by a million people is useless. I only care that it's singed by the people who are relevant in the context for which I'm using it. Relationships change too. If I've got a key from level 1 support to a level 2 support person, I can't trust 6 months later that the level 2 support person still works at the company. You need to have a context to describe the link in order to understand it. PGP (and by extension GPG) are absolutely horrible in that regard.
I find it ironic that the author says that the best way to reach them is by their Whisper number. This is what frustrates me. We exchange "horribly flawed implementation" for a central trust broker -- who may or may not be trust worthy.
I think the author of the article you link to is mostly right. Long term keys don't make much sense most of the time. A key that's signed by a million people is useless. I only care that it's singed by the people who are relevant in the context for which I'm using it. Relationships change too. If I've got a key from level 1 support to a level 2 support person, I can't trust 6 months later that the level 2 support person still works at the company. You need to have a context to describe the link in order to understand it. PGP (and by extension GPG) are absolutely horrible in that regard.
I find it ironic that the author says that the best way to reach them is by their Whisper number. This is what frustrates me. We exchange "horribly flawed implementation" for a central trust broker -- who may or may not be trust worthy.
This is a very useful way to think about a/the web of trust. Thank you; I am sure I will use it later.
I still think this is a problem of public key servers being a broken idea, rather than PGP itself.
It's 20 years since I've been to a key signing party, but there are still several small circles of trusts where I have very good ideas about the trustworthiness of each member and of the overall circle.
I still trust the crypto that PGP (and OpenPGP) uses. (With the caveat of no forward secrecy unless you try to handle that yourself).
I'm not entirely sure I've _ever_ trusted a key server provided public key, beyond the use case of trying it to open a conversation in which I can verify (to whatever level is needed) whether the person on the other end is the person I am trying to communicate with.e
It's 20 years since I've been to a key signing party, but there are still several small circles of trusts where I have very good ideas about the trustworthiness of each member and of the overall circle.
I still trust the crypto that PGP (and OpenPGP) uses. (With the caveat of no forward secrecy unless you try to handle that yourself).
I'm not entirely sure I've _ever_ trusted a key server provided public key, beyond the use case of trying it to open a conversation in which I can verify (to whatever level is needed) whether the person on the other end is the person I am trying to communicate with.e
If only distributed signatures included trust levels -- then you could at least attempt something like that. Though unfortunately trust levels are themselves incredibly coarse and subjectively determined (does "I trust fully" mean "I checked 6 forms of government ID" or "I know this person by their handle"?).
To be honest, I think Keybase has the only workable solution to this problem for modern online personalities -- tie it to directly to your other identities online such that you would need to break into many accounts in order to fake someone's identity. And individual users can decide for themselves what threshold of trust they have for someone.
To be honest, I think Keybase has the only workable solution to this problem for modern online personalities -- tie it to directly to your other identities online such that you would need to break into many accounts in order to fake someone's identity. And individual users can decide for themselves what threshold of trust they have for someone.
Every two other week, someone writes that openGPG is broken. Guess what they want to say is that if you use PGP in certain ways, it's broken (keyservers, addons like enigmail and so on).
But nobody has ever been able to demonstrate that it's broken if you use it correctly. I'll stick with openGPG.
Is that a fork of openPGP or some other product that is based on the same specs? I could not find anything meaningful for openGPG.
That's because it doesn't have open in its name, it's called GPG or GnuPG.
It's another product based on the same specs.
https://en.wikipedia.org/wiki/GNU_Privacy_Guard
It's another product based on the same specs.
https://en.wikipedia.org/wiki/GNU_Privacy_Guard
OpenPGP is not a product, it's a standard.
Maybe you're thinking of https://sequoia-pgp.org/ or https://neopg.io/ ?
Maybe you're thinking of https://sequoia-pgp.org/ or https://neopg.io/ ?
To be clear: this is a subhed from Filippo's email newsletter (which you should subscribe to), relating a news item about the ridiculous SKS/GnuPG-key-handling fiasco from last week; it is not a comprehensive summary of all the ways in which OpenPGP is broken, despite the title.
OK, we've restored the full article title.
>it is not a comprehensive summary of all the ways in which OpenPGP is broken
Is there a comprehensive summary anywhere?
Is there a comprehensive summary anywhere?
This article by the same author is perhaps not comprehensive, but a good place to start: https://blog.filippo.io/giving-up-on-long-term-pgp/
Except that the article is only about one particular reason the author finds PGP use uncomfortable. It doesn't deal with any "brokenness of PGP" at all.
Or at least a list of topics/keywords to search for to start learning some of the other ways?
yarrel(1)
Just wanted to say thanks for making the awesome cryptography newsletter! Really enjoyed reading this.
I've seen the link from this article before about alternatives to PGP and it bugs me for two reasons. One is the implication that everyone should write all software in Go. The other is that when you swap out one system for half a dozen, you now need to identify yourself half a dozen different ways. That seems confusing.
I've mostly been able to avoid PGP, but one workflow that I haven't been able to find a decent alternative for it Git commit signing.
Does anyone know good alternatives in this space?
Does anyone know good alternatives in this space?
Linus himself has expressed his opinion several times that signing every commit is useless. His posts here explain it a bit: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
Signing every commit can be useless, but signing the releases seems to be important and useful, mainly if the developer releases compiled binaries.
Well yes, signing every commit is useless. He did not however, at any point during that exchange, express the idea that commit signing is a useless activity. And that is what I was referring to.
Currently Git seems to be very much integrated with GnuPG and the same goes for GitHub's UX sprinkles over the signing feature. That is what I'd like a decent alternative to.
I considered using OpenBSD's signify but it does not integrate as nicely as GnuPG signing so I'd basically be rolling my own mechanism (which is fine I guess, but feels subpar)
Currently Git seems to be very much integrated with GnuPG and the same goes for GitHub's UX sprinkles over the signing feature. That is what I'd like a decent alternative to.
I considered using OpenBSD's signify but it does not integrate as nicely as GnuPG signing so I'd basically be rolling my own mechanism (which is fine I guess, but feels subpar)
For the record git signing can also use X.509 certificates but from what I see it's still managed by GnuPG.
I don't use key servers. So when I get an encrypted message from my friend I have no issues.
Allowing a third party such as a key server to play some role in veifiing the authenticity of a key is basically broken from tht start, and has nothing to do with pgp it's self.