But let's really get down to plain English. What is the best analogy to use when explaining public key cryptography to an educated, non-technical audience? I've used the door-with-2-locks analogy previously. Is there a clearer analogy?
I like to tell people that the public key is like an (unlocked) padlock, and the private key is the combination that opens the padlock. It's a little clunky because the padlock in the analogy only works once, but it conveys the idea of being able to encrypt something securely that you can't then decrypt yourself.
I really like the paint analogy on Wikipedia for explaining this concept to laypeople who will never need to understand how DH actually works.
If you need to explain DH to someone who demands an understanding of what it actually does, DH is so easy that you might as well have them bang it out with small numbers in their scripting language of choice; you can talk someone though DH in about 4 minutes, and it even works as a sort of magic trick if there's a third person in the room who can hear your public values (again: use 2-3 digit numbers).
Of course, that's only 1/3 the problem. You now have a secret key that you can use to encrypt/decrypt messages with your neighbor - you need a good encryption algorithm (the next 1/3 of the problem, thankfully there are a lot of high quality ones to chose from.) But the missing 1/3 of the problem - Who are you communicating with? Is it the person you think it is, or some nefarious MITM.
Diffie-Hellman can give you confidentiality, but it won't authenticate your neighbor. To do that, you'll need either a shared secret (which, ironically, could have been used as your encryption key in the first place - It's the way statically configured IPSec without PFS works), or some form of PKI. But, if you have PKI, then you somehow managed to securely get a certificate on your system, and that mechanism also could have been used to get a secure encryption key.
I like the signify approach used by OpenBSD for authentication - they didn't even attempt to use a PKI or trust relationship (The entire thing was basically written in 10 days) - they just blasted their public key (including http://www.openbsd.org/57.html) for each release in every possible place they could think of, and users are expected to use some caution, also check email, and possibly smoke-signals into outer space, with that process to jump start security. Of course, once you have your first link-in-the-chain, you can use that to securely bootstrap the rest of the keys (which are included in each release).
You get a mechanism for Key-Exchange, but not Identify verification. At the end of the day, Diffie-Hellman needs a good PKI infrastructure to be useful.
10 comments
[ 0.28 ms ] story [ 31.1 ms ] threadIf you need to explain DH to someone who demands an understanding of what it actually does, DH is so easy that you might as well have them bang it out with small numbers in their scripting language of choice; you can talk someone though DH in about 4 minutes, and it even works as a sort of magic trick if there's a third person in the room who can hear your public values (again: use 2-3 digit numbers).
Diffie-Hellman can give you confidentiality, but it won't authenticate your neighbor. To do that, you'll need either a shared secret (which, ironically, could have been used as your encryption key in the first place - It's the way statically configured IPSec without PFS works), or some form of PKI. But, if you have PKI, then you somehow managed to securely get a certificate on your system, and that mechanism also could have been used to get a secure encryption key.
I like the signify approach used by OpenBSD for authentication - they didn't even attempt to use a PKI or trust relationship (The entire thing was basically written in 10 days) - they just blasted their public key (including http://www.openbsd.org/57.html) for each release in every possible place they could think of, and users are expected to use some caution, also check email, and possibly smoke-signals into outer space, with that process to jump start security. Of course, once you have your first link-in-the-chain, you can use that to securely bootstrap the rest of the keys (which are included in each release).
You get a mechanism for Key-Exchange, but not Identify verification. At the end of the day, Diffie-Hellman needs a good PKI infrastructure to be useful.