Web Development

Cryptography's running gag: ROT13

If your cryptographer buddies are cracking cryptic jokes, you should check out Chad Perrin's explanation of the ROT13 cipher.

In pretty much every subculture, jokes that get repeated and gain an aura of mystique arise. A common one for the cryptology subculture focuses on the ROT13 cipher.


Probably the most prevalent running gag in cryptology circles revolves around the ROT13 cipher (pun intended).

If you think the XOR stream cipher is easy to implement, you haven't seen anything yet. The ROT13 cipher is much easier to implement, and there are probably an order of magnitude more ways to implement it than the XOR stream cipher. One of the simplest approaches to implementing it leverages the easy text processing capabilities of languages like Perl and Ruby. The following is a Ruby example that can be executed directly from the shell prompt:

> ruby -p -e '$_.tr! "A-Za-z", "N-ZA-Mn-za-m"' filename.txt

This will read in everything in the file whose name is provided as an argument, encrypt it, and print the ciphertext. Like the XOR stream cipher, ROT13 produces output that is the same length as its input. The way it does so, however, is somewhat different. In the case of the ROT13 cipher, you get the same result as what you get if you follow the instructions described here:

  1. Write all the letters of the alphabet in a circle on a piece of paper.
  2. Pick a letter you want to encrypt using ROT13.
  3. Place a token (perhaps a dime) on that letter.
  4. Move the token thirteen spaces clockwise (or counterclockwise -- it works the same either way, because 13 is half of 26, which is the number of letters in the alphabet).
  5. The letter on which the dime now rests is the ciphertext output of a ROT13 algorithm performed on the letter with which you started.

Decrypting ROT13 is just as easy; start with the encrypted letter, and do exactly the same thing. Thus, the above Ruby one-liner works for both encryption and decryption.

Of course, ROT13 is a laughably bad cipher. It is the sort of thing invented by toddlers to pass secret messages. One could conceivably change the "key", and thus change the number 13 to something else, and have some system for deciding which way to rotate the token for each character translation. One could also include more characters in a known order. Ultimately, however, these are all just variations on the same theme, which is not a strong algorithm.

In fact, it is so weak that it has been called "the Usenet equivalent of a magazine printing the answer to a quiz upside down." It has actually been used many times for that purpose to "protect" spoilers from accidental reading, since most people don't read ROT13 ciphertext as easily as plain ol' English.

Often, ROT13 is used to make light of very bad cryptography, as in cases where people try to improve the security of encryption by encrypting something with AES first and Blowfish next, thus "doubling up" on the encryption. Common jokes in that vein involve statements like "I'll double the strength of my leet rot13 cipher by doubling the rotation to rot26!" A moment's consideration should be sufficient to realize that ROT26 would result in "ciphertext" identical to the plaintext. Even more relevant to the problem of people doubling up on their encryption is using ROT13 twice which -- if you've been paying attention -- you know means you have just encrypted then immediately decrypted the text, and is functionally the same as ROT26.

The lesson to take from such things, of course, is that there is more to encryption than many people realize. For instance, doing something once does not mean that doing it twice is better. In addition to that, ROT13 provides an easily recognizable bit of lighthearted cultural reference that anyone with an interest in subjects of cryptology can recognize, including beginners.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

28 comments
Senrats
Senrats

I had to spit out my coffee when I read the ROT26 comment: ?I?ll double the strength of my leet rot13 cipher by doubling the rotation to rot26!? Good article and thanks for the laugh.

seanferd
seanferd

You'll never break my ultimate ROT-104 encryption! Actually, I was surprised a bit to see an article on ROT-13, but it is a really good example of what not to do, regardless of how obfuscated the method is, in a cryptographic system (likely a commercial product of some sort).

Deadly Ernest
Deadly Ernest

igpay atinlay, uchmay ecuresay, etbay ouyay.

jevans4949
jevans4949

Actually, it's just an interesting variant of what Simon Singh calls the Caesar Cipher. However, I wonder how much computer time the NSA would waste by assuming that it was something more complex. After all, a brute force attack on a cipher must resemble the infinite number of monkeys -> complete works of Shakespeare scenario. And if you're watching, guys, I have a bin laden with combustible material at my house.

Spitfire_Sysop
Spitfire_Sysop

Maybe I am now the butt of this joke but you didn't explain why layered ciphers are no stronger than the original cipher. I would assume that if you encrypted something multiple times with different algorithms that it would have to decrypted multiple times, with different algorithms. Is this just a false sense of security? What am I missing?

