Explain xkcd: It's 'cause you're dumb.
Alice, Bob, and Eve are role names traditionally used in describing cryptographic protocols. Rather than talking about "Person A", "Person B", "Person C", names beginning with each letter are used instead, and giving them different genders let pronouns be used to shorten discussions. For example: "Person A sends Person B a message encoded with Person B's public key" is much easier to parse when written as "Alice sends Bob a message encoded with his public key." Eve is short for "eavesdropper" - a person trying to find out what's being said in the conversations between the other people. The classic situation involves Alice wanting to send a secret message to Bob, while Eve (the eavesdropper), attempts to read the message, ideally without Alice or Bob ever finding out. Additional participants such as Carol (Person C) can be added if necessary. The list of names has become very standardised over time as described at Alice and Bob.
The joke here is that any computer scientist, hearing the names used, will think that they are listening to a cryptography problem. By changing the names in a story to these role names, you can induce them to listen carefully to boring stories. The fewer the interesting details, the more it sounds like a general problem, so very boring stories are actually the easiest.
The title text shows a more radical approach to the problem, for people who do not feel comfortable about lying. In this approach, you only make friends with people who have the appropriate names already.
In comic 177: Alice and Bob these names are used in the same context. Instead of Alice and Bob being perfectly innocent people who just want to communicate in private, Bob is actually having an affair with Alice. Eve —his former partner— cracked the encryption to see what the message contained. Thus, this comic seems to continue the Alice/Bob romance, jealous-Eve plot, with Eve apparently confronting Alice over her text message to Bob.
add a comment! ⋅ refresh comments!
- [Cueball is telling a story to a Computer Scientist who is seated at his desk.]
- Cueball: Alice sends a message to Bob saying to meet her somewhere.
- Computer Scientist: Uh huh.
- Cueball: But Eve sees it, too, and goes to the place.
- Computer Scientist: With you so far.
- Cueball: Bob is delayed, and Alice and Eve meet.
- Computer Scientist: Yeah?
- I've discovered a way to get computer scientists to listen to any boring story.
This is funny. I was really drawn into the conversation due to the names. 184.108.40.206 07:05, 29 January 2014 (UTC)
- Me too! And I'm even more drawn to the meta-conversation!! :) Nealmcb (talk) 13:30, 29 January 2014 (UTC)
- But what about me? Alice and Bob get way too much time already.... Carol (whisper) 13:30 29 January 2014 (UTC)
Eve appears in 177: Alice and Bob --JakubNarebski (talk) 08:14, 29 January 2014 (UTC)
Heh. I was immediately reminded of the movie, Bob & Carol & Ted & Alice. http://www.imdb.com/title/tt0064100/ I wonder if that movie influenced the encryption names, or vice versa, or mere coincidence?220.127.116.11 12:31, 29 January 2014 (UTC)
I think the explanation looks complete to me. I vote to remove the tag. Jarod997 (talk) 14:04, 29 January 2014 (UTC)
Removed then. There was someone who asked for more Cryptography comic references. I found 14 and have thus made a new category (see link below). Feel free to add more if I have not found them all by searching on Cryptography and Encryption (I have only included those where there were some direct mention of these issues in the commic - or title text) and not just because there was mention of it in the explanation. However, the words does not have to appear in the commic before I included them. i.e. PGP. But also feel free to delete one from the list if I was too quick to include it Kynde (talk) 15:45, 29 January 2014 (UTC)
The description misses a key aspect of the comic. The conversation follows the pattern of a message being sent from Cueball to the Computer Scientist, with the CS sending an acknowledgement back and Cueball continuing --- much in the matter of an internet communication protocol, as referenced in the title. JamesCurran (talk) 17:06, 29 January 2014 (UTC)
Really excellent explanation. Complete, concise and well written, with some helpful notes in the comments. Keep up the good work! 18.104.22.168 18:43, 29 January 2014 (UTC)
I agree this would explain the protocol title, but how does it compute with the message at the bottom: I've discovered a way to get computer scientists to listen to any boring story? Kynde (talk) 18:55, 29 January 2014 (UTC)
- The point is that Cueball tells a completely mundane and booooring! story (might be last evening's soap opera, for example), but by replacing the protagonist names with Alice, Bob and Eve, names commonly used in explanation of public key cryptography, he tricked the Computer Scientist into believing he describes some cryptography protocol, thus making him interested. Edheldil (talk) 10:22, 31 January 2014 (UTC)
- By the way, what Cueball describes might very well be DNS cache poisoning -- or what NSA's supposed FOXACID servers do. Edheldil (talk) 10:31, 31 January 2014 (UTC)
I believe the essence of this story is in the encryption aspect, not the TCP. Many protocols feature a message-and-reply type of structure, it's not unique to TCP. The alternative to having CS reply to each phrase is to have him not reply to each phrase, which would be boring and not really indicate what's going on in CS's head. As some cryptography problems can be complex they are sometimes stated in "chunks" so people can follow along more easily (See the Description section of the link). In trying to follow what might be a complex problem sometimes people will acknowledge that they understand each part in turn - weather for their own benefit or that of the problem stater. Jarod997 (talk) 21:04, 29 January 2014 (UTC)
- Found it: Bruce Schneier, a notable modern Cryptographer has published a number of cryptography books in which he routinely references characters such as Alice, Bob, and Eve. Jarod997 (talk)
- Also: TCP/IP doesn't necessarily ack every packet, it can also ack multiple packets in one go. This allows for a much larger throughput as the latency per packet goes down to zero. Kaa-ching (talk) 09:33, 30 January 2014 (UTC)