# Encryption algorithm designed to be easy to decrypt by machine but impractical to decrypt by hand

I am looking for - or considering the design of a new - encryption algorithm that does not use variable keys, such that it is easy for a computer to encrypt and decrypt any message regardless of its source, yet it is possible but impractical for a human using their brain and a pencil and paper to decrypt for any non-trivial length message.

Does anyone know of such an algorithm or have any ideas as to how to design one?

EDIT: The people using this algorithm have computers, but may need to hand-write the cipher text due to a lack of a printer, and may lack networking capability, so the message would have to be physically transmitted and scanned or retyped, thus, easy readability and hand-copyability is an advantage.

The persons attacking this cipher do not have computers, but may know the algorithm. The goal is to make the attackers waste human resources decrypting the messages.

• should it be practical for a human to encrypt by hand? – Richie Frame Oct 29 '14 at 4:23
• I'm guessing this is supposed to be a heavy-duty analogue of ROT13. $\;$ – user991 Oct 29 '14 at 4:30
• What do you mean by variable keys? How about RC4? – Dmitry Khovratovich Oct 29 '14 at 11:32
• @DmitryKhovratovich "...does not use variable keys..." Monty, do you mean that you want to use a fixed key value or a fixed key format? – Maarten Bodewes Oct 29 '14 at 16:33
• You are pretty much describing any modern cryptographic algorithm with a human readable encoding scheme... – Richie Frame Oct 30 '14 at 4:37

How about just plain old DES?

Each round is fairly simple, you take a few bits, duplicate (expand) them, calculate (shuffle bits, shift bits, replace them) the next value from a key, XOR the data with the resulting key, and "un-expand" the the result. It's an operation that could theoretically be done on paper in about a minute.

But then you repeat the action 16 times. These 16 rounds have to be done for every single byte (character). It's possible for a human to do, but spending 15 minutes to decode per character would be impractical. If you really want to make this worse on the user, try 3DES (basically re-encrypting the data using this same method three times).

To meet the requirement of "encryption algorithm that does not use variable keys", you could decide on a fixed key (make it a standard, and part of the specification. That way, the two parties don't need to meet ahead of time to decide on the key.)

Or better yet, send the random key to be used in cleartext along with the encrypted data For the decrypting computer, having the key will make decrypting a cakewalk (compared to trying to crack DES without the key, that is). For a human, however, having this key won't make it any faster, it just means they can't create a lookup table ahead of time.

• At that point, why not just used fixed-key AES? – Stephen Touset Oct 29 '14 at 20:25

Another way to is to take a page out of the book of Public Key Cryptography. In this case, I will illustrate how RSA can be used.

In this example, I have encrypted a number between 65 (which decodes to A) and 90 (which decodes to Z), assuming I send you the value 1486. Quick, what is the value of this?

$$1486^{2753}\ mod\ 3233$$

A computer could tell you, but this operation is really difficult on paper (and all your hard work only gave you a single character of the data). Now imagine using $2^{2048}$ bit keys to encrypt the information, instead of our paltry $2^{12}$ bit key.

This method too, would require a pre-defined pair of keys, but you can make them public to make the operations fast for computers, but near impossible on pen and paper.

• Yes, until someone precomputes the value of every letter when encrypted with that exponent and modulus, then it suffices to look up the ciphertext in a small table. To counter this, you could pack multiple letters in a single plaintext, or simply change exponents and modulus often. – Thomas Oct 29 '14 at 6:25
• @Thomas I was going to add a comment recommending to add an algorithm that alters the output by including (either by XOR or other means) the value of the previous output when calculating the next value in line, but I can't for the life of me remember (or even find) the name of that type of system. Do you know what I'm referring to? – IQAndreas Oct 29 '14 at 7:08
• Looks like you're referring to a generic feedback scheme. CBC and CFB mode are two such schemes for block ciphers (en.wikipedia.org/wiki/Block_cipher_mode_of_operation) – Thomas Oct 29 '14 at 7:27
• @Thomas Don't see why you cannot use full RSA encryption that includes cryptographically safe padding (PCKS#1 v1.5 or even better OAEP) that contains a random element to it. In that case it is impossible to create meaningful tables. Note that just concatenating RSA does not protect against replay attacks nor does it provide integrity. – Maarten Bodewes Oct 29 '14 at 16:30
• @owlstead Yes, as long as you add any kind of nondeterminism in the scheme, that will be enough to defeat precomputation and lookup for a human without access to a computer! (admittedly the question didn't specify the exact threat model, so this may be overkill, but since we're talking about giving the computer an advantage we can be as overkill as we want :)) – Thomas Oct 29 '14 at 22:46