Slashdot Mirror


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...

2 of 77 comments (clear)

  1. Use a code book! by MarkusQ · · Score: 5, Insightful
    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

  2. do-it-yourself one time pad by chongo · · Score: 5, Informative
    For a non-public key stream cipher:

    If you allow the addition of dice, say a d20 ...

    Setup by the sender:

    1. Generate a one-time pad by rolling the d20 and writing down the 1's digits (d20 face value mod 10).
    2. Transmit the one-time pad in a secure fashion (use somebody's public key suggestion, hand carry, etc.)
    Setup by the receiver:
    1. Receive the one-time pad from the sender.
    2. Store in a secure place.

    To encrypt:

    1. Convert each plaintext symbol into an alphabet of 100 values (00 thru 99).
    2. For each plaintext digit, remove a digit from the one-time pad and transmit the sum mod 10.
    3. Destroy the used digits of the one-time pad.

    To decrypt:

    1. Receive the cipher text from the sender.
    2. For each digit in the cipher, remove the next digit from the one-time pad and subtract mod 10, from the cipher digit.
    3. Convert the result, pairwise, (00 thru 99 alphabet) into plaintext symbols.
    4. Destroy the used digits of the one-time pad.

    Encrypt example:

    1. Plaintext: Hello
    2. One-time: 9690367034
    3. Alphabet: 0730373740
    4. Transmit: 9320630774

    Decrypt example:

    1. Receive Ciphertext: 9320630774
    2. Receive One-time: 9690367034
    3. Subtract mod 10: 0730373740
    4. Convert to text: Hello

    And yes, the devil in the details is in the secure transmission of the one-time pad (step 2 of sender setup). Key management is never easy. Storage and transmission of one-time pads is one of the reason why this form of crypto is not a realistic choice for most applications. However if you have some way to transmit the one-time pad ahead of time, say visiting the sender ahead of time and dropping off the one-time pad it is not a bad choice.

    --
    chongo (was here) /\oo/\