Encryption by Hand?

Arachn1d writes "A question for all those slashdot math-geeks out there: What's the simplest, but most secure encryption algorithm you can devise or provide a link to that can be carried out with nothing but a pen, some paper and a calculator? Bonus points for any public-key cryptography solutions!" Bruce Schneier developed an encryption algorithm designed to be performed with a deck of cards, but it's rather slow to do for fun. Well, you did say "a calculator", and if we assume a programmable calculator your options probably expand quite a bit...

Comments

Use a code book!

[MarkusQ]

1) Use a code book. Something with a concordence is good, though if you have the book in flat text you can easily make a concordence. Then you could write "fungal:17" to mean "staple" if "staple" (the word you intended) occured N words after (for some pre-agreed N) the seventeenth occurance of "fungal". There are a number of cute ways you could encode seventeen, and it's relatively easy to make N vary as well. Since this is "security through obscurity" you might as well have fun with it.

2) If you are going to be hand writing the messages as well, you may want to use out of band information (letter shapes, mispellings (with & without crossing out, etc.), line breaks, etc.) to either carry information or make it appear that you have hidden information & thus confuse the issue.

3) Split the message (e.g. every third word, etc.) in interesting ways.

4) Play Simon-says; send messages that say things you might have said, but that your recipient knows to ignore because they lack some feature.

Etc., etc. The list is pretty long, and success mostly depends on doing Odd Things the Bad Guys don't expect, and avoiding the Dumb Things that they will see right through.

Weren't you ever twelve?

-- MarkusQ

Don't do that!!

[epsalon]

These numbers, which are probably random, are not crytographically secure precisely because it's in a book you can find in the library.

An attacker can easily find out which book you are using from quite a small portion of plaintext and thus reveal all messages past and future.

One Time Pad relies on the utmost security of the key, and the fact that it's only used once (for any purpose).

RC4

[phr1]

Check the RC4 algorithm, which normally is done on a 256-element vector so we'll call it RC4-256.

It's pretty obvious that you can use vector sizes different from 256. For example, you can do RC4-52 with a deck of cards face up on a table (4 rows of 13 so you have to do arithmetic in your head mod 13 and 4 on the cards and suits--you figure out the details). Or you can do RC4-99 (9x11 grid) or maybe RC4-100 (10x10 grid) with pencil, paper, and eraser.

Then as several people mentioned, there's always the one-time pad. If you want to encrypt just one or two very short messages (total a few dozen characters or less), one innocuous way to carry the pad is as a wad of cash (I mean just a normal quantity of $1 and $5 bills in your wallet, not a suspicious roll of $50's and $100's). Use the serial numbers as the pad and spend the bills when you're done with them.

Forget public key. Public key cryptography in any known form is impossible without a programmable device. The calculations are just too cumbersome to do by hand. Anyway, public key probably isn't too useful in this situation. Public key solves the "n**2 problem" when a bunch of independent mutually distrustful peers are all trying to talk to each other--you only need one secret per person, instead of n**2 different secrets. For pencil and paper ciphers you're probably only communicating with trusted peers, so a shared secret is ok.

Of course if you have even a crude programmable device like a pocket organizer (even some of the ones much less fancy than a Palm Pilot) or a Java-enabled cellular phone, you can run all the usual computer cryptography algorithms on it.