A flaw in the best explanation for public-key cryptography for non-techies that I’ve seen, and a proposed tweak

by Joey deVilla on June 8, 2017

A quick recap

Yesterday, I wrote about my favorite way to explain public-key crypto to non-techies. It’s a clever analogy that Panayotis Vryonis devised and put forth in his blog entry, Public-key cryptography for non-geeks.

The analogy features:

  • a box equipped with a special lock that has three positions, as shown in the picture above,
  • two keys that can turn the lock:
    • One that can only turn the lock clockwise, called the private key, and
    • One that can only turn the lock counterclockwise, called the public key:

Public-key crypto is used in both sending secret messages and digital signatures, and the combination of the special three-position lock and two keys allows the analogy to work for both uses.

Here’s sending a secret message…

…and here’s digitally signing a message:

To get the full story, you should read:

The limits of the analogy

Oh yeah, I went there.

“The map is not the territory,” the saying goes. In a similar vein, an analogy is not the thing it represents; push it far enough, and you’ll get to a place where it falls apart.

Suppose you want to send me a secret message. In the analogy, you’d put it into the box, lock it with my public key, which can only turn the lock in the counterclockwise direction, and then send it to me:

You unlock the box with the private key, which is the only key that can turn the lock clockwise. So far, so good.

The problem with the analogy is that there’s another “unlocked” setting at the 9:00 position. Couple that with the fact that the public key turns the lock counterclockwise, it’s all too easy for an unauthorized party to intercept the message:

Of course, this isn’t how actual public-key crypto works, as evidenced by the fact that ecommerce exists (it uses the SSL protocol, which uses public-key crypto) and that my delinquent friends haven’t replaced the stuff in my GitHub repo with these David Hasselhoff centerfolds (I use SSH, which uses public and private keys, to log into GitHub):

I repeat: Oh yeah, I went there.

I didn’t make this discovery — credit for that goes to my computer science prof at Crazy Go Nuts University, Robin Dawes:

It’s been 25 years, and I’m still getting schooled by the prof whose “algorithms and data structures” and “ethical/legal/social issues for computer scientists” courses I took. Talk about getting value for your tuition fees!

My proposed tweak

Public-key encryption’s two main uses — sending secret messages and digitally signing them — are explained quite well with Vryonis’ analogy. But how do we get around the problem pointed out above, or the problem illustrated below?

My proposed tweak involves splitting the lock into two locks:

  • One for encryption, and
  • the other for signatures

…and both use the same set of keys:

  • The private key, which only turns clockwise, and
  • The public key, which only turns counterclockwise

Here they are:

Using two locks gets around the problems introduced by a single three-position lock, and also lets you illustrate the simultaneous use of encrypted messages and digital signatures. For example, if I wanted to send you a secret message with the assurance that it was genuine, I’d send it to you in a box with two padlocks:

  • An orange “secret message” padlock locked with a copy of your public key, and
  • A blue “signature” padlock locked with my private key

If you had the correct keys and couldn’t open both padlocks, you should treat the contents of the box as suspect, and for good measure, you might want to hold the messenger for questioning.

So — Mr. Vryonis, Dr. Dawes, and you, the Gentle Reader — what do you think of my proposed tweak?

{ 4 comments… read them below or add one }

1 Matthew Ernest June 8, 2017 at 3:07 pm

I noticed this problem yesterday, but I didn’t want to be the guy nitpicking a presentation that did get the gist across.

The change I would proposeis to replace the two unlocked states/one locked state with one unlocked state/two locked states.

a) It is clearly shows that there is no way to apply the same key twice and end up in an unlocked state

b) It matches the system being modeled in that the output is different when encrypting with public vs. private key (two different locked states), but unlocking results in the same plaintext (only one unlocked state) if you start from the matching encrypted output and does nothing if you do not start form the matching encrypted output.

2 Joey deVilla June 8, 2017 at 4:05 pm

Matthew Ernest: Interesting idea. I’ll have to model it in a follow-up post. Thanks for the input!

3 Steve Syfuhs June 8, 2017 at 7:55 pm

I liked the original analogy because it was simple enough. The problem though is that this starts turning into a complex incidental explanation that takes you further and further from the actual function of PK crypto. Getting back to showing in-action stuff becomes more difficult. IMO keep it simple if you’re using an analogy, explain its not perfect, and then show them real PK stuff if they press it. :-)

4 Alex June 9, 2017 at 8:28 am

This all makes sense to me — my only issue would be that millennials might not easily understand the meanings of ‘clockwise’ and ‘counter-clockwise’, based on the rarity of clock faces in today’s world. Your images demonstrate a turn to the left and right, but they might be left wondering, “A clock face? How does something that says 8:28 have a face?”

Leave a Comment

{ 1 trackback }

Previous post:

Next post: