I see two major barriers to mass adoption of any crypto system that requires a UI.
1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet.
So long as the "key" continues to appear to be an enormous password, people will continue to treat it that way, along with all the crazy worst-practices in the world. Not to mention the huge host of problems that accompanies key security for the layman.
I don't know what the answer is, but I do think that a physical token of some sort is the right start.
2. At the end of the day, the vast majority of people are not interested in the trade off between better security and convenience.
There is a learning curve, however shallow it can be made, and those that genuinely want or need better security are motivated enough to do the learning. For everyone else, it's like optional homework.
I would add to this that most everyone I know who cares about security is quite comfortable with a large array of APIs and software to do all sorts of cryptographic gymnastics. The bar is quite low already -- it has been for some time, IMO.
>We present the user with four items, a key, lock, seal and imprint. The key
and lock serve the purposes of encryption: Alice distributes her locks as
widely as possible so that others can send her messages that only she
can open with her key. Similarly, the seal and imprint handle signing:
Alice passes out copies of her imprint so others can verify her as the sender
of messages she has stamped with her seal. Collected together, we refer to
these four items as a toolkit this abstraction handles the contingency where
a user loses her key but not her seal: we insist that the toolkit represents
an indivisible unit that must be replaced whenever any element is lost.
That is actually a really nice metaphor they came up with. The seal and imprint are pretty useful for explaining signed email.
I already explain encrypted email to colleagues with the key and lock metaphor: I give you a box full of open padlocks to which only I hold the key, and you do the same for me. Anyone can have the padlocks as long as you keep the key secure. Seems to work.
> 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet.
I've been using GPG since a while now, to sign my outgoing mail. I don't encrypt it as I don't know anyone who uses GPG. I'm still happy to use it, to get used to it, and to see alternative uses. Signing is in my view a big improvement, to make sure nobody has messed with the messages. I always use HTML, so the receiver gets an attachment with the signing hash in it, and no strange text in the mail. I use a signature with a link to my public key and a link to the PGP page on Wikipedia. Everybody can read my mail, and if they want they can validate it.
So if the way the receiver gets hold of your public key is by a link in the signed email, what's to stop an attacker changing the link to a fake key and re-signing the email?
Hmm. Why don't we have a standard place on our domains for public keys? For example for myname@mydomain.com the public key could be https://key.mydomain.com/myname.
Some part of a key exchange needs to be out-of-band.
Alice communicating to Bob what the hash of her public key is over the phone, in person, or otherwise is good enough. Doing that allows Bob to verify whether or not a specific public key belongs to Alice.
The problem with hosting a key on a website is that it only really works if the domain has an extended validation certificate, i.e. someone proved their identity to their domain registrar. Then things just become a question of how much you trust the CA.
With PGP/Mime email clients that don't understand OpenPGP simply show a small attachment. Without PGP/Mime (the old way) you get funky delimiters in your mail body that look scary to non-technical users. I started with the old way (because it appears to be more compatible with legacy email clients) until a colleague worriedly asked me about the weirdness in my mails, so I switched to PGP/Mime. As far as I can tell only really old Outlook versions can't handle PGP/Mime, and you can use plain text mails as well as HTML.
The idea of including a link to your public key and a link the wiki on PGP is great! I'm going to do this as well. Would you mind showing me how you link to the above mentioned?
I agree that some terminology could make it easier. I think "key" is an ok choice for the private key, but for the public key I think there could be a better analogy. Calling them the same thing is a bit confusing and people don't understand that one of them you give away, while the other is confidential.
When I explain it to people I tell them that their public key is like an unlocked lockbox that you give people into which they can put a private message. They can close the box to lock it, but once they shut the box only you have the key to open it.
It's not a great analogy but it seems to me that the public key does not make sense as a "key" to the average person.
I think if it can be made to work, a better framing is in terms of establishing a secure channel and then communicating/sharing something over that channel.
Don't make the user think about the underlying mechanism at all.
The hardest part is probably getting the public key distributed, but that can just be "Check if Bill can receive over a secure channel."
I like this line of thinking. It seems that the word "key" is not the problem so much as the terms describing the respective key's status as opposed to their function. Perhaps something along the lines of "locking" and "unlocking" keys, or "encryption" key and "decryption" key (and, of course, "signing" key, no one has to know this is the same thing as your "decryption" key).
1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet.
So long as the "key" continues to appear to be an enormous password, people will continue to treat it that way, along with all the crazy worst-practices in the world. Not to mention the huge host of problems that accompanies key security for the layman.
I don't know what the answer is, but I do think that a physical token of some sort is the right start.
2. At the end of the day, the vast majority of people are not interested in the trade off between better security and convenience.
There is a learning curve, however shallow it can be made, and those that genuinely want or need better security are motivated enough to do the learning. For everyone else, it's like optional homework.
I would add to this that most everyone I know who cares about security is quite comfortable with a large array of APIs and software to do all sorts of cryptographic gymnastics. The bar is quite low already -- it has been for some time, IMO.