Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why is PGP not used widely?
89 points by dilithiumhe3 on Nov 3, 2013 | hide | past | web | favorite | 72 comments
In light of the whole NSA leaks etc, I have to ask why we don't use PGP widely. Is it just because it's too difficult or is it because we never thought our emails were ever something to be kept private or just that there was never a need to produce tools to make the technology accessible.

A friend and I were discussing this over dinner and couldn't really pin point the reason. Both of us came across ideas around what could be done to make the situation better but were drawing somewhat of a blank on the question of "why is this not already done?".

I think it's because there still isn't a good metaphor that covers up the complexity of public key encryption. Such a metaphor is a prerequisite for a UI that the average user can comprehend.

First, I think we should rename the keys to 'locking key' and 'unlocking key'. I've had people still scratch their heads at 'public/private' a few days after I've completely explained the concept to them. They find it easier to understand that a lock-only key can be shared freely while an unlocking key has to be guarded.

Second, key exchange and storage has to be transparent to the user. The process can go something like:

1. User 1 clicks 'setup secure email with user2@domain.com'

2. User 2 receives 'user1@domain.com wants to setup secure email with you. y/n? (first make sure that this is really his/her email address)'

3. Based on the response, keys are automatically exchanged and stored.

4. Provide a 'compose secure email' option

5. When adding email recipients, the encryption happens automatically. Recipients with no keys are not allowed in secure mail, obviously.

6. The encrypted form is never displayed on screen. Only a lock icon.

7. On the receive end, a passphrase prompt is displayed when a secure mail is opened

Perhaps commercial/proprietary clients already do this, but none of the free ones I've tried are like this. So I'm stuck with using GPG with only with those who understand how the thing really works.

> First, I think we should rename the keys to 'locking key' and 'unlocking key'.

Why not go a step further and call one ‘key’ and the other ‘lock’? So you can share (copies of) your lock freely with others, and if they want to send encrypted email to you, they take your ‘lock’ and put it on that email. It then becomes obvious that you shouldn’t share the private key (after all, anybody could then unlock the locks) and that you have to make absolutely sure that you get the correct public key from others (as putting a ‘false’ lock on a letter doesn’t help).

Sure, this falls somewhat apart if you also want to consider signing…

That would make for nice iconography - public keys being open padlocks, private keys being keys and encrypted things being closed padlocks.

was bored so made something - http://postimg.org/image/8sm7otl2p/full/

interesting! i can clearly understand what each means, but i think the average person might get confused. how about just the key and the open padlock? signed/encrypted content can have the icon on the side (kind of like the shortcut indicator in windows)?

I might have a bit more of a play about with it, oh and here's the svg as a gist if anyone wants it - https://gist.github.com/anonymous/7308250

Okay, thinking further: The (open) (pad)locks you distribute also carry a seal impression. Then:

- to encrypt, the user takes a padlock of the recipient and adds it to the message.

- to decrypt, the recipient uses his key to open the lock.

- to sign something, you use your key as a seal, creating a unique impression on the message

- to check a signature, the recipient compares the impression on the message with the impression on the lock.

Does that make at least some sense?

I like this metaphor very much. It is much easier to wrap it.

"I think it's because there still isn't a good metaphor that covers up the complexity of public key encryption. Such a metaphor is a prerequisite for a UI that the average user can comprehend."

We already have that metaphor: the private inbox. People assume that their inbox is private and that nobody else can read it; public key encryption is how we ensure that is the case. The UI should treat a public key as a destination.

In fact, we can set things up so that an email address is a public key, though it requires a private key generating authority:


Before dismissing this, consider the following:

1. The key generating authority can be separate from the email service.

2. We can make threshold key generation systems, so that no single entity can decrypt anyone's messages.

3. The sender picks the authority/authorities that the receiver will use. This solves one of the biggest problems with PGP: no matter how badly you want to encrypt, you need the receivers of your message to set up their public keys first.

