Moxie Marlinspike, a security researcher and cryptography expert for whom I have a lot of respect published a somewhat controversial article GPG And Me. Moxie says that he thinks of GPG
"as a glorious experiment that has run its course"
And I hate to admit it, but think he is right. I'd love to believe that PGP will take off in the wake of the Snowden revelations, it will become ubiquitous and built into every mail client as standard. But PGP has been around for almost 25 years now, and GNU Privacy Guard the open source implementation has been around for almost 20 years and it has not gone mainstream. I like the way Adam Boileau from Risky Business1 puts it "If GPG was going to solve our problems it would have by now"
I think the problem with PGP is that you need to make a conscious decision to use it. Any time you have to think about using a security system it's already too much work for most users. Consider HTTPS, my grandfather who will be celebrating his 90th birthday in March uses a tablet to check his online banking. The encryption part of that just does it's thing and gets out of the way, he doesn't have to know what a Private Key or a Certification Authority is he just logs in and it's all taken care of for him.
WhatsApp rolled out the same end to end encryption that TextSecure uses and most of it's user base never even knew there was a change. Apple's iMessage provides robust encryption and again most of it's users would have no idea what a key fingerprint is or how to check theirs but their messages are encrypted.
Even with email now, most mail protocols now (IMAP, POP, SMTP) all run over TLS and while it might not provide full end to end encryption it provides encryption in transit. When you consider the number of people using mail providers like Gmail and Yahoo Mail, it's clear that StartTLS has a much higher adoption that PGP ever will simply because most people that are using it don't know or need to think about it.
Even SSH for the most part hides the cryptography away, sure the first time you connect to a server it asks you to verify the fingerprint2 but after that there is almost no noticeable difference between SSH and Telnet from the end users perspective.
I think for any encryption product (and most security systems for that matter) to take off and go main stream it needs to be almost invisible to the users. If you think "Now is the point where I do the encryption" at any point process then it's too much work. Whether that connecting to a server with SSH, viewing a website over HTTPS, sending an encrypted text message or sending an email it should happen automatically systems should be encrypted and secure by default with no user interaction.
To be clear here, I don't believe that these problems exist because users don't care about security or a too lazy to use a heed security advice. There is a good paper called So Long, And No Thanks for the Externalities from the abstract:
It is often suggested that users are hopelessly lazy and unmotivated on security questions. They chose weak passwords, ignore security warnings, and are oblivious to certificates errors. We argue that users' rejection of the security advice they receive is entirely rational from an economic perspective. The advice offers to shield them from the direct costs of attacks, but burdens them with far greater indirect costs in the form of effort.
I don't necessarily agree with everything in that paper, but I do think that it raise a good point. We as an industry need to make security easier than insecurity.
Episode 355 at 14:00, the section on the post begins at 13:05 ↩
I suspect that most people just blindly accept the fingerprint without checking. But even if it is blindly accepted (and possibly the fingerprints could be accepted automatically and hidden away unless users specifically ask for them) that doesn't mean it's useless. It can still provide a warnings like public key pinning, that way it doesn't stop a man in the middle attack but it means that to go undetected attackers need man in the middle the first connection, and every subsequent connection, with the same key. ↩