> Yeah, about that. I never ever ever successfully used the WoT to validate a public key.
If you ever installed a Debian package then you did. A long-term identity as "Bob Jones" might not be terribly useful - but that's not the kind of long-term identity we care about a lot in real life either. A long-term identity as "Debian release manager" or "Signatory on bank account xyz" or even "Wikileaks committee member" is a lot more important, and for those cases PGP becomes very useful.
> Then, there's the UX problem. Easy crippling mistakes. Messy keyserver listings from years ago. "I can't read this email on my phone". "Or on the laptop, I left the keys I never use on the other machine".
These are real problems. We should fix them. But we don't need a new crypto standard to do so! It never fails to amaze me how many people/organizations are like "I don't have the time/money/patience to write a high-quality OpenPGP libary (or a high-quality GPG frontend), but I'm perfectly placed to create a new cryptosystem from scratch."
> Your average adversary probably can't MitM Twitter DMs (which means you can use them to exchange fingerprints opportunistically, while still protecting your privacy). The Mossad will do Mossad things to your machine, whatever key you use.
This is pets vs cattle in the opposite direction. Can Mossad Mossad you personally? Yes, if you're a big enough target, but they can't Mossad everyone. Whereas the NSA can MitM key fingerprints exchanged via Twitter on an industrial scale.
> Mostly I'll use Signal or WhatsApp, which offer vastly better endpoint security on iOS, ephemerality, and smoother key rotation.
If you're using iOS you've already given up against state-level attackers. Anything actually encrypted (e.g. IRC with SSL) is more than adequate in that case. Most people don't need the jump up to PGP, sure. But it's important that the option is there for people that really do need it. It bears repeating that we know, from their complaints in leaked emails, that the NSA can't break PGP when used correctly. That's an extremely strong seal of approval for the most critical use cases for encryption.
You understand the difference between a lone hacker as an APT vs a state level threat as an APT.
That distinction is huge and chooing not to defend yourself against one or the other may allow for huge convenience gains at the cost what is to many a purely hypothetical notion of security.
Can we improve the tools and techniques we have enough so they are convenient enough to not have to make such a choice?
I think the big line in terms of what's practical is whether you're willing to trust the CA system or not. If you are - and I think if your threat model is a lone hacker then you can, compromising a single CA or maintaining an MitM requires a very high level of capability - then while doing SSL right and in a way that will let you detect MitM attempts is by no means trivial, there's such a wealth of messaging options available that I'm just not worried about this case. Use whatever, you'll probably be fine.
Once you step beyond that, there are no convenient options (or to put it differently, all convenient options come with risks that are more-or-less as big as the CA system). E.g. compromising Signal's central servers is probably not substantially harder than compromising a CA, and I simply don't trust that a system that does automated key exchange on first use (trusting the servers) will be able to avoid downgrade attacks by a compromised server. I think to a certain extent usability issues are inherent - if you are unwilling to trust any centralized identity services then you have to show key fingerprints and rely on the user to verify them themselves, there's no third option. At the same time I think we can and should do a lot better than current GPG.
Insofar as that the FBI has to actually crack the device and don't have universal key of some sort. Newer version will (and already are) more secure. Its not perfect because this was 'just' the FBI and 'just' the legal way, but at least its something.
If you ever installed a Debian package then you did. A long-term identity as "Bob Jones" might not be terribly useful - but that's not the kind of long-term identity we care about a lot in real life either. A long-term identity as "Debian release manager" or "Signatory on bank account xyz" or even "Wikileaks committee member" is a lot more important, and for those cases PGP becomes very useful.
> Then, there's the UX problem. Easy crippling mistakes. Messy keyserver listings from years ago. "I can't read this email on my phone". "Or on the laptop, I left the keys I never use on the other machine".
These are real problems. We should fix them. But we don't need a new crypto standard to do so! It never fails to amaze me how many people/organizations are like "I don't have the time/money/patience to write a high-quality OpenPGP libary (or a high-quality GPG frontend), but I'm perfectly placed to create a new cryptosystem from scratch."
> Your average adversary probably can't MitM Twitter DMs (which means you can use them to exchange fingerprints opportunistically, while still protecting your privacy). The Mossad will do Mossad things to your machine, whatever key you use.
This is pets vs cattle in the opposite direction. Can Mossad Mossad you personally? Yes, if you're a big enough target, but they can't Mossad everyone. Whereas the NSA can MitM key fingerprints exchanged via Twitter on an industrial scale.
> Mostly I'll use Signal or WhatsApp, which offer vastly better endpoint security on iOS, ephemerality, and smoother key rotation.
If you're using iOS you've already given up against state-level attackers. Anything actually encrypted (e.g. IRC with SSL) is more than adequate in that case. Most people don't need the jump up to PGP, sure. But it's important that the option is there for people that really do need it. It bears repeating that we know, from their complaints in leaked emails, that the NSA can't break PGP when used correctly. That's an extremely strong seal of approval for the most critical use cases for encryption.