As everyone is pointi ng out, usability is too low. A good target for usability would be TextSecure, the OTR for sms Android app (why I'm sure everyone is using).

Essentially, TextSecure works because: 1. It reverts to completely normal behavior if the recipient doesn't use TextSecure. 2. It automatically sets up keys if it recognizes the recipient uses TextSecure. 3. It never asks you for anything besides a password when you start the app the first time.

Point 2 is the difficult one for email, as is the the fact that people use email on a variety of devices, requiring syncing between computer/devices.

I would suggest emails get a X-smtg header which advertises the sending device is PGP capable, and the email client prompts the user automatically to set up key exchange. Remains syncing, which afaik isn't the hardest part.

The problem with the key exchange mechanism you've described is it's untrustworthy. The software would be essentially asking "is this initial email from the person you think it is?" which is a tough question to answer given the fact that emails can be readily spoofed. Granted, Bob's key will differ from Mallory's key, but there may be just enough time to do bad things before detection.

Key exchange between people should always require some kind of offline verification. If you don't do this, you can't really trust that the person you're communicating with is who they say they are. It's this key exchange process that's a pain in the ass and prohibits PGP's adoption. We've kinda solved this already with certificate authorities, but they're now considered a weak link in the chain.

> Key exchange between people should always require some kind of offline verification. If you don't do this, you can't really trust that the person you're communicating with is who they say they are.

I know a lot of people who I've never met IRL and likely never will. When you think about it, I already don't know that they are who they say they are.

Many of them live far from me. I don't see a practical way to exchange keys with them offline. You have to travel and do it face to face, or trust that USPS, UPS or FEDEX haven't been compromised. Sure, that's very unlikely for Joe Blow, but still, you're doing it offline for security.

Lastpass and probably others have an online secure exchange tool, but then you have to trust Lastpass (which I currently do, if very uneasily).

This is why theres the web of trust concept. Which is even harder to explain than public/private keys.

I'm not sure the general public needs the level of trust you are describing. The have an email address somehow, from a Facebook chat, business card, or spam mail - and that's the level of trust in identity they are currently comfortable with.

Adding a key exchange with the identity they have - the person handing out biz cards could be lieing about his identity, but if someone else spoofs his key, he will not be able to read the email which will still end up in his inbox, not the spoofers. So now the spoofer needs to control this guys whole box to read and delete the emails, or else he'll be detected. At this point if your box is compromised, pgp isn't providing security. ;)

On the whole it sounds easier to impersonate biz card guy, than to just spoof his real email address and provide a fake pgp key.

(And as for unsolicited mails identity being trusted - Nigerian spam does still work, but the message has gotten through, even to the general populace - people know there is no assurance that identities are real. We just need to NOT undermine that distrust when adding pgp. )

> Key exchange between people should always require some kind of offline verification.

Or a trusted third party (see IBE.)

They have the same benefits and drawbacks of CAs.

> 4. Provide a 'compose secure email' option

There should be only one "compose" button.

If you have exchanged public keys with the recipient, all content sent to her address should be transparently encrypted, period.

People don't care about special "secure" buttons that clutter their screens.

Locking/unlocking key is a great way to think of them!

The issue, in my mind, however, is less the conceptual issue, but more that there's not good way to encrypt gmail/yahoo mail.

For two reasons: because it has a UX that hasn't changed meaningfully since the mid-1990s (GUI tools for GPG/PGP tend simply to wrap the command line UX), and because it presumes that the only reasonable way to use a tool like GPG is to exert fine-grained control over keys and identity.

Email needs to be encrypted opportunistically, without user intervention. GPG could do this; it could generate semi-ephemeral keys as needed and use key continuity, like OTR, to figure out which keys were kosher for which addresses.

Instead, GPG exposes to its users the metaphor of a "key ring" with different kinds of keys and key signatures. That model works for people like me, who use it to secure corp-to-corp communications where I have very specific and fussy requirements for whose keys I'm interacting with. But it doesn't work for end-users at all.

Someone should write a secure-by-default email client that uses the OpenPGP message format and is compatible with GPG, but that ignores the intended GPG security model entirely.

Yup. I have made an active use of GPG over the last few months, and there's a few big problems:

1. A UX that is... Hard. As you say. See the last few minutes of this talk I did: http://youtu.be/LjZk8PP-u3c

2. You can't PGP with webmail.

3. You can't PGP on mobile.

4. This means that unless you're on your desktop, you can't do things like search through older emails, which is really important.

5. It requires both people to use PGP.

I fully agree with your final sentiment. If I could fork myself, this is one of the things I'd be putting a ton of time into.

1. Agreed.

