Calculator-based cryptography

You think you need a computer to have a high-security code? Think again. I am about to tell you how to encrypt a message with as much security as you want, using just a common calculator. The name of this code is “root”, because the calculator’s square root key is what makes it secure.

Let’s say you have an important message you need to transmit, but your enemies have tapped your phone, fax, and email, and you suspect they have infected your computer with a worm that will relay to them everything inside. Let’s say your message is:

MEET ME AT THE TRAIN STATION

The first thing you have to do is convert each character into a two-digit number from 00 to 99, following a code you have agreed with your friends. This gives you room for all letters in the alphabet, plus numbers, plus a whole lot of special characters. Let’s say the code gives 00 for a space (though often it is better to eliminate spaces and punctuation altogether), and then the letters are numbered in alphabetical order: A = 01, B = 02, C = 03, and so on. Then the message becomes:

13050520 00 1305 00 0120 00 200805 00 2018010914 00 19200120091514

Of course, cracking this would be child’s play for just about anybody, so we must conceal it under something really difficult to guess. Here’s where the calculator comes in handy. But before you begin, you need to have two more things. The first is a secret passnumber, which you have agreed with your friends. You have memorized this passnumber and never ever written it down. If you find it hard to memorize a long number, then use a password made of text, but you must convert it to numbers, as described above, before you can use it.

Let’s say your passnumber is:

123456789012345678901234567890

Its length is a function on how many digits your calculator can handle. It should be a little shorter than a multiple of the calculator’s precision. Here I assume you have a 12-digit calculator (many desktop calculators can do that; the more digits, the better). Your friends should have an identical calculator, or the code will break down.

The second thing you must have is a serial number for your message, which you must produce right now. The only trick is that you should never exchange two messages with the same serial number (in either direction), or the code will be exposed. The length of the serial number is equal to a multiple of the calculator’s precision, less the passnumber length. Since we use 12-digit calculators and a 30-digit passnumber, that leaves 12×3 – 30 = 6 digits for the serial number, with enough room for a million different messages.

Let’s say you pick this serial number:

555555

Now append the serial number to the passnumber and break the whole thing into groups of 12 digits, like this:

123456789012

345678901234

567890555555

Now comes the tricky part. You must convert these into three kinds of mathematical entities: multipliers, adders, and a seed. Since you have only three numbers, you’ll have one of each. The multipliers have half of its figures as integers and half as decimals (because of the 12-digit precision, since 12/2 = 6 integer figures; if we had a 14-digit calculator, then you would take 14/2 = 7 integer figures). The adders have two fewer integer figures, in our case, four. The seed is all decimals, and it contains the serial number as its tail. Thus, you have:

Multiplier = 123456.789012

Adder = 3456.78901234

Seed = .567890555555

Now you enter these numbers into the calculator and perform the following calculation:

Result = fract(sqrt(Seed * Multiplier + Adder))

In other words, you take the Seed, multiply it by the Multiplier, and add the Adder. Then you take the square root of that result and subtract the integer part so that only decimals remain. With the numbers of our example, this is:

The last number obtained becomes the new Seed, and the process can be repeated. If there are more adders and multipliers, the next time a different set of Multiplier and Adder is used. When all the adders and multipliers have been used once, you look at the digits of the final result, which add to the encrypting “keystream”. In the example, they are:

231881430 (all zeros count, except the one on the left of the decimal point)

Then you write those numbers underneath the message (turned into numbers), and add the two together neglecting carryovers (so you can do it from left to right). If there are not enough digits in the keystream, you generate more with the calculator, starting with the last result as Seed but using the same adders and multipliers, until there are enough. Your message has 56 digits but the calculator has given you only 9, so you need to do it six more times. It is convenient to store adders and multipliers in memories (which you will erase when you’re done, right?) to save work. In this way, you get:

where the last sequence of numbers is obtained by adding the other two digit by digit, neglecting any carryovers (that is, 8+7 = 5, not 15)