Ed Woychowsky
Ed Woychowsky

Talk about a blast from the past! Thank's Chad. Oh, here's ROT13 in XSLT 1.0: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format"> <xsl:template match="/|*|@*"> <xsl:copy> <xsl:apply-templates select="./attribute::node()"/> <xsl:call-template name="rot13"> <xsl:with-param name="text" select="./text()"/> </xsl:call-template> <xsl:apply-templates select="./child::node()"/> </xsl:copy> </xsl:template> <xsl:template match="text()"/> <xsl:template match="@*"> <xsl:attribute name="{name(.)}"> <xsl:call-template name="rot13"> <xsl:with-param name="text" select="."/> </xsl:call-template> </xsl:attribute> </xsl:template> <xsl:template name="rot13"> <xsl:param name="text"/> <xsl:value-of select="translate($text,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz', 'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm')"/> </xsl:template> </xsl:stylesheet>

apotheon
apotheon

Either "Uvynevbhf!" is not ROT104, or it doesn't translate as anything meaningful.

apotheon
apotheon

This might help: rotturo (edit: moved script to BitBucket) It's a slightly generalized rotN script that is configurable by way of some global variables to rotate by various numbers (currently set by 13) and to translate characters following a particular pattern (currently set to translate all characters). It also allows you to change what it uses as its "alphabet" if you like. If you change the $cryptchar value to 2, it'll do every second character (hint hint). I haven't bothered giving it command option configurable behavior, so you have to edit the script to change its behavior. I also haven't accounted for all possible (or even all likely) patterns of which characters to translate, but I'm feeling a little too lazy to do any more work on it at the moment. It's ugly, but it works.

CharlesG1970
CharlesG1970

The idea of using an encryption twice is that you have to undue both to get the plain text, this is not the case. The actual result is that you have to find an unknown key that will have the same effect. It would be like using ROT+10, and then Rot-6 and thinking that you now are secure, really the code breaker just uses the ROT-4 to get back to plain text. If you use 128, then 256, you still only need to break the 256 (Just the key is not the same as the original 256 key) Also the idea of will take more time that the life of the universe is with Today?s computers, in 18 month , it will be less than the live of the universe, and 18 more we are down to a quarter. Still good but don't be fooled. Also, code breakers are smart; they are not a room full of monkey, even when doing brute force.

djdawson
djdawson

It must be more secure, since that's exactly what 3DES is - DES performed 3 times. I'd also like some clarification from the author...

apotheon
apotheon

re: your XSLT implementation This is one of the reasons I don't use XSLT for . . . well, anything, really.

seanferd
seanferd

No, that was, in fact, ROT-13. I should have somehow distinguished my ROT-104 comment as as separate entity. Sorry, I have a novelty browser extension which does all sorts of silly encoding tricks, so I didn't even have to bother iterating that myself. "Hilarious."

mcrogerm
mcrogerm

but something I've been curious about -- why is the 3DES cipher supposed to be more secure than the DES cipher? I understad it just applies the DES algorithm 3 times to successiv ciphertexts. Am I mistaken?

mcrogerm
mcrogerm

It's been many years and I haven't been working in the field, so I don't remember all that well, but I was thinking of a couple of articles I read back when I was still studying computer science for my own pleasure. The articles I was thinking of tried to develop a good estimate of the fastest computers that would be possible according to the constraints of the laws of physics (I don't think quantum computers were considered -- they hadn't been shown to be theoretically possible then). They then went on to use Big O analysis to demonstrate that the required complexity of the solution algorithm would be beyond the possibility of solution in the expected life of the universe. Anyway, if you really want to hear about this stuff look up some of the material published by Bruce Schneier -- he's written a lot on computer security and cryptography. Seems to me the strongest encryption was called the RAS algorithm, but I no longer remember the names that RAS stands for.

Spitfire_Sysop
Spitfire_Sysop

This is an interesting concept but I read a story about a crazy inventor that was arrested in a UK airport for having a model rocket in his luggage. They then wanted to look through his computer equipment for evidence of bomb making instructions. He had some encrypted files and refused to give up the key because he said they contained plans for an invention that he had not yet patented. The point of this story is that the authorities used a FED cracker to open the encrypted container. It took them a really long time and when they got it opened, they found another encrypted container file. They had not been able to open the second container by the time the article I read was written.

Aaron Mason
Aaron Mason

I think the case for the experts who consider multiple layers of encryption a false sense of security, is that all you're doing is slowing potential attackers down.

apotheon
apotheon

Well . . . I've been thinking of writing an automated ROT-N and XOR cracker. I might build on rotturo to do it -- if I get around to it. A naive version of it should be fairly easy -- just some limited depth recursion to combine different options in an orderly way to try a bunch of different ways to decrypt some text. Before I do anything like that, though, I should probably see if there's a tool like that out there already (or maybe a pair of tools that can be stitched together with trivial ease).

MikeG3b
MikeG3b

Most of my reading on triple-DES is limited to the white paper that Phil Zimmerman provided with the original version of PGP. I think he did some tricks with the key to strengthen the PGP implementation of triple-DES because of the issue of using the same key in all 3 iterations. I'd incorrectly assumed that the same tricks were a standard for any triple-DES implementation. Thanks! Clarifications are always good!

apotheon
apotheon

IIRC the second round of a Triple-DES encryption uses the initial key backwards, or something like that. Actually, that depends on the specific implementation of 3DES. By the way, for some excellent cryptographic historical fiction, you should give Neal Stephenson's Cryptonomicon a read.

MikeG3b
MikeG3b

IIRC the second round of a Triple-DES encryption uses the initial key backwards, or something like that. So, even with a single key provided for all 3 rounds, the key is permuted to yield a pretty strong (but not REAL strong) encryption. Bruce Schneier's book ("Applied Cryptography") is one of the best lay-person's introductions to cryptography. Bruce is a gifted writer -- I subscribe to his "Crypto-Gram" newsletter, and even though I can't follow the math in a lot of his technical discussions, it's an interesting read. Another great book is Steven Levy's "Crypto: How the Code Rebels Beat the Government Saving Privacy in the Digital Age" -- although not heavy on details, it's a fun book to read. Finally, "The Codebreakers" by David Kahn is another great read. It's more on the history of cryptography, but explains why things like ROT13, XOR, the Enigma machine, etc. are all doomed to failure at some point.

apotheon
apotheon

Actually, whether multiple rounds of encryption will increase the difficulty of cracking something depends on the specific algorithm -- and it takes extensive testing to determine that a given algorithm can be used multiple times to improve resistance to cracking. The fact is that DES is relatively rare in that it has actually been extensively tested to determine that multiple rounds of encryption do provide increased security, as long as each round uses a different key than the others. As such, an algorithm has been developed that uses three 56 bit keys chained together to form a single 168 bit key to multiply encrypt something. In fact . . . if you use the same key twice in a row with DES, you cancel the benefits of DES, the same as if you use ROT13 twice. This is the sort of thing that makes multiply encrypting something without knowing exactly what you're doing -- without really understanding the technology you're using -- such a bad idea. On the other hand . . . modern ciphers tend to be designed such that they can take keys of varying lengths. Thus, if you're using 128 bit AES, but you decide you want the improved security of 256 bit AES, you can easily do so just by increasing the key size you use. Encrypting twice with 128 bit AES, using different keys, would at best provide the same cryptographic strength as 256 bit AES, but at a substantially greater cost in performance. Why bother?

apotheon
apotheon

I'd like to see the article. My suspicion is that they actually cracked his password -- though it's possible he just chose poorly when selecting his encryption methodology.

Spitfire_Sysop
Spitfire_Sysop

That makes sense to me. I don't like it when scientists claim to know the bounds of the universe however that is an entirely different discussion. If we had three points of view from a "sufficient distance" apart we could get better measurements but we are always limited by a horizon created by the limitations of our measurement instruments. The "sufficient distance" would be the current horizon we are looking at, then you could actually see if there is anything past that or if there is an end. Limitless could simply be the practicality of light travel.

Spitfire_Sysop
Spitfire_Sysop

That is a good question. I imagine that it fits an equation like a key fits a lock.

FreddieM
FreddieM

I've always wondered how a cracking algorythm could know that it found the (arbitary and perhaps not obvious) plaintext, if the number of repetative encryptions was unknown.

mcrogerm
mcrogerm

Although there are a few cryptographic algorithms out there that are nearly unbreakable, in general the stronger they are the more they cost in terms of time. I always thought the whole point of enciphering something was to make it uneconomic for the opposition. Most information is time-sensitive to some degree or other, so a cost-effective cipher is one that takes longer to break than the information is valuable. I think the public key algorithm is theoretically unbreakable within the lifetime of the universe, but without that constraint could be broken (i.e. if you had infinite time you could eventually break it, but it would be expected to take you longer than the time the universe is thought to exist in the future).

Editor's Picks