2. http://www.mailvelope.com/ https://countermail.com/ http://www.hushmail.com/

3. http://code.google.com/p/k9mail/

4. Well, you could if you jump through some hoops. Which describes using PGP in general.

5. Not only that, it requires both people to use it _correctly_.

Hushmail has given your info to the Feds. All the others could be. It's a trust issue.

Same with mobile. There's 'pgp for iOS' but I'll be damned if I upload my private key to a system running all proprietary software...

Someone should write a secure-by-default email client that uses the OpenPGP message format and is compatible with GPG, but that ignores the intended GPG security model entirely.

Someone (my company) is trying: https://parley.co

I use GPG quite often but there are many annoying issues:

- Lacking GPG support on iOS devices, the available apps are not integrated with Mail.app (iOS).

- GPG support on OS X devices is usable with Mail.app and GPG Tools ((https://gpgtools.org/) but encrypted mails are not searchable. I use folders etc. but it is still often a pain do browse manually through mail after mail until you find the one you've been looking for …

- Webmail, for example Gmail or Outlook.com, and GPG don't fit together well – if at all.

- The public keychain is not made for use on more than one device, i.e., it's not sync-ready.

- Key verification is bothersome, i.e., you have to attend key signing parties etc.

- There are political issues, e.g., should you upload your keys to key server? If so, with or without signatures? If you upload signatures, you create not only a web of trust but you also expose at least parts of your address book.

- Key servers store long invalid keys and there is no way to remove such keys. The PGP.com key server removes keys if you don't confirm them by mail from time to time. On the other hand, the PGP.com key server only accepts one key per mail address.

- Etc.

Mailvelope [1] has ok support in gmail for pgp.



I'm not sure if mail encryption in the browser is a good idea, especially with regard to the protection of private keys …

And I'm wondering why Mailvelope doesn't support mail signing?

> Mailvelope currently does not support signing of messages.

Probably because you have to make absolutely sure that the things you sign are actually the things sent by the webmail provider, and if they decide to add random stuff, the signature will fail. Encryption is, in some sense, easier.

People cannot use Gmail without help. People have trouble editing wikipedia. People misunderstand some simple concepts.

Even people who have taken the time to install and use PGP, and who seem to want privacy, make weird mistakes such as "Messages encrypted to public keys, to passwords and passphrases, and PGP messages not encrypted at all!"


Usability of Security: A Case Study of PGP 5.0 User Interface http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98...

"Why Johnny Can't Encrypt" http://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Enc...

Even Phil Zimmermann, PGP's creator, says it's too hard to use:

“I hardly ever run PGP. When people send me PGP encrypted mail I have to go through a lot of trouble to decrypt it. If it’s coming from a stranger, I’ll say please re-send this in plain text, which probably raises their eyebrows.“


The average user has no idea just how broken email is w.r.t. the concept of secure and private communication. Google's entire business is built on this broad ignorance. So for that matter is the the internet ecosystem in general if you expand the concept of use of data to include tracking of site access patterns, etc.

Moreover, it's certainly not in SV's vested interests (regardless of recent protestations to the contrary by google, facebook, etc) to see secure mail become the standard, and by extension to broadly educate and move the consuming public to a mindset of security first.

All of that said, the average end-user is/would be befuddled figuring out the use of shared pub keys, the web of trust concept, and in moreover, PKI in the bigger picture.

And even if you could get broad use of pgp going for message payload privacy/security, you don't solve the problem of metadata if you are using the current email protocol.

It's long past time for a new persistent messaging protocol that addresses metadata leakage and payload security comprehensively. There are people working on this now. Hopefully that will drive some positive steps forward on this issue.

In my experience it is mostly due to annoyance. PGP is seamless until someone tries to check their mail on their friend's computer and discovers that encryption works as intended. Then all of a sudden they start begging you not to send them encrypted messages.

I have yet to see any other reason for why PGP is not even used by people for whom it would be easy. Even within the security and cryptography research communities it is rarely used.

The solution to this particular problem is to have smartcards; while we are at it, we should also use smartcards for authentication, so that when you sit down at your friend's computer you plug in a smartcard to log in and to read your messages. Unfortunately that means we need to deploy a bunch of new infrastructure, and I would not count on any help from governments or from the tech community (which is largely monetized by violating user privacy).

I know some folks in the Air Force - all of their ID cards have public/private keys stored on them. They use them (plus a pin) for logging onto their computers at work, all of their e-mails are digitally signed, and the computer is locked just by removing the card from the card reader. Most personnel don't know a thing about public key encryption/two factor authentication, and likely wouldn't care if you offered to explain it to them.

I can imagine this could easily get rolled out if you integrated the public/private keys into driver's licenses. A quick search online suggests that blank cards are about $.06 each in bulk [1], but smart card vary between $.60 and $1.50 [2] (don't take this as definitive - I have no experience purchasing them). I don't think anyone would care paying an extra, say $2 or so whenever they get a new license for the cost of the card plus recouping the cost of hardware to print them.

Phase it in over time - have hand-outs at the DMV answering "What's this funny chip on my driver's license?" Gradually phase it in over time for online tax payments/water bills/etc. - something like "your username and password will be good until {date reasonably far in the future}, but after that you'll need a card reader. You can purchase one for $15 from any of these retailers: ..."

Once both the cards and readers are in place, it's a lot easier to get the critical mass to push for stronger authentication from banks, online retailers, etc. People worried about privacy implication could purchase their own cards from independent retailers and put their own keys on them.

[1] http://www.smartcardsupply.com/Content/Cards/cards.htm

[2] http://www.smartcardsupply.com/Content/Cards/ISO7816.htm

>I know some folks in the Air Force . . .

Interesting. Do all of their work computers run Windows?

Wikipedia gives better overall picture in TL;DR fashion. http://en.wikipedia.org/wiki/Common_Access_Card

I don't think that's as big an issue these days, given the rise of the smartphone - people just use their smartphone for email.

The solution is to make software so the smartphone can act as the smartcard if you really want to go that route.

Smartcard readers exist, and certain institutions use them already, the problem is getting the cards and readers to the masses.

A version of your suggested solution is currently in use in Estonia [1], although it is not really used to encrypt e-mails.

I guess it's one of the virtues of having a population a tad smaller than 1.5 million.


Huh, I don't see what I would have considered the obvious answer among what's already been said.

So, to me, the obvious answer is that if you want to use PGP, you first have to make everyone you intend to communicate with also use PGP. That's an obvious no-go. I would be happy to set it up, but what good would that do me?


PGP is enabled by the recipient, not the sender.

If I release my public key (convincingly authenticated), it's up to the sender to take their time to use it.

> if you want to use PGP, you first have to make everyone you intend to communicate with also use PGP

And that is probably even harder then getting people to quit facebook...

There should be a popular messenger that uses xmpp with otr by default.

Even if you know what you are doing and really must get some secure document to someone then it is far from straightforward. First you need to get the key. Then you need to get that key onto a computer that you believe is not already compromised. Anything running Windows can be assumed to be less than secure. Whatever happens there will be some hoops to go through to get that key, your secret document and some program to spit out whatever it is you are to send.

Then the fun really starts. You send your message, other party claims it could not be opened. So you go through the hoops again and re-send. At this stage you have probably changed a word or two in your source document. But that does not bother you because you are new to this. You send again. Another reply comes back - 'sorry mate...' - so you send again, probably introducing a few more edits.

Then you never hear back from them ever again. As it turns out you have been man-in-the-middled and those requests for a re-send were purely in the expectation that you would change your message slightly. This provides the 'crib' needed to open your message without knowing the key by our friends in Gloucestershire.

Where did my tin foil go?

1) Most people haven't had a need for it. Till now. 2) Encryption is difficult concept for even technical people. 3) Commercial PGP costs too much. Building a quality PKI system for an organization costs more 4) GPG is a pain to use 5) Encryption has been discouraged by the government, companies and users.

