| Welcome to Crypto. We hope you enjoy your visit. You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free. Join our community! If you're already a member please log in to your account to access all of our features: |
| The Calculator Cipher; A new cipher for you to destroy! | |
|---|---|
| Topic Started: Nov 1 2005, 05:01 AM (274 Views) | |
| Donald | Nov 1 2005, 05:01 AM Post #1 |
|
Elite member
  ![]](http://209.85.122.85/static/1/pip_r.png)
|
Ok, the other day I was messing around with my wrist watch calculator. (Yes, I AM a nerd!)
 When suddenly it occurred to me that I ought to be able to make a primitive cipher using just a simple calculator. By simple, I mean SIMPLE. As simple as the one on my wrist watch. That means you have an 8 character display and the operators +-*/.Furthermore, I wanted this cipher to be usable WITHOUT writing down a bunch of intermediate steps and no elaborate tables specifying the inputs. All of the encryption should happen in the calculator (or in your head). Just a simple calculator and you write down the encrypted results only. (Writing down the key and plain text might help as well, but neither is STRICTLY required if you have a good memory) An explanation of using "The Calculator Cipher": First, you must have a key that is a multiple of 7 digits. Arrange your key so that each block of 7 digits is separated into 1 digit and 6. Like this: 1 983844, 5 265181, 5 818271 So, when I refer to block 1 of the key, it is 1 983844. Block 2 of the key is 5 265181. Etc. The key should really be a minimum of 3 blocks long, 4 or more is better. We encrypt the plain text in blocks of 3 characters at a time. Each block of 3 plain text characters is encrypted with one 7 digit block from the key, we rotate through the key as we rotate through the plain text blocks. So the first 3 characters of the plain text will be encrypted with block 1 of the key. The second 3 characters of plain text with block 2 of the key. The third 3 chars of plain with block 3 of the key. And (assuming the key is only 3 blocks long) the fourth 3 chars of the plain text will be encrypted with block 1 of the key again. We must convert the plain text characters into numerical values. We do that by building a mini "matrix" on the calculators number pad. Each number represents 3 characters. The first digit of our key block is the "Start Position" for our alphabet on the number pad. So for our first key block the start position is "1" and we have:
Our plain text message to encrypt for this example is: "Send help at once". We encrypt the plain text in blocks of three characters using the alphabet matrix created by our "starting position" digit from the key block. (A starting position of 0=1) Each plain text character translates into two digits. The first digit is the number under the letter. The second digit specifies which letter in the group of three. For the first position the second digit will be 1, 4, or 7. For a second position letter the second digit will be 2, 5, or 8. And for a third position character the second digit will be 3, 6, or 9. Furthermore, a ZERO may replace a 1 at any point at the encryptors option. So "A" could be encrypted not only as 11, 14 or 17, but also as 10, 01, 00, 04 or 07. The first three characters of our plain text are SEN and we encrypt them as: 41 22 85 (44 28 85 would have also been valid, as well as many other combinations) Now we enter that number into our calculator, and add the next 6 digits of the first key block. 412285+983844=1396129 The result is truncated to 6 digits and our cipher text is 39 61 29. The next 3 plain text characters are DHE and they will be encrypted with the second key block 5 265181. The "5" gives us a new start position, so now our alphabet matrix looks like:
we encrypt DHE to 67 12 68, put it into our calculator and add the next 6 digits of the key block: 671268+265181=936449. Our cipher text is 93 64 49. The next three plain text characters are LPA and our key block is 5 818271. (Note that by chance it has the same starting position as key block 2) LPA=23 74 51. 237451+818271=1055722, cipher text is 05 57 22. The next three plain text characters are TON and our key block is 1 983844 again. TON=45 86 82. 458682+983844=1442526, cipher text is 44 25 26 The last plain text characters are CEQ and our key block is 5 265181. (note we padded with a q) CEQ=53 62 75. 536275+265181=801456, cipher text is 80 14 56. So we send this encrypted message to our friend: 39 61 29 93 64 49 05 57 22 44 25 26 80 14 56 To decrypt it, he simply divides it into 6 digit numbers and reverses the process. 396129-983844=-587715 With any result smaller than zero we add 1 million. -587715+1000000=412285 Use the starting position and number pad to convert 41 22 85 into S E N We continue with: 936449-265181=671268 = D H E 055722-818271=-762549+1000000=237451 = L P A 442526-983844=-541318+1000000=458682 = T O N 801456-265181=536275 = C E Q And Viola! there is our message, "Send Help At Once" |
 |
 
|
| Donald | Nov 1 2005, 05:06 AM Post #2 |
|
Elite member
|
Some more details on the calculator cipher and it's development. The reason I didn't just convert A..Z into 01 to 26 (or 00 to 25) is two fold. First, there is NO WAY that I'm going to be able to remember what number of the alphabet P is without a chart or some VERY tedious and error prone counting. I wanted to make it at least POSSIBLE (if not practical) to use this cipher without writing out a chart. Martin Gardner's "Telephone Code" inspired this variation. I may not be able to remember what position p is in, but it's (relatively) easy to run down the alphabet by threes while looking at the number pad and see that P belongs to 6. And for a further advantage, our cipher now uses digits 0-9 in all positions making it a LITTLE bit harder for the unauthorized decryptor to recognize the correct decrypt. Also, the homonyms add some distinct advantages to the system. Now I ALSO came up with a variation that encrypted 2 characters into 3 digits. Say you have any two characters. Each will be in position 1, 2 or 3. There are only 9 possible combinations of these positions for two characters. 11,12,13,21,22,23,31,32,33. Instead of recording our characters as two digits each, we could write down the first digit of the first character, the first digit of the second character, and then make the third digit represent the positions of both. You can do this with as simple a rule as saying we represent the first characters position with the numbers 1, 4 and 7. And the second characters position with 0, 1 and 2. Then add them together to create our "superimposition" character. 1+0=1 1+1=2 1+2=3 4+0=4 4+1=5 4+2=6 7+0=7 7+1=8 7+2=9 It's cool, and lets you represent 4 characters in 6 digits. BUT, it's a nightmare to work with by hand. Especially when your goal was to not write down any intermediate steps. And decryption? ARGH!!!! Had to be trashed. I also tried to work in more complicated formulas for the encryption, but any combination of multiplication and addition compressed down algebraically to p*a+b where p=your plain text digits and a and c are constants. Furthermore, you can't "undo" multiplication when you are using modulus arithmetic. And without emulating modulus arithmetic, you give away clues about your key and plain text. This is because values in the middle of the output range could have come from MANY combinations of plain text and key. BUT, since there is no wrapping without using modulus, crypt text values at the top and the bottom of the range could have only come from extremes in the plain and key. So I switched to just using addition and subtraction and emulating modulus in order to get that all essential wrap. With the system as described, any plain text input can produce any crypt text output in the entire range, depending on the key. And a few further notes on the key. I would recommend at least 3 blocks (21 digits) in your key. 2 blocks (14 digits) can be brute forced in a reasonable amount of time. Brute forcing a 21 digit key would be possible, but isn't very practical. (It all depends on how badly they want to read the message!) Of course, 4 blocks or more is MUCH better.With 7 digits per key block, it will be tempting to use phone numbers for keys. Don't. It's the first thing any cryptanalyst will try. One way to create an easy to remember key is to use an abbreviated form of our encryption system to turn a pass phrase into a number. Of course we do NOT want any homonym ambiguity in our passphrase, so we skip the second digit and only use the first. Using this system the passphrase THEYELLOWROSESOFTEXAS would become: THEYELLOWROSESOFTEXAS 198384452651815818271 = 1 983844, 5 265181, 5 818271 This system can't produce a 0, and will produce a LOT of 8's. You can come up with more complicated schemes to get a more random key. (which is probably a good idea). Such as, instead of using the first digit, use the SECOND digit (the one that represents the letters position), and rotate through them with each occurrence of a letter. So the first e would be a 2, the second would be a 5, and the third would be an 8. This is STILL not very random, the more random you can make your key, the better, but you have to trade off with the ability to remember your key. |
|
|
|
| Donald | Nov 1 2005, 05:09 AM Post #3 |
|
Elite member
|
Initial look at Cryptanalysis of the Calculator Cipher: In the end, this is just a glorified Vigenere that encrypts 3 characters at a time (sort of). Strengths: The homonyms and encrypting 3 characters at once should make this cipher very resistant to IOC, Kasiski and probable word analysis. Resistant, but not immune. Weaknesses: Kasiski vulnerabilities at the character level: With this cipher, a character MAY influence the encryption of other characters in it's group of three, but it does not HAVE to. ESPECIALLY the right most character of the three. Note two different blocks of 3 characters, assume the same starting position and key:
The plain "44" encrypted to "25" both times. Unless modulus arithmetic causes the number to "wrap", encrypting the same rightmost character with the same key block will result in the same crypt character. And even the other positions are not guaranteed to be influenced by their companions. It all depends on whether the arithmetic causes a carry or a wrap. BUT, the good news for the cipher is that homonyms greatly reduce the risk of this happening. Each plain text character can be translated into a number at least three different ways. Kasiski vulnerabilities at the block level: Any block of three plain text characters, THAT HAVE BEEN TRANSLATED TO DIGITS USING THE SAME HOMONYMS, will always result in the same crypt text when encrypted with the same block of the key. Again, as with the above, the existence of so many homonyms greatly reduces the chances of this happening. But with humans choosing the homonyms, the odds of them choosing the same combination IS greater than pure random chance. Probable word pattern matching: Probable word pattern matching is MUCH more difficult, but again, not impossible. Especially if you can find a word or phrase that has 3 character patterns at the period length (or a multiple of it). For example, if the key is 3 blocks long, then the phrase: "One Vote to one man" would encrypt the two "one"s with the same key. BUT, again, the homonyms defend against this quite a bit. Known Plaintext Attack: Now searching for a probable word somewhere in the text will be very difficult. But I fear that this code will fall quickly to a known plaintext attack. If you know for certain exactly where a certain phrase is within the crypt text, even with the homonyms and alphabet shifting there are only 9*3=27 possible encryptions for each character, and only 27*3=81 possible plain text digits for the block. Which gives you 81 possible keys that that block could have been encrypted with. That's a lot for pen and paper, but a computer analysis should be able to quickly test those keys against other blocks and reveal which one is correct. [EDIT]UGH! After a good nights sleep, I realized that this analysis has BAD MATH SYNDROM!!!! if there are 27 possible encryptions for each character, there are 27^3=19683 possible ways to encrypt 3 characters. It's still very exploitable, of course, but now it's exploitable with GOOD MATH! [/EDIT]Second Digit predictability: Each plain text character in this cipher is converted into a two digit number. The first digit can be any number from 0 to 9, but the second digit, the one that determines the letters position in it's triplet, has less freedom. If the letter is the first of its group, the second digit will always be 0,1,4, or 7. If it's the second then the second digit will always be 2, 5, or 8. And if it's the third, then the second digit will always be 3, 6 or 9. So, since E is the second letter in it's triplet, we can ALWAYS know that the letter E will be translated into a number in the form of #2, #5, or #8. E might be 22 or 35, but it could NEVER be 21 or 59. Key Reduction: The OVERALL key size is the combination of all of your key blocks. But an attacker may decide not to approach them as one big key. Instead, they may simply attack one block at a time. I think identifying correct decryptions of 3 character blocks will be difficult, but if the decryptor can determine the period of the cipher, they can decrypt every single block of text encrypted with that block of the key and perhaps determine if the frequency/letter combinations are reasonable. If this kind of attack is workable, it would be devastating. The ZERO ONE Weakness: Since Zero can replace One when converting letters into numbers, the digits zero and one should both show an abnormally reduced frequency in a correct decryption. I'm not certain how well that can be exploited. --- And so, is this cipher going to replace AES? Ha! Not even in the ballpark. In the end, it may not even be as secure as a good playfair. I'm not certain. But I think it did achieve my goal. It's a cipher I can work on my wrist watch calculator. And if I can remember my key and not lose my place in the plain text, I can actually work it ENTIRELY on the calculator, writing down only the crypt text that comes out. In practice, my memory isn't that good. I have to have the key and plain text written out. Mainly it was fun to create and I hope you guys have fun shredding it to pieces.
|
|
|
|
| rot13 | Nov 1 2005, 03:18 PM Post #4 |
|
Elite member
|
The first thing I wanted to mention was the notion of brute force and key length. Donald sorta hit on it in his analysis, but I just wanted to make it clear. The notion that a 21-digit key requires a 21-digit number of brute force attacks is not necessarily correct. For digital ciphers, where the change of 1 bit can affect any bit in the block, then yes, the key size determines the number of attacks required to brute-force the key. For ciphers like this, and also like the CBC ones we were working on, certain parts of the key only affect certain parts of the ciphertext. If you brute force that section and figure out that portion of the key, you don't have to compute it again. In other words, let's suppose I need 256 tries to figure out the lower 8 bits of a key. Once I know that 8-bit value, I can attack the next 8 bits, and instead of having to do it in 256*256 tries, it is only 256+256 tries. That's because for every possible value in the 2nd 8 bits, I do NOT have to try all 256 possibilities for the lower 8 bits, I already know the correct value. In the case of this cipher, I think it is possible to brute force a block. Let me first say how I would do it with a key length of 1, then I can extrapolate later. I would start by attacking the rightmost character in the block. There are 9 possible initial block positions, and 100 possible values that were added to the number. That means I have to try 900 possibile values. I try each one and decrypt the rightmost character in each block. Then I compute the frequency distribution of the resulting letters and compare that with standard English. I pick the value that correlates most closely. Obviously this attach requires a sufficient amount of text. Once I know the block position and the added value, I go to work on the next character in the block. Since I know the rightmost part of each block, I know whether there would have been a carry-over from the addition on the rightmost part of the block. Again I try 900 possibilities and do the correlation. I would do the same thing for the last character in the block. If my math is correct, it would take me 2700 tries to crack the block. Since it only takes 2700 tries, instead of trying to work up some way to do a kasiski or IOC attack, I would probably just start with a key length of 1 and try to break it. Then I would try a key length of 2, etc. To try up to a key length of 10 is only 27000 tries. This is just theoretical, I haven't actually tried this attack. I don't have time at the moment to write a program to generate the ciphertext, much less one to crack it, but I am reasonably sure that it would succeed with a text about as long as the ones supplied by insecure for his CBC cipher. |
|
|
|
| Donald | Nov 1 2005, 03:27 PM Post #5 |
|
Elite member
|
Yowch! That's even worse than I THOUGHT it was. Excellent approach. I should have considered cracking one character at a time in the block instead of one block at a time. Yep, I think that's a solid crack. If I could only figure out some way to do mixing across the entire number while still maintaining mod wrapping. Thanks for the analysis! Donald |
|
|
|
| insecure | Nov 1 2005, 04:08 PM Post #6 |
|
Elite member
|
Now we're getting onto S-boxes. Incidentally, I will be covering these in a CBC challenge to come. Possibly CBC-3, although I must admit I was hoping to make the CBC-2-to-3 change something a little simpler, such as the use of key material rather than constants for the mathematics of the encryption. But maybe the time is ripe for CryptoForum to be introduced to S-boxes. Opinions? |
|
|
|
| Donald | Nov 1 2005, 04:17 PM Post #7 |
|
Elite member
|
I would LOVE to learn more about S-Boxes. So count my vote as FOR. BUT, I doubt if I'll be able to use them to fix the calculator cipher.  I probably should have stuck with the original design which used an 8 digit key # ## #####. The first digit was S (for the alphabet shift) the next two digits were A (and must not be zero) and the last five digits were B. And the equation was Crypt Text=(Plain Text*A)+B It mixed the results up pretty well, but, as I said, you were leaking information about the plaintext and key at the extremes of the range because the only way to GET an output of 99999900 was with plain text of 99 99 99 and a key of 99 99999. <sigh> Alas, I wish my wrist watch had a MEMORY, I could have done some cool things with that. Donald |
|
|
|
| rot13 | Nov 1 2005, 05:46 PM Post #8 |
|
Elite member
|
I'll second the vote for S-boxes, although in the interest of not getting too difficult too fast, I would ask that we have a reduced number of rounds. |
|
|
|
| insecure | Nov 1 2005, 07:21 PM Post #9 |
|
Elite member
|
rot13 - are you of the opinion that S-boxes (and I'm thinking specifically of 8x8 here) would be sufficient to mask the silliness of those constants, or should they be fixed at the same time? I don't want to change too much at once, but I think this might be worth doing. I agree that we can reduce the number of rounds - perhaps to 2? |
|
|
|
| rot13 | Nov 1 2005, 07:47 PM Post #10 |
|
Elite member
|
That's a toughie. I guess you might as well fix the constants. It will make things tougher, but it will be a better example. By fix I just mean to make sure that the right-most bit of the multiplier is 1 if nothing else. The proposed numbers you mentioned towards the end of the CBC thread should be fine. And 2 rounds sounds good for a start. |
|
|
|
| 1 user reading this topic (1 Guest and 0 Anonymous) | |
| « Previous Topic · General · Next Topic » |
11:05 PM Nov 27
