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.
