Scenario
- Alice is the wife of jealous Bob. She wants to communicate with her secret lover Carl. She creates two keys, one intended to be kept secret, the other intended to be sacrificed. She passes the secret key (or both) to Carl.
- Alice constructs a harmless message M1 about boring math stuff for Carl (intended to be revealed to Bob in case of discovery) and a burning love letter M2 to Carl. She constructs a cipher-text C out of both messages M1, M2 and emails it to Carl.
- Carl uses his key to decrypt M2 and possibly M1 (in order to know the fake message, too).
- Bob finds out about the email to Carl, becomes suspicious and forces Alice to decrypt the message.
- Alice uses the sacrificable key and reveals the message M1 about boring math stuff to Bob. Since Bob does not know the other key, he has to assume that there is no other message M2.
This is a possible scenario for the use of deniable encryption, found on Wikipedia.
I laughed out loud when I read this. I’ll now state the probably obvious fact that examples like this are awesome. They’re awesome for the reader because they’re goofy and therefore engaging, and they’re awesome for the writer because they’re fun to make. (They might not, of course, be so awesome for the characters involved — like Bob.)
What’s more, I posit that this fun-is-good principle can be applied to anything.
Take code, for example: certainly, you can write some off-the-wall program that is completely unintelligible. I think, however, that you can also mix goofiness and good form in such a way that you increase readability.
I try to do this with programming assignments for my classes. I do it partly out of consideration for myself — it makes it more fun — and partly to brighten the day and ease the job of some poor teaching assistant who’s already looked over fifty other versions of the same program.
As another example, I attended a lecture just last week on Turing machines. What made it memorable was that after mentioning some new variation on the standard model, the professor would sometimes pause to point out that “of course, if you have four arms, you’re no less powerful than a person with one — right?”
There’s one problem, unfortunately, and that is that it can be hard to get right. The deniable encryption scenario is effective because it is plausible. I remember some outrageous scenario given by one of my professors* last year. It involved voting machines being connected to a giant panel of lights in some room where people watched the flashes to count the votes coming in, and it would have been a good use for multiplexors or demultiplexors or something — and that’s the point: I remember the scenario quite well, but I have no idea what it was for.
Plausibility, luckily, is a fairly easy test. Metaphor is similar: to be effective, it requires a tight mapping between its world and that of whatever it’s meant to explain. If this isn’t in place, a metaphor could both fail to accomplish its purpose as an effective teaching tool or mnemonic and lead you astray in your understanding, but major inconsistencies in a metaphor are easy to spot.
The code example is a bit harder. Minor flaws in a scenario or metaphor might easily go unnoticed, but bad or ugly code is more obviously bad or ugly. Worse still, you might have the wittiest comments or symbol names imaginable, but they won’t redeem your code if it’s stylistically atrocious. It’s akin to showing up to a party without having showered in a week: you might be the funniest person in the world, but you’ll reek badly enough that no one will want to be around to listen to your jokes**.
Discouraged now that I’ve argued that fun is good and that getting good fun right can be difficult? That’s about the worst thing you can be. I’m not a fan of making grand “anyone can do x” statements, but it’s appropriate here: anyone can get good fun right. I used to be terrible at explaining things to other people. I persisted, though, and I’ve gotten better at making things easy and memorable. The key is not being afraid to get it wrong. Sure, you will get it wrong, but if you’re afraid of that, you won’t be able to get it right.
Have fun with what you do, and do so without fear of doing it wrong. You’ll very quickly find yourself doing your own awesome things.
* This particular professor, however, was awesome, and this one goofy and ineffective example was such a rarity that I feel bad using it as my example of a goofy and ineffective example.
** Fortunately, I’ve noticed a positive correlation between people who shower often and programmers who write good code, so if you’re a programmer who’s not very susceptible to one of these problems I’d expect you to be similarly unaffected by the other.