The setup phase is too difficult. The complex part is the key exchange phase.

Simple and secure mail is an unsolved problem.

I'm using PGP with all my friends, as well as we have secured our normal SMTP transport with SMTPS and SSL certificate pinning. So everything is now double encrypted. Of course PGP key finger prints as well as SMTPS SSL fingerprints have been verified using alternate communication channel & personal verification. Many people think that SMTP is problematic, but SMTPS with certpin is actually quite good. Messages are only delivered over secure encrypted channel, and only to server which got right SSL cert. So even fake CA attacks won't help in this case, you'll need to have cert with exactly right fingerprint. Uh, yeah, don't use MD5 fingerprints.

Without meaning to detract from some of the excellent explanations in this thread, I should add that it sounds like you're approaching this as if it were mostly a technical problem when as far as I can tell it is mostly a social problem. Social problems are harder than coming up with a tool to make it understandable, although I strongly suspect that's also not as easy as you think it is. The failure modes, corner cases, and generally making it robust to someone who Just Doesn't Get it are what kill you, not the happy path of a user who does roughly what they ought.

Setting aside the social problems of explaining cryptography and generating a network effect, most people assume their communications are not worth listening to. "If they want to listen to/read my mom drone on, they're welcome to it!" Or they assume it happens to "someone else."

I'd expect that most people -- rationally and correctly, I might add -- conclude that it's unlikely to happen to them in any way relevant to their experience.

Anything you suggest has to overcome that inertia. Facebook was a value-add. Cryptography's value-add is subjectively nil and possibly negative (whoops laptop stolen lost my keys) if you don't see the benefit in the first place.

Most people don't care enough to put up with the mild to moderate inconvenience and learning curve. It really isn't a big deal if the NSA reads my email most of the time. None of it is interesting enough to them to actually show it to a human. Of course, that attitude being widespread means it's easy for the NSA to spy on people in situations where it might have a big impact on politics.

PGP is great. Everybody in tech has the skills to use it. But for non tech people it is still to difficult. But since the NSA affairs many crypto parties happened, specially in Germany. On this crypto parties tech people are teaching non tech people how to crypt emails with PGP. I think that is a good start and I hope we will see more crypto parties in future.

Won't happen unless there is a war-like situation with not only widespread surveilance, but also widespread use of surveilance. I would be willing to bet on it. Large groups of people simply have too short attention span, and the cost of not using encryption is too small (the cost of using encryption is too large).

I have taught PGP, find that at least some communities are increasingly interested in it, and hope more people will use it, though I think the forward secrecy issue alone shows the value of trying to replace it with a more modern design.

I think the logistical and conceptual parts of key exchange and verification are probably the most difficult for new PGP users. There are some ideas to make this more convenient; I know people who've produced some nice educational materials, and a colleague has a nice idea for making key exchange faster and easier among people on a LAN.

But I think the biggest obstacle in the long run may be just how fond many Internet users have become so fond of webmail and of being able to read their e-mail from any device. Having to use one particular desktop e-mail client on one particular machine to read encrypted e-mail is normal to me but may seem like a huge sacrifice if that's not what you're used to.

I think as long as PGP or any encryption is an add-on to internet apps like email and the web, it's doomed for general adaptation and for effectiveness.

It needs to be a fundamental part of the individual apps' (email, web, etc) specs, or more ideally part of the underlying internet (tcp?) that apps are built on.

Because its too easy to not use it. HTTPS has widespread adoption because end-users don't need to supply any cognitive resources to make the leap - until PGP occurs with the same simplicity it'll never see adoption amongst the commoners.

The ease of use has to approach at least Skype level (and even then you'll exclude a wide swath of users who don't know how Skype works).

There's an old joke about Unix to the effect of "it's not user unfriendly; it's actively user hostile". Likewise, many aspects of PGP, E.G. key generation and management, web of trust, public key validation and keeping the private key secure that is utterly befuddling for the vast majority of people. This, despite the fact that it's one of the most accessible avenues for secure communication we have right now.

If people have things that are easier to use securely, more people will be secure.

I think one problem that's mostly overlooked is the difficulty of getting people to use desktop email clients. Particularly in my younger generation, we've grown up with webmail, and switching to desktop clients is a major switch.

I've also always found them to be very difficult to configure. I use one SMTP server on campus, and need to use my ISP's SMTP server elsewhere? What if I'm on public wifi? And how do I authenticate on that server when my credentials are from someone else? How do I get Gmail to play nicely with my folders?

PGP, in contrast, was not hard to set up.

I wonder if some of the usability frustrations would be eased if people adopted the convention of having a secure-only email address, where the only email it accepts is encrypted email. It probably would be easy to set it to bounce/delete any non-encrypted email. Maybe only check it using a separate email client. Traffic would be low so searching wouldn't be such a hassle. Use your other email address for receiving insecure email (and tell everyone that by default, their email addresses are insecure).

