Posted: 3/8/2011 8:46:58 PM EDT
|
I had to sit through that awful 2nd National Treasure movie the other night, but it did afford an opportunity to recall the good old Playfair Cipher.
First some background... scrambling messages using pen and paper crypto has always been serious business. But also fun. The simplest cipher, the Caesar Cipher is simply a shift function –– you all saw it with the little kid and his decoder ring on A Christmas Story. You take the alphabet, and you shift it so that:
becomes
The key is simply the number of spaces you've shifted the alphabet, or a couplet that tells you two letters that line up –– for example: "AD" The problem with that cipher is that its easily broken because you can take the ciphertext and guess where there maybe some common engrams ("TH" will always encrypt to the same two letters of ciphertext for example) and then guess what some of the text is, and once you correctly map ONE letter, you've broken the entire cipher. There are other ciphers that try to fix that error. For example, the Vigenere Cipher uses a table of many Caesar shifted codes, and achieves the encoded text by using a key such that each letter of the key is aligned with a letter of the plain text, and those two are then processed together using the table. The result is that each letter in the plaintext is encrypted with a different Caesar cipher depending on its position in the text vis a viz the position of the key in relation to the text. This makes patterns more difficult to pull out (though still trivial for computers especially if the code key (which repeats if its shorter than the message) is simple or short). Aside from some of the brutal codes the Russians came up with (In Russia codekey encrypts YOU) ––- example the VIC Cipher, I think the Playfair cipher is my favorite. This is a grid code using a 5x5 grid. You take your key code and create the grid with it by writing it out, omitting duplicates, omitting recurrances, etc. Then you complete the rest of the table alphabetically but skipping letters you already used, and skipping "J" (I and J have to share a square). So a code key of "ARFCOM" would yield the following playfair box:
Now, to encrypt you take your plain text message and break it up into two letter pieces. There's an important rule though: Either formulate your plain text to omit "double" letters, or split doubles with a "nul" (usually X) and you also add a null either beginning or end to make your number of letters even. So if you use the word "puppy" in your plain text, you'd either write it as "pupy" or "pupxpy" ..... Thus, the following plain text and pieces before encoding:
Now, you use three rules when you encode each pair. Rule 1: If the two letters in a pair to be encrypted are in NEITHER the same row, NOR the same column of the table (i.e., they're on a diagonal), you envision a box/rectangle bracketed by the two letters and the cipher text of each letter is the letter in ITS same row which aligns with the column of the OTHER letter. (i.e, the other corners of the rectangle are the ciphertext) Rule 2: If the two letters in a pair to be encrypted are in the same ROW, then the cipher text of each letter is the letter immediately to its RIGHT. (and you wrap around to the same row if your letter falls on the end). Rule 3: If the two letters in a pair to be encrypted are in the same COLUMN, then the cipher text of each letter is the letter immediately BELOW it (and you wrap around to the same column if your letter falls on the bottom of the column). Decryption is the reverse. So lets try a couple: Our first pair is "LE" These land on the Playfair grid in a way that implicates Rule 3 –– they're sharing a column.
That means that each letter encodes to the character just below it in that column. "L" encrypts to "T" ....
... and "E" encrypts to "L"
.....thus, our first ciphertext pair is: "TL" OK, so lets move on then to our next "pair" from the unencrypted plaintext ––- "TI".... This time, Rule 1 is implicated –– the characters share neither a row nor a column. So we take our Playfair Grid and imagine a small rectangle whose corners are defined by the two characters:
And then the cipher text for each letter is the character in its same row that lines up with the column of the other. "T" becomes "Q"... and "I" becomes "L"
And so there you have it. There are things you can do (with agreement of sender and receiver) to mix things up in the Playfair. You can populate the table starting from the center square for example. Or fill it in using every other block. Or instead of combining "I" and "J" you could combine "U" and "V" ... But that's the fun of it. This code can be broken, of course ––- its no PGP –– but its not a bad code and short of having a good chunk of known plaintext, or a really long encrypted message so that you could do some really advanced crypto analysis, its going to be fairly good code. And now, here is a code to decrypt. The rules are as follows: My Playfair Grid is prepared in the normal way (no tricks), which is to say, it was prepared just as we did with "ARFCOM" above. I and J are combined into only one space on the grid. This time, instead of "ARFCOM" I used a different code key. The key is two words, four letters each, and is the name of a manufacturing facility well known to anyone with an AR15. I'll post a hint later if no one can figure that out. Prepare your Playfair Grid and decipher the following message. This message was encoded using "X" as a nul to split double characters and to fill out the end of a line when it was an odd number of characters. So when you decipher, you will easily see what "X" characters in the resulting plaintext you can pull out and discard. The first to post the answer gets, well, nothing. But you will perhaps have the admiration of your peers and a working understanding of an old pen and pencil code system that may be a good way to send messages when a solar flare totally the whole internet. Here's the message:
|
|
Quoted:
Quoted:
Damn, for a new guy you post some pretty cool stuff. Interesting little history lesson combined with a genuine thinking exercise. If you want another thinking exercise, see what sort ????????????????????????????. 
ETA: Shhh! I'm dating and happy and not sure I'd want my current S.O. to back-search all my old posts under the prior S/N if I were to forget to log out. ;-) |
|
Quoted:
I got the key, working on the decrypt now....."There once was..." edit: shoot, everybody beat me. 
I love this stuff. OP, keep it coming. OK, here you go... here's one. The following ciphertext was encrypted with a standard Playfair Cipher. (That is to say that I put it together using the regular manner of populating the grid from above):
This time, I'm not giving you the code key!! Or even hinting at it. I'm just giving you a "crib" which is a piece of the actual plain text that occurs somewhere within the message: NAVALBATTLEATARTEMISIUM
I.e., "naval battle at Artemisium" Using that crib (which I've selected for cryptographically significant reasons in that it leaks information about the key both in and of itself and by way of content hinting at topic matter of the plaintext), and knowing how the Playfair grid works, it should be possible to decrypt the plain text in a few hours work. You may find PARTS of the source text by google searching the crib, but in order to solve this cipher in a way that would be meaningful (i.e., allow you to decode future messages where you don't get a snippet of plaintext, you need to derive the key). So don't cheat! Flip to page 14 of this .pdf for some cryptoanalysis ideas. http://www.umich.edu/~umich/fm-34-40-2/ch7.pdf To make this easy, I will tell you that the crib digrams here correspond to the following plaintext pairs .. i.e., you don't need to worry about shifting it left or right (Note: the question mark is a character I'm not revealing other than to say its not a nul):
See any patterns there? (ETA: I just put it in green, so you better!) Oh, and one more thing to know about Playfairs: For two diagrams that are mirrors of each other in plaintext, eg: AB and BA, the ciphertext pairs are also mirrors of each other, i.e., XQ QX. (These are JUST examples, AB does not cipher to XQ in the problem presented above). Given that information, you should be able to match this crib up with an exact spot in the ciphertext and start working on your table. Good luck! |
|
Quoted:
Learn the Solitaire cipher. Takes a deck of cards and some patience, but is nearly unbreakable if the 'key deck' is unavailable. Solitaie is very secure, but hard as fuck to pull off and requires extra security to protect the deck and not accidentally shuffle it. Also unless you figure out some way to surreptitiously communicate new deck orderings, its dangerous in that you'll be encrypting subsequent messages with it. One benefit to Playfair is that you can agree before hand on a key selection protocol: I.e. senders and receivers can agree that: 1. The next message key is the answer to 1 down on the NYTimes crossword from the most recent Sunday. 2. If the answer to 1 across is an "odd" number of letters, then populate the Playfair grid in the regular way. 3. IF the answer to 1 across is an "even" number of letters, then populate the Playfair grid in a spiral pattern starting at the bottom right corner. 4. BUT if any answer in any the first three (down or across) hints is a proper noun, populate the Playfair grid in a checkerboard pattern starting at top left. Our you could just do a compound Playfair where each subsequent digram in the plaintext gets encrypted by a different Playfair grid, and that the passwords for each grid are chosen from a one time pad –– maybe a magazine or innocuous text. These rules get agreed on and then the sender and receiver never have to meet again, and always have a viable new code key. Further, they can do some pre-processing of the plain-text to cause it to defeat frequency analysis. |
|
Quoted:
Quoted:
Learn the Solitaire cipher. Takes a deck of cards and some patience, but is nearly unbreakable if the 'key deck' is unavailable. Solitaie is very secure, but hard as fuck to pull off and requires extra security to protect the deck and not accidentally shuffle it. Also unless you figure out some way to surreptitiously communicate new deck orderings, its dangerous in that you'll be encrypting subsequent messages with it. One benefit to Playfair is that you can agree before hand on a key selection protocol: I.e. senders and receivers can agree that: 1. The next message key is the answer to 1 down on the NYTimes crossword from the most recent Sunday. 2. If the answer to 1 across is an "odd" number of letters, then populate the Playfair grid in the regular way. 3. IF the answer to 1 across is an "even" number of letters, then populate the Playfair grid in a spiral pattern starting at the bottom right corner. 4. BUT if any answer in any the first three (down or across) hints is a proper noun, populate the Playfair grid in a checkerboard pattern starting at top left. Our you could just do a compound Playfair where each subsequent digram in the plaintext gets encrypted by a different Playfair grid, and that the passwords for each grid are chosen from a one time pad –– maybe a magazine or innocuous text. These rules get agreed on and then the sender and receiver never have to meet again, and always have a viable new code key. Further, they can do some pre-processing of the plain-text to cause it to defeat frequency analysis. You'd be amazed at how often key schemes like the ones you proposed are broken by really smart people who keep huge amounts of information in their heads. Bottom line, if you don't have a secure key exchange protocol, your crypto will eventually fall to some smart cryptanalyst. |
|
Quoted:
Quoted:
Learn the Solitaire cipher. Takes a deck of cards and some patience, but is nearly unbreakable if the 'key deck' is unavailable. Solitaie is very secure, but hard as fuck to pull off and requires extra security to protect the deck and not accidentally shuffle it. Also unless you figure out some way to surreptitiously communicate new deck orderings, its dangerous in that you'll be encrypting subsequent messages with it. One benefit to Playfair is that you can agree before hand on a key selection protocol: I.e. senders and receivers can agree that: 1. The next message key is the answer to 1 down on the NYTimes crossword from the most recent Sunday. 2. If the answer to 1 across is an "odd" number of letters, then populate the Playfair grid in the regular way. 3. IF the answer to 1 across is an "even" number of letters, then populate the Playfair grid in a spiral pattern starting at the bottom right corner. 4. BUT if any answer in any the first three (down or across) hints is a proper noun, populate the Playfair grid in a checkerboard pattern starting at top left. Our you could just do a compound Playfair where each subsequent digram in the plaintext gets encrypted by a different Playfair grid, and that the passwords for each grid are chosen from a one time pad –– maybe a magazine or innocuous text. These rules get agreed on and then the sender and receiver never have to meet again, and always have a viable new code key. Further, they can do some pre-processing of the plain-text to cause it to defeat frequency analysis. The biggest part of solitaire is obscurity. If you get caught with a piece of paper with tons of nonsense letters on it, you'll be looked at a bit harder than if you were carrying a couple decks of cards. One key deck and one for playing cards with. |
| I haven't started anything on the new one above yet, but a problem I see with the playfair system is the potential for repeat couplets. Any plaintext couplet of the same two letters will always have the same ciphertext couplet. Given a long enough message (and it wouldn't take much), commonly combined pairs of plaintext letters (ER, TH, etc.) will be easily identified, giving the codebreaker a foothold. I've never tried working through the Solitaire cipher yet, although it does look pretty interesting. |
|
Quoted:
I haven't started anything on the new one above yet, but a problem I see with the playfair system is the potential for repeat couplets. Any plaintext couplet of the same two letters will always have the same ciphertext couplet. Given a long enough message (and it wouldn't take much), commonly combined pairs of plaintext letters (ER, TH, etc.) will be easily identified, giving the codebreaker a foothold. I've never tried working through the Solitaire cipher yet, although it does look pretty interesting. Indeed, however... I see a few thoughts in response: First, remember that its not a given that every "TH" will be a couplet of "TH" –– and pre-encryption washing of the plaintext can deal with some of those troublesome repeating blocks: Consider: The plain text:
Has five of the common "TH" blocks. And if broken up alligned one way, they leave four intact instances of "TH"...
But watch this. Lets insert a nul ("X") in front of that sequence to shift it and see what happens.
That time there's only one "TH" because the others are all split between couplets. Second, there are additional ways to perform a more general purpose "wash" of the plaintext before encryption including: 1. Salting it with a repeating pad. For example, lets have our pad be three high and three low frequency letters, a combination I like to use a lot: VAKTZE Our plaintext with all the "TH" combination:
...becomes...
which we then drop into our pairs for encryption (now you see why we don't use our nul "x" in the pad however as we need it to break up pairs):
Now, run THAT through the Playfair Grid and lets see someone try to run a common pairs analysis! 2. Hit the plaintext with vigenere cipher or an autokey of some kind, which would scrub out the plain language common couplets. 3. Pick your couplets/digrams by laying out your plaintext in short rows of set frequency and then taking the pairs to be encoded from the vertical pairings. There are others of course. But you're right... its one of the weaknesses of the code in question. |
|
But if you're going to go through all the trouble of synchronizing those inserted nulls with the intended recipient, why not just go with a one time pad? Or is there some kind of algorithm for determining a varying set of nulls with which to salt a plaintext based on the date or something? (still haven't gotten a chance to actually play with the ciphertext, I had a late class tonight ) |
|
Quoted:
But if you're going to go through all the trouble of synchronizing those inserted nulls with the intended recipient, why not just go with a one time pad? Or is there some kind of algorithm for determining a varying set of nulls with which to salt a plaintext based on the date or something? I think OTP s are harder to implement. Besides, you don't have to "synch" the inserted nulls or pads with the recipient. He's got the key, and it will be obvious (in the case of the padding scheme) that he simply needs to discard the second letter in each digram in order to more easily read the result. (still haven't gotten a chance to actually play with the ciphertext, I had a late class tonight
)I'm currently working through the cipher just as you would be doing, even though I know the key I'm trying to go backwards from the known plaintext matching. Obviously the first step is to figure out that the known plaintext crip I gave contains a pair of "reversed" couplets, which means that the ciphertext will have a pair of reversed couplets in the same position. That gets you started as you can then line up the known plaintext at the right location and have a solution for those pairs. You also have solutions for those same pairs elsewhere where they appear, as well as "reverses" of those pairs. Once you've got as many as you can, you can start trying to work backward between pairings to see how the Playfair table would work. There are 156 couplets. Just matching the known plaintext crib I gave, and before even playing with the Playfair grid, you can decrypt 28 of the couplets. Then just context guessing you can probably get a number of additional pairings, including the nice "th" combination. When I am working on a code, I print out the cipher text pairs with lots of space below and above each row. I write plaintext I am sure of BELOW the cipher text pairs, and those I'm not 100% on jut above the pair in question. Use a pencil! |
|
Quoted:
You Sir are far and above my capability to hold still for this. I don't need Jackie Chan to tell you that my head is full of Fuck right now. OK, I think I'll take a nap Dont' give me too much credit. I just realized that the Plaintext crib I gave, once you start doing some rudimentary positional analysis, reveals almost the whole keycode. 
|
|
Quoted:
Got started on it about half an hour ago. I'd already figured out the repeats and reverse couplets, as well as identifying repeated sets of couplets (that remain encrypted). Still working.... You've probably already figured this out, but the "thread to pull on here" is that there is one set of couplets that you have already (its in the crib) where the plaintext and ciphertext pairings share a common letter. That means they're in the same row or column. |
|
Quoted:
THE BATTLE OF THERMOPYLAE WAS FOUGHT BETWEEN etc.... Not too bad for a history major. 
working between doing actual work here at work, no less...  Well done! Now you see why the modern crypto systems spend so much time worrying about "known plaintext" attacks. Its a big deal too: Any hard drive, for example, has a bunch of files with identical extensions ".doc" –– over and and over and over. High frequency. Every windows computer has a directory called "Windows" Every web page has HTML symbols inside. Modern cryptography is well and beyond this stuff, but it is a fun exercise. The thing with Playfair, in my view, is that you get decent security by doing: 1. Some kind of good wash of the plaintext. 2. SHORT SHORT SHORT messages. Less ciphertext means less frequency to work on. 3. Long password / phrase –– and possibly permute the Playfair grid in a nonstandard way. (I like spiral from the center). Finally, if you find this stuff enjoyable, download a copy of Crypt tool, which is educational and helpful as well. http://www.cryptool.org/index.php/en/download-topmenu-63.html Final cipher. No crib this time, but I will represent that there ARE a number of common two and three letter words in the plaintext. Words longer than three letters have been washed in an interesting way. They are not encrypted with an external key nor are they transposed or transformed in accordance with any patter, but they are scrambled with themselves such that they're anagrams of themselves. Thus, you cannot rely on pattern matching of larger words. I didn't do anything cute with the way the playfair grid is populated, its the same old start at the top left pattern as before. BUT the pass key is long, and it is not a coherent word or phrase, so its a well scrambled grid (unlike the last when where V W X Y Z on the bottom line was unaltered). This one's a neat example of one that's going to be tough to break by hand, but would probably be easy for a computer. A computer could brute force this cipher and keep tweaking its key with a goal of hitting the english language histogram of letter usage rates and that would do it. Any rate, here it is:
Good luck. |
|
Quoted:
The thing with Playfair, in my view, is that you get decent security by doing: 1. Some kind of good wash of the plaintext. 2. SHORT SHORT SHORT messages. Less ciphertext means less frequency to work on. 3. Long password / phrase –– and possibly permute the Playfair grid in a nonstandard way. (I like spiral from the center). Finally, if you find this stuff enjoyable, download a copy of Crypt tool, which is educational and helpful as well. http://www.cryptool.org/index.php/en/download-topmenu-63.html You can get some very decent crypto if you combine old school and public key crypto, especially when computers are automatically deciphering, instead of humans. "stack" playfair onto solitaire, then use a 2048 bit public key encryption with ASCII armor, and another "layer" of a polyalphabetic cypher. Without advanced tools, you can make others trying to read your stuff more difficult than the value of the time put into it. If you are paranoid, the biggest thing to remember is to encrypt everything. All emails, and use a hard drive encryption system that works at or below OS level. If you've been sending/receiving plaintext for years, then there are a couple high grade encrypted messages, followed by more plaintext, it's a "flag" of sorts. If everything is encrypted (TrueCrypt is nice), plausible deniablilty is almost guaranteed, especiallly when using a hidden encrypted partition inside a known encrypted partition. The courts may force you to give out the passphrase for the known encrypted partition, but only too much information from you would even show the existence of the ghost partition. |