Which key(s) is it signed with? What is the hash of the corresponding unsigned artifact?
Signature verification tools should have some option which prints these things in a machine-readable format.
I did some work on reproducibility of Android apps and system images with Nix, and while defining a build step which can automatically establish these relationships sounds a bit goofy, it can make the issues with underspecified edge cases visible by defining verification more strictly. I did not do this to look for those edge cases though.
I am still working on that type of stuff now, but on more fundamental issues of trust we could start addressing with systems like Nix.
i still believe "pgp is too complex" was the most successful cia counter action after they lost the crypto wars to the people.
solving via nix only works within the flawed assumptions that end users either fully trust google or fdroid and are incapable of anything else.
PGP is too complex. I've known my way around the command line before I learned how to hand-write, and I have to look up the commands to fetch the keys and/or verify the blob every single time. Keyservers regularly fail to respond. There's no desktop integration to speak of. The entire UX stinks of XKCD 196.
Don't blame CIA for obvious deficiencies in usability.
I'm not saying I have evidence that this happened to PGP specifically, just that it doesn't seem at all implausible. If the CIA told me my code was never to get too easy to use, but otherwise I could live a long and happy life and maybe a couple of government contracts it would be hard to argue.
Why a mass-market interface never took off (GPG and other descendants notwithstanding) may indicate that the whole cryptographic idea is inherently not amenable to user-friendliness, but I don't find that hypothesis as compelling.
(It could also be an unlikely coincidence that there's a good solution not found for lack of looking, but that's even less plausible to me.)
Thanks to the efforts of Google to "simplify" smartphones the average young person now couldn't find and double-click a downloaded file if their life depended on it.
In the US, a manual car is considered an anti-theft device. In Europe, basically everyone that isn't obscenely rich has driven a manual car at some point.
People learn what they're expected to learn.
signify[1] is approachable at least for the power users - I could print out that man page on a T-shirt. HTTPS is ubiquitous and easy, thanks to ACME & Let's Encrypt. E2EE with optional identity verification is offered in mainstream chat apps.
And of course there are usability improvements to GPG, being made by third parties: Debian introduced package verification a couple decades ago, Github does commit verification, etc. What's to stop e.g. Nautilus or Dolphin from introducing similar features?
I have no doubt that this is true, but I very much question whether any alternate UX would solve this problem for you, because the arguments for these two tasks are given very obvious names: `gpg --receive-keys <keyIDs>` and `gpg --verify <sigfile>`. There's no real way to make it easier than that, you just have to use it more.
The tool also accepts abbreviations of commands to make things easier, i.e. you could also just blindly type `gpg --receive <keyID>` and it would just work.
I think you are right that UI sucks in many cases, but I think its not intrinsic to PGP - its fixable.
Like you said people learn what they're expected to learn.
However Whatsapp/signal show how e2e can be done in a user-compatible way. By default it simply exchanges keys and shows a warning when key is changed and those who need/want can verify identity.
Missing there of course openness.
I wonder why there aren't more, but there are some, for example Proton's efforts towards encrypted email.
https://proton.me/support/how-to-use-pgp
(I won't mention the relative shortcomings of HTTPS and E2E chat apps here.)
So the rest are actually OK with Whatsapp/Signal having the opportunity to see their messages? I would submit that most are not even aware of the issue...
The identity thing is basically the usability issue for E2EE messaging. If you don't solve that then you have not actually increased usability in a meaningful way. The PGP community understood this and did things like organize key signing parties. When is the last time anyone did anything like that for any popular E2EE capable instant messenger?
The UI still sucks, though, because people ask me what the .ASC attachments sent with all of my emails are and if I've been hacked. When I explain that's for encryption, they may ask how to set that up on their phones if they care, but most of them just look at me funny.
I do use email encryption at my job, through S/MIME, and that works fine. Encryption doesn't need terrible UI, but PGP needs support from major apps (including webmail) for it to gain any traction beyond reporting bug bounties.
Signature verification tools on the command line do not surface enough information to make it easy for their users keep track of what the unsigned input was.
I don't think their users are "end users" though. I am concerned about having better UX and making it more accessible to check these things, but for very advanced users, developers and security professionals. I think surfacing this to end users might come a few steps further down that road, but I am not thinking about that yet. I guess that's why you're talking about trust in google or f-droid, because you're thinking about end users already.
For now at least professionals should have an easy time keeping track of what the corresponding unsigned artifact to a signed artifact is, and we are far away from that right now. You have to write code for that, or inspect the binary formats of those signed and unsigned artifacts. That's not good enough. If that code is part of the tool in the first place, that automatically means that the semantics of the signature are much more well defined.
If we accept that the world has moved to webmail, and use a GUI client, then the way to make it easier is bake in into the client and make it seamless so there's no manual futzing with anything. Make it like TLS certs, so there's a padlock icon for encrypted mail, yellow for insecure, and mail that fails validation gets a big red warning.
Unfortunately, purists in the community could not accept that, so it's never happened, and so gpg failed to get critical mass before alternatives popped up.
with that stigma no company invested in that that entire space for decades! we are still gluing scraps from Canadian phds when it comes to pgp UX.
now that crypto is cool you will get keypass, which is the obvious evolution of "url padlock". either the login button is enabled or not. don't question whats happening behind the curtain.
... the fact this entire comment thread is mixing my loose points about the url padlock (consequence) with the CIA actions on pgp (cause)... sigh. I won't bother anymore. enjoy the bliss.
Do you talk to non-technical people? Some people can hardly turn their computer on. Do you really think PGP is in their grasp?
My father, a farmer type born in 1935, managed to use it easily enough when shown how.
It was typical enough of the tools of the time.
34 years ago the average person did not own a computer. What was computer ownership at in 1990, 10%? The people who owned computers tended to be wealthy, smart or hobbyists which isn't exactly indicative of the average person.
So, your father, who has has somebody who can walk him through it can figure it out. Well guess what, the average person doesn't have a technologically knowledgeable child to show it to them.
Perhaps you have a literate child that might explain context.
Encrypted email is near useless. The metadata (subject, participants, etc) is unencrypted, and often as important as the content itself. There are no ephemeral keys, because the protocol doesn't support it (it's crudely bolted on top of SMTP and optionally MIME). Key exchange is manual and a nuisance few will bother with, and only the most dedicated will rotate their keys regularly. It leaves key custody/management to the user: if there was anything good about the cryptocurrency bubble, it's that it proved that this is NOT something you can trust an average person with.
Signed email is also hard to use securely: unless the sender bothered to re-include all relevant metadata in the message body, someone else can just copy-paste the message content and use it out of context (as long as they can fake the sender header). It's also trivial to mount an invisible salamanders attack (the server needs to cooperate).
The golden standard of E2EE UX are Signal, iMessage, and WhatsApp; all the details of signing and encryption are invisible. Anything less is insecure - because if security is optional or difficult, people will gravitate towards the easy path.
The only use-case I have for PGP is verifying the integrity of downloads, but with ubiquitous HTTPS it's just easier to run sha256sum and trust the hash that was published on the website. The chain of trust is more complicated and centralised (involves CAs and browser vendors), but the UX is simpler, and therefore it does a better job.