Root cause: Usability. It's difficult to quickly set up. But there are (at least) two components to this:

1. Portability. How do I manage keys across my computers, phones & tablets?

2. Ease of use. What do I do to set this up? Most common clients don't support PGP out of the box. Even once plugins are added, they are complicated to use.

As a result, no one uses it. So, if you want to start, you need to convince your friends/colleagues to also use it.

I've recently started signing email from my home computer as a hint to others to do the same. So far no takers.

Users don't do security, all of this should happen automatically in the background.

When you hit send, a shared key should be negotiated with the recipient before your text leaves your box, without you really knowing it.

The key could silently be negotiated on top of the same protocol through automatically generated emails containing key setup information in headers (but empty "body" fields).

Specs for those key negotiation headers could easily go in an RFC, and systems that don't speak the language could then be shamed as noncompliant.

OpenPGP end-to-end encryption has to be done client-side, and the keys have to be stored client-side. This is hard to do given the current trend of using webmails. Besides, using OpenPGP means that you have to store a copy of your key on all the machines that you use to check email, and people usually do not know how to do this without entrusting a third party (Google, Dropbox, Apple, etc.) with the information.

It's a pain in the ass, thats why. It's hard to explain and it's hard to implement. And don't forget about mobile: If your locked down phone is compromised (and I wouldn't assume it's not), then even if you have PGP running you can forget about security.

Heck, even your desktop can be completely compromised. I think there's a big chance it is. If not by the NSA then by some malware.

It's fairly easy to get a good working PGP system on OSX - Symantec makes it obscure to get but it works well, at least for file encryption with options available in the Finder menu.


No need to pay - you just need to go through the rigmarole of getting a trial registration.

I'd highly advise against this and instead suggest going with GPGMail or similar. Considering the NSA's documented influence on security companies, an encryption product from a large corporation is quite possibly the worst choice you could make.

That's a good point. Though keys we use were generated back before Symantec bought PGP - is it more reasonable to expect that files encrypted with Symantec's version might be tamper-able, rather than keys generated might be?

The answer is Usability. It's a pain in the butt for someone like my Mom, Dad or most of my Friends to setup. Most digital security measures have a pretty high usability tax. I used to build out PKI systems and that was a nightmare to build correctly. It was costly to setup, develop and maintain, but it was secure.

I will put it SIMPLY. The AVERAGE user hasn't a clue about things this complex nor that it even exists. It needs to come packaged as a fully functioning part of the email clients and be as transparent to them as the send button is when your email client having that SMTP conversation with your mail server.

For the same reason why we don't exercise or always follow healthy eating habits:


I like Sneak's Law: Most users cannot or will not securely manage key material (http://www.youtube.com/watch?v=9k4GP3Evh9c @ 23:00).

Where I work they recently rolled out a policy that all laptops must be protected by PGP. We are not a small company and that update was pushed out with a few minor inconveniences but for me, I do not even notice its there.

a) 99.9% of the population does not give a shit. oh great, now you're reading my emails with boring, meaningless stuff in them. exciting!

b) google would LOVE it. no more context sensitive ads. let's shut down free gmail then.

c) a and b intersect - if you're using gmail or ANY other big webmail provider, you just. don't. care.

It takes ten minutes to learn the handful of steps involved with using it. For most people that's too much.

The biggest problem with pgp/gps is webmails and search in your messages :/

Most people don't understand it. Never have. Never will.

Not used because it's cumbersome for the average user.

1. You don't get it integrated with your applications like browser, email software, text editor or spreadsheet by default. This leads to network effect in reverse. if you are only person to use it within your circles, signing and encrypting data and messages you send to others can't be done.

2. Encryption is extra risk for your data. If you lose the keys, you lose the data. People are bad at backing up their data, why they would be better at managing their keys? Being sloppy with your keys means that somebody can impersonate you with more credibility (what if banks would accepting PGP singed orders in email)

3. Value from widely used PGP happens mostly in society level. Encrypting any particular piece of data has negative expected value in most cases.

4. Using PGP requires understanding the basic concepts and using it well is not that easy (lots of pest practices). People don't know any of this stuff. Even public and private key is far out concept for most people.

Most people, and even organizations, prioritize convenience and ease of use over security.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact