You might have heard Alice and Bob's names floating around security discussions, maybe even in regards to threat modeling slides for privacy technology.
The pair appear in graphics about how the Tor network operates. They also appear in basic illustrations of how public key encryption works.
Alice and Bob even have their own Wikipedia page providing some information and background on the pair.
Consider this blog entry nothing more than a quick and digestible introduction to Alice and Bob.
(photo credit)
They are no one in particular. They only exist in the minds of cryptographers and security hackers. They are fictional people used as placeholders to represent two people attempting to establish communications in which security and privacy are the primary concern. Note that their respective names start with "A" and "B."
"Jack and Jill" won’t work. "Jane Doe and John Doe" is, well, sort of confusing.
The idea is each participant in a security model or illustration is assigned a name that becomes common lexicon.
If you overhear someone discussing Alice and Bob, it’s probably privacy or security-related chatter.
There’s another benefit to using Alice and Bob as placeholders. Sanitizing identities is always a smart and cautious move when discussing threat models and security scenarios about actually existing individuals. It might sound like an amateur and even delusional adaptation of spy tradecraft, but it’s a good habit regardless.
If Alice and Bob are two communicating parties, Carol/Carlos/Charlie could be the third participant. And the alphabetic name assignments continue from there.
The central question about the David's, Eve's, Frank's, all the way through Walter and Wendy is straightforward: they all have some relation to Alice and Bob. Sometimes they are trusted participants but sometimes they are not.
For example, there’s another concept in privacy technology to be aware of, the notion of an adversary, which is normally a third party seeking to disrupt, compromise or just surveil communications. Our very own Alice and Bob are frequent targets for an array of those adversaries.
In privacy technology, classifying the type of adversary matters, particularly when working through threat models.
Some adversaries are active. They engage in activities to intrude on specific targets, in this case Alice and Bob. They might be the thief who accesses a physical password book in a desk drawer while the target is on vacation. In other cases, the active adversary could be someone who compromises a specific device or resource on a local network.
In the alphabetic assignments, Mallory is an active adversary. It's notable that the phrase "Man in the Middle," in which some adversary intercedes in the middle of communications, is often mentioned by its acronym "MITM." That first "M" nicely fits with Mallory.
There are also passive adversaries in the context of threat modeling. A passive adversary is a party observing the signals on the wire, but plays no direct role in disrupting those signals. Think about examples like the parent reviewing their troublesome teenager’s cell phone calls on this month’s bill. Probably more common, a passive adversary could be a wiretapping party, such as a 3LGA, a three-letter government agency, watching TCP packets on the wire.
In that case, Alice and Bob's communications are eavesdropped on by Eve. Get it? Eve and eavesdropping. Sometimes it's Michael as in microphone.
Knowing the Alice and Bob narrative isn’t a requirement for any security certifications as far as I know, but it could make reading slides at a technical conference presentation more enlightening. Better yet, understanding all the roles in the Alice and Bob matrix of alphabetic friends and enemies provides a basic framework for approaching privacy and security problems.
For more details beyond the Wikipedia page, the actual Alice and Bob saga starts with a 1978 white paper (or here) by some individuals known collectively as "RSA": three of the digital age's cryptography pioneers from the 1970’s: Ron Rivest, Adi Shamir and Leonard Adelman.
George is a co-founder and CTO of ClearOPS. By trade, George is a systems administrator out of BSD Unix land, with long-time involvement in privacy-enhancing technologies. By nature, he thrives on creating unorthodox solutions to ordinary problems.
ClearOPS offers knowledge management for privacy and security ops data that is turned into information that can be used to respond to security questionnaires and conduct vendor monitoring. Do you know who your vendors are?