The PGP Problem

You can try recommending quicksy. It's been launched fairly recent and is an effort from the conversations developer to reach a similar userfriendliness as other phonenumber-based messengers have, while still being open to other users who decided to go with the regular accounts (e.g. you). You can even bind your phonenumber to your jabber account, so you show up as a concact without them having to add your jabber id to their phonebook.

There's a few places where this engages in goalpost shifting that seems less than helpful even though I end up agreeing with the general thrust. Let's focus on one:

> Put a Signal number on your security page to receive bug bounty reports, not a PGP key.

We can reasonably assume in 2019 that this "security page" is from an HTTPS web site, so it's reasonably safe against tampering, but a "Signal number" is just a phone number, something bad guys can definitely intercept if it's worth money to them, whereas a PGP key is just a public key and so you can't "intercept" it at all.

Now, Signal doesn't pretend this can't happen. It isn't a vulnerability in Signal, it's just a mistaken use case, this is not what Signal is for, go ask Moxie, "Hey Moxie, should I be giving out Signal numbers to secure tip-offs from random people so that nobody can intercept them?".

[ Somebody might think "Aha, they meant a _Safety number_ not a Signal number, that fixes everything right?". Bzzt. Signal's Safety Numbers are per-conversation, you can upload one to a web page if you want, and I can even think of really marginal scenarios where that's useful, but it doesn't provide a way to replace PGP's public keys ]

Somebody _could_ build a tool like Signal that had a persistent global public identity you can publish like a PGP key, but that is not what Signal is today.

Hi Thomas et al.! Good write-up and with several software suggestions that I didn't know. Excellent! I think one thing you are missing is an "alternative" for the identity problem. I somewhat agree that all long-term keys are a problem but how do we build an identity out of a bunch of keys for different systems, covering privacy concerns, with some sort of key transparency to detect attacks, ... I think this would be a very interesting post from you guys that I would love to read. ;)

PGP was a game changer when it was introduced and the idea of a chain of trust was neat.

Unfortunately, its implementations are difficult to use, it was never directly supported by operating systems or major applications, and its crypto agility makes it impossible to write minimal implementations.

I wrote and use Piknik for small files transfer (especially with the Visual Studio extension), Encpipe for file encryption and Minisign to sign software. What they have in common is that they are very simple to use, because they only do one thing, with very little parameters to choose from.

The main reason for having written these in the first place was that PGP is too complicated to use, not that it couldn't have done the job.

I’d argue for replacing TLS if it were plausible to replace TLS for mainstream users. HTTPS is a dumpster-fire for a lot of the same reasons PGP is.

For example, the fact that there’s a grab bag of different ciphers, compression options, and other toggles makes properly picking settings an exercise in copy-pasting from a site you trust or guessing and then running an SSL Labs test until it comes back green. If you miss something, congrats, somebody can MITM and trick your users into downgrading.

Things like this are why the most notable features of TLS 1.3 are the things it removed, more so than what was added.