Title: Transposition Ciphers ( Basic ). Author: hexxeh - hexxeh@hotmail.com Target-Level: Beginners Date: July 29th 2002 Revised: August 1st 2002 .:[Body]:. Transposition ciphers can get quite simple in the basic frame of mind. They do not change the plaintext into ciphertext, all they do is shuffle the characters basically. So in a nutshell, they are not encrypters or decrypters, the are sometimes called "rotors". This kind of cipher originates from Rotor Machines. I will now present some of the most classic transposition ciphers known. The cryptanalysis remains simple, since the plaintext characters are the same as the ciphertext characters, frequency analysis can really help the cryptanalyst. .:[Points]:. xD matrix = 'x' dimensional coded graph, EG: 2D matrix. .:[Simple transposition Ciphers]:. What happens in a "simple transposition cipher" is that the rotor will take the user's input, set it out on a 2 dimensional matrix(a programmed graph), and the output would be the letters in columns. Here is the process a transposition cipher takes when encrypting. Plaintext -> rotor engine -> set out plaintext on 2d matrix ->\ \ | | \ / ----------------------------------------------------------------+ | +--> Mapping the horizontal characters in columns -> Ciphertext If you run the ciphertext against the rotor engine of the simple substitution cipher, then you should in *theory* get the original plaintext. This all depends on the cryptographic algorithm used in the rotor. I will now present a real time *hand* example(We've filtered out the whitespaces) of a roter+1. .:[Concepts: simple substitution ciphers]:. Inputted Plaintext: I LIKE ERROKEYZ Key 2d Matrix against *plaintext*: 1 2 3 4 <---- Columnar Count 1 I L I K 2 E R R O 3 K E Y Z | +---> Row count 4x3 { Four columns by three rows } Outputted ciphertext( recruit the characters in their colums, seperate with whitespace ): IEK LRE IRY KOZ Verification Inputted Ciphertext: IEK LRE IRY KOZ 2d matrix against *ciphertext*: 1 2 3 <---- Columnar Count 1 I E K 2 L R E 3 I R Y 4 K O Z | +---> Row count 3x4 { Three columns by four rows } Outputted ciphertext: ILIK ERRO KEYZ ++ Confirmed! :-) Cryptography Analysis: Now what have you just read is something beyond simplicity. It's very simple and easy to break, any cryptanalysts can break it without using a computer. Keep on reading, you'll learn about *computered* transposition ciphers. .:[transposition ciphers with keys]:. Now, for these kind of transposition ciphers, you would usually need more thought to do it. You would usually need to define a key to determine the pattern of the outputted ciphertext. I will explain this as we go along. Consider the following: .:[Concepts: transposition ciphers with keys]:. Inputted plaintext: I LIKE ERROKEYZ Inputted key: NITE 2D matrix against *plaintext*: 1 2 3 4 <-- Columnar Count of PLAINTEXT N I T E <-- Key 3 2 4 1 <-- Occurences in order. Read next statement. 1 I L I K 2 E E R R 3 O K E Y 4 Z | +---> Row count of PLAINTEXT Okay, the occurences, "E" is the first character found in the english alphabet inside the key("NITE"), so we say its the first occurence. Then "I" Is the first character found in the alphabet inside the key after the "e", so we label that as 2. Then "N" is the first character found in the alphabet inside the key after "I", so we label its occurence with 3. And so on. 4x3 { Four columns by three rows } The outputted ciphertext will run under the order of the smallest labelled occurence, and gradually increase. Outputted ciphertext(recruiting characters in vertically(columns), seperated with whitespaces): KRY LEK IEOZ IRE Verification - If the key used against the rotor ciphertext is the same as the key used the plaintext, then you would get the original plaintext. If you didnt understand that line, then just go on and read the next part, you'll get it right. :-) Inputted ciphertext: KRY LEK IEOZ IRE Inputted key(should be the same if you want to decrypt): NITE First you must input the key, and the occurance hits on it: 1 2 3 4 <-- Columnar Count of PLAINTEXT N I T E <-- Key 3 2 4 1 <-- Occurences in order. Read next statement. Now You must place the first block from the ciphertext in this case (KRY) under the number 1. The second block from the ciphertext (LEK) should go under the number 2. The third block from the ciphertext(IEOZ) should go under the number 3, and so on respectivly. So at the very end, it should look like this: 1 2 3 4 <-- Columnar Count of PLAINTEXT N I T E <-- Key 3 2 4 1 <-- Occurence hits. Read next statement. 1 I L I K 2 E E R R 3 O K E Y 4 Z | +---> Row count of PLAINTEXT Outputted Plantext( Recruit horizontal from under the first, second, third, and fourth occurence): ILIK ERRO KEYZ ++Confirmed :-) .:[Bad Bits(Programmers)]:. Okay, if you've read this, you might of been asking yourself a variety of questions, especially if you are a programmer. Now here sre some useful pointers that you must consider writing one in whatever language. *) IF there are more than one of the same character in a key, the first occurence of that character should have a smaller occurence than the other. For example, lets say we got a key of "dood", then the occurence list would look like this: d o o d <-- Key 1 3 4 2 <-- Occurence Hits *) Occurences should also be in order of decimals(ascii) from smallest at start. For example if we had a key of "z00", as in a 'z' and 'zero' and 'zero', then the occurences should look like this: z 0 0 <-- Key 3 1 2 <-- Occurence Hits If you run this on your most used c compiler, printf("%d is smaller than %d\n", '0', 'z'); Then you'd get an output of: 48 is smaller than 122, Hence meaning the decimal ascii of of 0 is smaller than the decimal ascii of 'z'. *) You might be asking, why dont we have 5 columns instead of 4? Well, okay this can be debatable, but here's my solution to your question. The number of columns should differ on how many characters you have in a key. For example, if we had the word "dood" as a key, then there would be four columns on the 2d matrix. *) The message to encipher should be at least twice the length of the key, AT LEAST. It dont make sense if the number of characters you have in your key is bigger than the number of characters you have in the message. Hence the following rational expression should evaluate as true: // This is C if (strlen(message) < strlen(key)) // If message larger than key exit( fprintf(stderr, " Yo, heh, No!\n")); // Quit the program So if you do try to encipher a message that has a smaller number of characters than the key the whole process would get screwed up. Consider the following Inputted key: rawt.daemon.sh.helo Inputted plaintext: Shoes 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 <-- Columnar count r a w t . d a e m o n . s h . h e l o <-- Key 14 1 17 16 18 3 2 4 9 11 10 19 15 6 20 7 5 8 13 <-- Occurence hit, That should be right! 1 S o h e s | +---> Row count of PLAINTEXT Now if you recruit horizontally, bleh! Then the cipher text would be something like " s ohe s ". So its real stupid That's all I can think of at the moment, be sure to let me know of your comments. .:[End - hexxeh]:.