Signal is useless for the only people it could be useful for. Most people don't need better-than-TLS security, and for those people Facebook Messenger or any number of other options are perfectly adequate. The people who do need better security are precisely the same people who a) can't afford to use phone numbers as IDs, not even burner phones, when they mean a hostile government who captures one person can immediately start tracing the location of all their contacts and b) can't afford to trust an unaudited server run by a company that could relatively easily be forced to cooperate with a hostile government (particularly when the encryption protocol uses a novel semi-TOFU construct that makes attacks a lot more plausible when the server is cooperating).
There are threat models where TLS is good enough. There are (mostly quite paranoid) threat models where GPG, for all its usability issues, makes sense. There is no threat model where Signal makes sense.
Finally, GPG's usability issues are contingent and fixable. Probably in GPG-the-program, and certainly without abandoning OpenPGP-the-protocol. Throw a bit of money at it, get an actual UX designer to spend a couple of months on a nice UI, and who knows where that would take us? Whereas Signals flaws are there by design.
I agree with the literal interpretation of this statement; most Signal users don't need that level of security. But many users want a level of security that makes it much harder for their government to intercept their messages, and I believe Signal is better for that than Facebook Messenger. I think you could make a convincing argument that Whisper could be strong-armed by the US government, but for me it seems unlikely that they could be compelled to install a back door by Turkey, Russia, China, or some other such illiberal regime (at least, less likely than Google/Facebook).
For example, see https://www.cultofmac.com/426440/whatsapp-wins-encryption-vi..., where WhatsApp (which uses the Signal protocol) was not able/willing to hand over message data to a Brazilian court. That is the feature that Signal users are choosing that FB Messenger does not have.
> I think you could make a convincing argument that Whisper could be strong-armed by the US government, but for me it seems unlikely that they could be compelled to install a back door by Turkey, Russia, China, or some other such illiberal regime (at least, less likely than Google/Facebook).
> For example, see https://www.cultofmac.com/426440/whatsapp-wins-encryption-vi..., where WhatsApp (which uses the Signal protocol) was not able/willing to hand over message data to a Brazilian court. That is the feature that Signal users are choosing that FB Messenger does not have.
Actually I'd say it's a feature that FB Messenger has and Signal doesn't, since the salient fact is that Facebook inc. refused to turn over private messages. Facebook has the resources to play hardball with governments; they could afford to have their service shut off for 3 days in Brazil. Does Signal have that kind of warchest?
I'm not sure if they need a warchest; my point was that Whisper don't have a presence in Brazil and so they probably couldn't be compelled to do anything by the government there, whereas FB has employees and execs there, and directly do business there, so there are all sorts of levers that the Brazilian government can (and have tried to) pull to compel them. Frankly I suspect it would be good press for Moxie if he had an arrest warrant outstanding for not turning over customer messages to a government.
Also note that FB Messenger doesn't have e2e encryption, and I'm fairly sure that FB would hand over any data that they do have to any government that asked. They certainly hand such information over to the NSA.
The reason I brought WhatsApp in as an example was because even Facebook, a company well-known for sharing its users' data with government security agencies, was not able to share Signal messages. That is fairly strong evidence that their protocol implementation does not have a secret backdoor; if there was such a backdoor, there would be no story of an FB exec in jail, since FB would have quietly handed over the messages that Brazil asked for.
To add to this, I believe Signal is open source and has reproducible builds so its chances of getting away with mischief on a large scale are much lower than Facebook's / WhatsApp's. Even if you (weirdly IMO) think Whisper Systems is less trustworthy than Facebook.
As usual, I'll add that GPG was Snowden's tool of choice because it was one of only things hampering mass collection at NSA. If it stops NSA, it can probably handle other attackers that don't have a budget of $200+ million a year for bypassing security. Definitely worthwhile to start with a known-good tool to do UI or other improvements.
Moxie's point was that GPG doesn't hamper mass collection at NSA because nobody uses it! GPG is definitely more secure than Signal. Signal has probably encrypted more messages than GPG, despite being around for only a fraction of the time.
Well, he's definitely discouraging using it in the post. He also strawmans the usability with his power, flexibility, and huge man page argument. Here's how easy it is to use after you swap keys with someone:
1. Type message in a text file.
2. Use one command to encrypt that.
3. Send the encrypted file to the other party using what medium you deem convenient or necessary.
4. Other person uses one command to decrypt it.
That's all. There's people in police states that communicate with me regularly with that method. Non-technical people I've shown find it simple but tedious. So, that's what we should recommend if we want to avoid the complexity. If he's being fair, that's what Moxie should be comparing any new solution against when assessing how easy it can be (or isn't) to use GPG.
Further, we can either modify the program and/or put a front end in to remove what little complexity it has. Especially knock out the ridiculous delay on randomness, pick good ciphers by default, and eliminate putting the sender/receiver full name in there. Just click a person's name for the latter. I'd have already done the stuff myself if I could stomach learning C++ plus whatever the author's style is. Maybe add SaferCPlusPlus or something like that to further reduce likelihood of code injection. If preventing injection and using isolation mechanisms, one could just freeze the forked codebase not adding anything else to it past protocol-level fixes that are required over time for just the features one uses to encrypt or decrypt a text file. Then, slowly rewrite and/or subtract pieces from it to make it simpler over time.
That should've been the response a long time ago. It would've saved cryptographers and security professionals that know C++ a lot of criticism. They could've just posted a link to the simplified program I just described that's a two-step process for each party when sending messages.
I intentionally left out key exchange to see if anyone would ignore my points on ease of messaging to focus on something else. Nice taking the bait. ;) Yes, we can do a front end improvement on that part, too.
What you think about my greater claim that one can use it effectively exchanging text files after learning a handful of commands? It's more important because it refutes the GPG is too hard argument.
Not that I use GPG, but that is exactly how I would. write text, encrypt, paste base64 nonsense into email, verify I'm sending nonsense, send. So many failures result from trying to make things "easy" and so you get people full quoting in plaintext, cc to the wrong person (transparently encrypted with their key, so they can read it, etc.).
I disagree that GPG is easy, and I think telling people to use it will mean they screw it up. But I also think efforts to make it easier are likely to automate failure.
Why would people paste the text into the composer rather than attaching the file?
> I disagree that GPG is easy, and I think telling people to use it will mean they screw it up.
We can tell people to zip up files (possibly encrypting them with a password) and attach them to an email, but I've never heard anyone argue that telling people to do that would mean that they would screw it up. What makes GPG different (other than the public/private key thing)?
Maybe one way to introduce people to GPG would be to have them use symmetric encryption at first to send messages and files (as an alternative to a password protected zip or other archive format).
Then tell them that if they create keypairs, they only need to give the other person their public key and the other person does not need to tell them the password of the day anymore to securely send the message.
Note that Im telling them to attach a text file they encrypted rather than mess with encodings and stuff. They just encrypt a file, attach it, done. Alternatively, the front end has a built in editor that outputs an encrypted file with the name they pick.
Far as failure automation, you could say that about anything. Ive reduced the problem of communicating to two steps. Most things aren't that easy centralized or decentralized.
The closed and centralized nature of their backend in combination with them being a very small team makes them especially vulnerable to being compromised.
Are we sure no single employee can be pressured by the government they operate under or the company as a whole?
Are we sure none of them are compromised and perhaps don't even know it?
Who holds the signing keys for the mobile apps? How have they been handled?
Are their internal CI servers secure? Do they do reproducible builds? How can we verify no last minute changes were slipped in by an employee or an NSA operative that has broken into their systems?
Considering Moxie has been openly opposed to third parties wanting to do externally verified reproducible builds such as f-droid... I simply can't have much confidence here.
On their website signal says they "...design open protocols, develop Open Source software, and give it away for free."
In spite of this, they do not allow spinning up your own clients and servers to validate their work without forking their client and re-implementing portions of their server.
I would challenge that we should not run from a situation where we have too much trust in one entity only to put complete trust in another.
I don't totally understand why you can't just swap public keys and just send GPG-encrypted messages.
I also don't fully understand why Signal needs to be centralized. What if it were a generic chat server that could, optionally, receive messages via SMS?
> An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do.
That's fair, but it still entails additional trust in the host. On, e.g. Matrix, I can run my own homeserver, so if something evil happens on another homeserver it's not really a big deal for me, unless there's a protocol vulnerability that allows them to mess with my own homeserver. Whereas on Signal, I might not even know if the centralized host has been compromised, and then as a casual user I have to wait around until a non-compromised host has appeared.
I get it, but I don't really get it. The argument that "federation does freeze protocols in time" doens't make a ton of sense to me. Just look at Bitcoin: people want to keep participating, so they upgrade. It's probably easier to get a bunch of scattered servers to upgrade than a few centralized ones.
Absolutely, it's a trade-off, and is probably strictly worse for power users.
As a counterpoint to Bitcoin (which is still quite a young and under-adopted protocol), consider how hard it has proven to upgrade the IP protocol from version 4 to 6 (20 years and still not complete?)
Ip works at a much deeper level which is why it's harder to change. Everything uses ip, including hardware and software that's no longer getting updated but is still in use.
Which supports my point -- the quote "federation does freeze protocols in time" was being questioned, and IPv4 is the textbook example of a federated protocol that was frozen in time.
I have a lot of respect for moxie helping create the signal protocol. I think the problem is many extend that respect to take his word as gospel for everything else, including stuff like this that is total nonsense.
1) We -can't- just take the backend of signal and deploy our own because all clients are hardcoded to use Signal central servers. You currently -must- trust central Signal servers to not store metadata and the government their servers live under. You totally can have end to end encryption -and- have federation as Matrix.org and Riot.im have well demonstrated.
2) There is no reason at all you need to be centralized to encrypt SMS via the signal protocol. The Silence project has already demonstrated this https://silence.im/
tbf, decentralisation + e2e crypto is hard, as we've discovered at Matrix & Riot. You can have some wonderfully nasty situations if you don't know which devices (or even users) are in a given room, because the room is by definition not globally consistent due to being decentralised. Although we're doggedly working through addressing all the edge cases which result; my guess is that it's about 6x more work than the equivalent centralised service.
If you like minimalism, try trojita (http://trojita.flaska.net/). It's basically an IMAP explorer with lots of rfcs implemented and gpg support. Takes 1 minute to configure. It might have some rough edges, but I always find its lightness welcome when I'm using other bloated apps.
It seems nice, but for some reason I can only set a global username for imap, rather than a per-email one. How can I log in to multiple gmail imap accounts?
> I think it would be good to read this post remembering that Moxie is competing with OpenPGP with his Signal app.
No, this is incorrect, for several reasons.
1. Signal and OpenPGP have substantially different intended use cases. OpenPGP is a protocol for encrypting and signing fully offline, asynchronous messages using only public-key encryption and digital signature schemes such as RSA and DSA, respectively. Signal is an OTR-based protocol for both asynchronous and synchronous messaging. You can send something that looks like email using Signal, but you cannot natively use OpenPGP for encrypted instant message, voice calls or video calls.
2. Due to these differences, OpenPGP and Signal also have substantially different features. OpenPGP is not only intended for asynchronous messaging: it cannot be used for synchronous communication from a purely technical perspective. OpenPGP does not have a native system for symmetric encryption or key exchange, which means it cannot establish or maintain a secure channel efficiently. Therefore by necessity OpenPGP is slower and has higher latency because it can only natively implement public-key encryption for communication, and users must manually supply the rest. Signal's cryptosystem is much more sophisticated, and incorporates mechanisms for public-key encryption, digital signatures, private-key encryption and key-exchange.
3. Aside from just supporting synchronous communication, Signal's larger cryptosystem scope allows for security guarantees beyond the basic trifecta of confidentiality, authentication and non-repudiation that OpenPGP cannot provide. For example, Signal's protocol provides perfect forward secrecy and message delivery notification. You could only do this using OpenPGP by manually handling key exchange, then manually pre-sharing sufficiently large secret keys, or doing a new key exchange for each communication.
Furthermore, Signal is an open protocol much like OpenPGP, and in that sense doesn't "compete" with any other protoco. I use both Signal and GPG, and I'm not affiliated with Signal; that said what I'm trying to convey here is that OpenPGP has significant technical limitations that make it basically ineligible for being fairly compared with Signal (or any other similarly sophisticated messaging cryptosystem). Moxie and Perrin didn't really have to "compete" to get the Signal Protocol adopted at a massive scale by Google and Facebook - from a technical and usability perspective it enables secure communication that OpenPGP simply doesn't.
> You can send something that looks like email using Signal, but you cannot use OpenPGP for instant messaging or phone calls.
Of course you can use OpenPGP in IM [0] but as you note it won't have perfect forward secrecy and has some disadvantages but could you show me how to send an e-mail through Signal?
> OpenPGP at it's core is surprisingly simple standard
A simple standard doesn't automatically give you an end-user product that is simple and that anyone wants to use. GnuPG as a piece of software is ridiculously complicated and uses terms and concepts that the vast majority of people don't and won't understand.
Is it possible to make a simple experience from the OpenPGP spec, one that would be accessible to the majority of non-technical users, and could be seamlessly integrated into common communications workflows? I don't know, though I would suspect it's not.
> A simple standard doesn't automatically give you an end-user product that is simple and that anyone wants to use.
I never said it does. What Moxie claims is that decentralized standard (like OpenPGP) will always be worse than centralized, curated solution (like Signal).
As for making OpenPGP easier to use check out OpenKeychain [0]. The developers have clear design guidelines to keep things simple.
Another example of decentralized solution more in line of the current messanging topic: Conversations.im [1] - supports end-to-end encryption and you can set it up on your own server (uses XMPP).
> is ridiculously complicated and uses terms and concepts that the vast majority of people don't and won't understand.
You are being a bit harsh. Sure, it's complicated if you don't understand the basics of public key encryption, but as soon as you do, GPG is trivial to use.
The problem most people have is an unwillingness to learn the basic concepts. Public key encryption is a novel idea, and really isn't hard to learn.
> Is it possible to make a simple experience from the OpenPGP spec, one that would be accessible to the majority of non-technical users, and could be seamlessly integrated into common communications workflows? I don't know, though I would suspect it's not.
I suspect it would. Certainly it's not a possibility we should write off when no-one's seriously tried.
I think people have tried, and the only meaningful success has come from approaches that build key management into the mail client and make it transparent. At first blush this seems great, but there are drawbacks that make it not worth that much:
1) For a web-based client, the keypair is stored out of the user's control, so it ends up meaning you're outsourcing trust to a third party, not just that they're trustworthy, but that they'll never experience a breach.
2) For a local client, the keypair isn't backed up anywhere, so if the user switches computers or suffers a hardware failure, the key is gone. These days you can mitigate that issue by integrating a cloud backup feature, but then you're risking that the user is protecting the private key with a weak password (which I'd expect to be common). I expect that most people don't use thick clients these days, outside of corporate use that mandates Exchange/Outlook or something similar.
3) You don't get the benefits of the web of trust. These sorts of users will never go to a key-signing party or anything like that, so one of the stated goals of OpenPGP -- that you can examine that web to feel safe that you're actually communicating with whom you think you are -- just falls away.
> I think people have tried, and the only meaningful success has come from approaches that build key management into the mail client and make it transparent. At first blush this seems great, but there are drawbacks that make it not worth that much:
I'd say no-one has tried at the level of committing significant resources to it - i.e. a couple of full-time developers/designers. Certainly not the level of investment that Signal has got.
> 2) For a local client, the keypair isn't backed up anywhere, so if the user switches computers or suffers a hardware failure, the key is gone. These days you can mitigate that issue by integrating a cloud backup feature, but then you're risking that the user is protecting the private key with a weak password (which I'd expect to be common). I expect that most people don't use thick clients these days, outside of corporate use that mandates Exchange/Outlook or something similar.
All true. I'd hope that hardware tokens (Yubikey et al) could offer a solution, if we could agree on a standard for them. A good "web crypto" API would also be a huge help - browsers are more willing to add new APIs these days, so something like an encrypted input field where the cryptography is managed by the browser and the far side never sees the plaintext is a bit more feasible. Also the rise of bitcoin means people are having to get used to the level of key/passphrase security necessary for securing genuinely valuable things - we're seeing a new wave of interest in things like SSSS split keys. There are serious challenges, but there's room for hope as well.
> 3) You don't get the benefits of the web of trust. These sorts of users will never go to a key-signing party or anything like that, so one of the stated goals of OpenPGP -- that you can examine that web to feel safe that you're actually communicating with whom you think you are -- just falls away.
True, though there are also a lot more ways identities could be passed around these days. When Keybase started I dared to hope they'd help improve the OpenPGP ecosystem, though they seem to have gone down the opposite track now.
I think the downside of many approaches is the "lose it and it's gone forever" aspect. Users just aren't used to that failure case. There's always a password reset link that gets you back where you started. If you have PGP-encrypted mail and you lose access to the private key, you've lost access to that mail forever, and that's still not a very well-understood concept to many people. Awareness of this sort of thing is certainly getting better, but arguably we aren't to a point where your average user is comfortable with that yet, and we certainly weren't there back when OpenPGP was first designed.
It's possible to use OpenPGP in instant messaging [0] and it works fine (transparent encryption and decryption in a client) although there are newer solutions more suited to IM [1].
I mean that at least relatively speaking, nobody[1] uses OpenPGP for messaging, so it's not a threat to Signal's market share. Which is presumably the implied motive for Moxie to trash talk OpenPGP.
[1] I can admittedly think of two people I know for whom I could probably find public keys and who would probably be able to decrypt a PGP'ed email if I were to send them one, but they're both Debian maintainers who I met via IRC. Whereas I have maybe a couple of hundred people on my phone from various walks of life I could send Signal messages to with literally no extra effort.
> Which is presumably the implied motive for Moxie to trash talk OpenPGP.
I'd rather say that Moxie implies that OpenPGP is broken beyond repair and thus the only alternative is his centralized solution. While he doesn't say this explicitly his other post (The ecosystem is moving) says exactly this.
Your anecdotal evidence while interesting does not show that OpenPGP cannot be improved, only that given enough government funding you can build a nice centralized, encrypted solution but as the top comment by lmm shows [0] it's not clear what audience is Signal aimed at:
> There is no threat model where Signal makes sense.
> It's possible to use OpenPGP in instant messaging [0] and it works fine (transparent encryption and decryption in a client)
For some definitions of "possible" and "works fine", sure. But OpenPGP is not natively designed for instant messaging. You can use OpenPGP as the public-key component of a cryptosystem that is suited for instant messaging, but at that point you're better off just going with an OTR protocol that already has the key-exchange and secret-key encryption functionality baked into it.
Beyond that, the page you're citing mentions this:
> The method defined herein has the following security issues:
> Key exchange relies on the web of trust model used on the OpenPGP keys network.
> There is no mechanism for checking a fingerprint or ownership of a key other than checking the user IDs on a key.
> When the recipient is not mentioned in the encrypted body, replay attacks are possible on messages.
> Replay of the signed <presence/> status is possible.
> It relies on signing or encryption of XML character data; therefore, it does not support signing or encryption of <iq/> stanzas, and it allows signing of the presence <status/> element and encryption of the message <body/> element only.
> Thus the method is not acceptable when signing or encryption of full stanzas is required.
It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.
In particular, the warts of using an asynchronous protocol for a synchronous communication system are exposed here: you can replay the signed presence status, which sort of defeats the purpose of having an open connection. In a secure, synchronous communication channel, the "freshness" checks incorporate non-repudiation. This is before we even address the problem of not being able to verify key ownership aside from the user IDs.
> When I receive a GPG encrypted email from a stranger, though, I immediately get the feeling that I don’t want to read it. Sometimes I actually contemplate creating a filter for them so that they bypass my inbox entirely, but for now I sigh, unlock my key, start reading, and with a faint glimmer of hope am typically disappointed.
I wonder what proportion of his plaintext email from strangers is interesting. For me it's close to 0%, mostly spam or people demanding I do free work to fix issues in open source code. I really doubt this has much to do with GPG mails specifically.
To contrast this, in the last bug bounty page I set up I strongly suggested researchers gpg encrypt email to submit their findings. I really didn't want sensitive issues directly exposed to our entire support team.
As it turns out, the gpg encrypted emails which were only a small fraction of the ones we received, and made up the substantial majority of actionable issues we rewarded on.
If a security researcher is not capable of encrypting email to a public key, they probably are not bringing me anything worth my time to read.
I wonder if he has an especially onerous password? It doesn't seem like it should be that big of a burden to pop in the password for an email. I guess he has it set for ultra-paranoid mode where you have to enter the password every time you even think about touching the mail.
I do agree that GPG has been largely a failure. A tool too general and too vaguely defined for the average user. A powerful tool but only really usable by crypto nerds. What's worse, the key distribution problem was never really solved and that's the most critical component of the entire system. Even today there are scant few email clients that will query the keyservers for you.
Since my GPG subkeys are in my yubikey I literally just tap it to decrypt, ssh, or sign commits. I also plug my key into my phone and tap it to decrypt/sign email or decrypt passwords too.
I have sucessfuly migrated dozens of friends and engineering teams at 3 companies to daily use of gpg via this same non-intrusive setup.
GPG is fairly pain free (and far more secure) if you put in the one time effort to set up a security token.
It seems to be a workable option with PGP/GPG, but do you have to plug it in per use rather than leave it in as this post says (to use the onscreen keyboard)?
I'm not, primarily, an Android user so I wasn't aware of that option. Thanks. I have a USB-A yubikey and just got a laptop with USB-C ports and an adaptor so I guess I'll give this a go on my backup Android phone tonight.
Most of them do, however in multiple groups I have been part of we maintained a git repo containing all trusted public keys ready to batch import.
To make maintianing trust on this easy, all commits to this folder are made with commits signed by the owner of the respective key, and then a merge commit signed by a maintainer that verified it.
This makes it really easy for automation to have a source of trouth to check/validate commit signatures in other repos.
With GPG there are many more options: have internal keyserver, have "certification authority" key that signs new employee keys and everyone else trusts this authority (via trust signatures. For details see: https://www.linuxfoundation.org/blog/pgp-web-of-trust-delega...
Too many options, honestly. I'd love to see a widely agreed "basic profile" for GPG, so that everyone writing tutorials etc. would be suggesting the same thing.
The cryptographical ideas behind GPG are not flawed in principle, but the usability is absolutely atrocious and it's easy to get things wrong.
I imagine that a good ux-designer or two could do wonders for it.
"Mailpile had to write 1400 lines of python code just to interface with a native GnuPG installation for basic operations, and it still isn’t rock solid."
* Add an authentiction subkey and you now have a drop-in-replacement for ssh keys.
* Password managers like "Password Store" use a git repository full of gpg encrypted files as a backend allowing for a secure password management solution that only decrypts the credential you need vs decrypting -all- of them at once like most popular tools.
* If you make use of the solid smartcard support you can even avoid your keys ever being exposed to system memory where malware can steal them.
S/MIME and X.509 generally are used in enterprise scenarios where people want one corporate Certification Authority and thus keeping things simple (the underlying encoding is far from simple but that's another topic).
this smacks of he usual “hard work is hard” argument and i for one am sick of hearing the excuses. gpg has had ecdh and curve25519 for an entire version, rainloop and thunderbird and mutt all handle pgp seamlessly. having to trust a key is a bit archaic, but this is all worth it for he one reason openpgp exists: security
Gpg still has a lot of uses. There isn’t one solution for every problem nor is there a single solution for any single problem. We need to have as many tools as possible if we the people want to win.
How does a user send a file of arbitrary type through Signal?
Is it true that PGP has uses that do not overlap with Signal?
If no, then please ignore the rest of this comment.
Is it true that a block cipher has uses that do not overlap with a stream cipher?
Signing and verfiying files.1
Encrypting files.
From what I have read, Signal is concerned with messaging. But there is more to PGP than just messaging. Files that need to be signed/verified or encrypted do not necessarily always have to be sent to or received from others.
The blog post singles out one particular use of PGP, i.e. email, and complains about one implementation of PGP: GPG. Maybe the GPG software is not user friendly. Maybe PGP email is hopelessly complex. It is easy to make those arguments. Many have done it before.
However PGP encryption, in the general sense, not when used for email and not necessarily as implemented by the GPG software, can still be useful.
Files can still be useful, even when not in the context of the "messaging" business, Twitter subsidiaries, Facebook subsidiaries, advertising, smartphones, etc.
1 I prefer ed25519 for signing and verifying files but perhaps there are advantages to PGP I am not aware of.
Exactly, OpenPGP is more like a framework for many things and the underlying structures support cryptographic agility (switching algorithms). OpenPGP can also be used to authenticate to servers (like SSH keys) and for broadly defined trust management.
There are threat models where TLS is good enough. There are (mostly quite paranoid) threat models where GPG, for all its usability issues, makes sense. There is no threat model where Signal makes sense.
Finally, GPG's usability issues are contingent and fixable. Probably in GPG-the-program, and certainly without abandoning OpenPGP-the-protocol. Throw a bit of money at it, get an actual UX designer to spend a couple of months on a nice UI, and who knows where that would take us? Whereas Signals flaws are there by design.