Now you only have to send your friends this last sequence of numbers, plus the serial number (as a list of phone numbers, or stock prices, or whatnot), confident that nobody who doesn’t have the password will be able to decipher it. So, this is what you would send more or less in the open, assuming you have agreed to place the serial number at the very beginning:

55555536138663013147259856534369586568921249742259748124481858

Your friends, after retrieving the serial number from the message itself and the passnumber from their own brain, will be able to produce the exact same encrypting keystream from their calculator, and they will subtract it (again, neglecting any carryovers, so that 5 – 7 = 8, and so on) from the transmitted message, in this way:

And now they can easily convert every two-digit group back into characters:

MEET_ME_AT_THE_TRAIN_STATION

That’s it! Now anyone can enjoy high-strength encryption without the help of a computer.

Now, you’re probably wondering, how strong is this cipher, really? The short answer to that question is: that depends on the length of the passnumber and on how many digits your calculator can handle. The more digits in either, the better.

A long passnumber ensures that a lot of possibilities must be tried by anyone trying to crack the message by brute force. If the passnumber is thirty digits long, that’s 10^30 different numbers to try. This is comparable to using a 99-bit binary key, which is just about twice as long as the 56-bit key of DES encryption, used by the US Government until recently. A team of determined hackers cracked DES by brute force in just about 23 hours in the year 2000. Assuming that Moore’s Law holds (that computer power increases by a factor of ten every five years, for a constant inflation-adjusted cost), the same team wouldn’t be able to crack your 30-digit encription by brute force in under a day until sometime in 2065 AD. Even giving the NSA a ten-year advantage, that’s still pretty good for most of us.

If this isn’t enough for you, you can always use a longer passnumber, since every digit added increases the cracking difficulty by a factor of ten. Now, this is best done by chunks as big as can fit in the calculator. So, if you use a 12-digit calculator, the next thing to do is to use two multipliers instead of just one, and then the next to use two multipliers and two adders. The digits added to the keystream are those obtained after all the adders and multipliers have been involved. And so on, and so forth.

Additional security can be gained by using a special “message key” instead of passnumber+serial to generate adders, multipliers, and seed (just in case you make a mistake and use the same serial number twice, more on that later). In this case the process goes the same way, except that the first series of digits coming out of the calculator are used to make a new set of adders, multipliers, and seed, and then the keystream is produced starting from those. This added step forces your generating numbers to be completely different from message to message (not just the few last digits of the seed), and thus your master passnumber is never exposed in any way. I recommend using this precaution, which does not add that much extra work anyway (because you’re going to burn the paper containing your calculations, right?).

It is important to make sure that the serial number is never reused (by either side of the transmission), because then the same encrypting keystream would be used for two different messages. An enemy could then eliminate it by subtracting one message from the other, leaving a superposition of two unencrypted messages that would be quite easy to crack by letter frequency methods. And on top of that the keystream would be revealed, from which it might be conceivably possible to extract the numbers used to generate it. This is a bad feature of all “stream ciphers,” like this one, but they also have good features that other ciphers don’t have. For instance, in most ciphers any mistake garbles the end result completely, but in stream ciphers only the characters encrypted after the mistake end up garbled, which makes it a lot easier to spot the error and correct it. Handy when it’s just you punching keys.

And how about the calculator? If it uses too few digits (many pocket calculators display only eight), then the pseudo-random properties of the keystream suffer, and the message is exposed to statistical analysis. The sequence will also start repeating after a while, which is bad. In my experience, eight digits is no good, ten is barely acceptable, and twelve and above work fine. The more digits, the better. I have a Palm-based calculator that can operate with thirty-eight digits at a time, so it gives me better security than the current AES governement standard (256-bit) without even using an adder.

You have to thank irrational numbers for this cipher. The digits of irrational numbers obtained from a square root, like the square root of two (1.41439799432119332181380109536190378…) never repeat, and appear random to anyone who doesn’t know where they came from. It is this apparent randomness that conceals your message in noise, rendering it impossible to read.