http://randomwalker.info/teaching/spring-2014-privacy-techno...
>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.
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.
Do you mean something like the Yubikey USB dongle: https://www.yubico.com/products/yubikey-hardware/
[not associated, just referencing a 'physical' item that can be treated as a 'key' by non-experts]
Hmm. Why don't we have a standard place on our domains for public keys? For example for [email protected] the public key could be https://key.mydomain.com/myname.
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.
<div style="font-size: 10px; color: #666;">This message is signed using <a href="https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>. Public key: <a href="https://pgp.mit.edu/pks/lookup?op=get&search=0xBE5D1E31ABCD1... ABCD1234</a> </div>
I see the link in the code is not closed properly, so you need to fix this.
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.
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."
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.