## “Perfectly” Encrypt 50 Letters By Hand

January 6th, 2014 at 12:32 UTC by

When I read about cryptography before computers, I sometimes wonder why people did this and that instead of something a bit more secure. We may ridicule portable encryption systems based on monoalphabetic or even simple polyalphabetic ciphers but we may also change our opinion after actually trying it for real.

A long time ago I and George French spent some time trying to create a pen&paper encryption that would be easy enough for people to use. We have realised fairly quickly how difficult it was to create something that would allow to encrypt even short messages. Encryption tables we came up with allowed encryption of 50 characters in one go and they took whole A4 sheets. I was hoping to be able to encrypt 160 characters with one A4 sheet but it was impossible if we wanted to keep instructions simple.

Our encryption tables need to be generated and printed but after that, encryption and decryption can be done without any electronics. We used one-time pad encryption scheme as it was one of the simplest. The current implementation generates one-time pads from time and a secret stored on the server running the table generation script (absolutely not the most secure way of doing it).

I have recently revisited the Python script for generating encryption tables and extended the alphabet from 26 letters to 37 by adding digits and space. If you want to experience cryptographic without computers, here are instructions.

1. Each time you click on the link below, you should get a new encryption table. Incognito/Private windows help a bit but you should delete PDF files if stored on the disk. (It is good to use thin paper for printing as that is easier to burn or eat )

### GET A NEW ENCRYPTION TABLE

2. Personalise the encryption table and share it – imagine you have 10 friends and intend to send 5 messages to each of them. The rule of thumb would be to create 10×5 encryption tables to prevent any errors and minimise compromise. You can try to optimise the number of tables but you will always increase risk of messages to be compromised.
3. Choose a message and recipient, find an encryption table and encrypt. Write the message at the top. Find each letter in the column underneath and write the second letter on the bottom line.
4. Tear the bottom line away, burn or dissolve in acid or eat the rest of the paper, and send the message.

Steps for decryption are following:

1. Find the correct encryption sheet (its identification code must match the code received with the message).
2. Align the encrypted message with columns or write the message on the first line of the decryption table.
3. Decrypt the message. Find each letter in the column underneath and write the second letter on the bottom line.
4. Read the decrypted message and burn or dissolve in acid or eat the whole paper.

The same instructions with pictures are here.

It is a simple system but it nicely demonstrates most of real-world problems with encryption. How to securely generate keys (i.e., encryption tables). How to do key distribution. How to communicate compromise of a key and mitigate the leak.

Not everyone has a spare passport, pile of cash, and reports to M.

UPDATE: The source code is at https://github.com/smartcrib/papercrypto

Entry filed under: Protocols, Usability, Useful software

• 1. Anon  |  January 6th, 2014 at 17:56 UTC

This is excellent Dan. Could you put the source on github?

• 2. Matt  |  January 6th, 2014 at 18:22 UTC

Should the lower half say, “Send last 5 letters of the sheet code with the message?”

• 3. Dan Cvrcek  |  January 6th, 2014 at 20:33 UTC

For whoever is interested in the source code: https://github.com/smartcrib/papercrypto

• 4. Anon  |  January 6th, 2014 at 20:46 UTC

Super cool, thanks so much Dan!

• 5. kme  |  January 6th, 2014 at 23:18 UTC

The Solitaire cipher was designed to be a pen&paper cipher secure against machine cryptanalysis.

• 6. Dan Cvrcek  |  January 7th, 2014 at 12:57 UTC

Solitaire is quite nice as it completely avoids computers. Unfortunately, it seems to be quite difficult to use. We played quite a bit with an idea of a mechanical tool for generating the key but it was too difficult to use.

• 7. M  |  January 7th, 2014 at 21:20 UTC

Thanks Dan, I have rolled this out to all field operatives with immediate effect.

• 8. M  |  January 7th, 2014 at 21:40 UTC

Incidentally if you’re interested in this I recommend spending many fascinating hours on this site:

• 9. Dan Cvrcek  |  January 8th, 2014 at 08:09 UTC

Excellent M! Here at MiB, we are on it as well.

• 10. Dan Cvrcek  |  January 8th, 2014 at 08:24 UTC

In my view a less important issue but there was some discussion about how the table is generated – how random it is.

The script uses three sources to create random seed:
1. time of running the algorithm
2. static string hardcoded in the code
3. urandom() – PRNG provided by the operating system

The thinking behind is to have at least some source of randomness if the script is used or installed incorrectly.

Re-seeding with urandom() is done for each character. I also make sure that I get uniform distribution over 0-36 = the character set for encryption tables.

• 11. SNAKEOIL  |  February 7th, 2014 at 10:32 UTC

Please DO NOT USE this cipher implementation for anything more serious than playing spooks and teaching children tradecraft.

There is at least half a dozen reasons why.

First, the combination of RNGs used is not of cryptographical strength.

Second, it is run by an untrusted party (not either personally you, or somebody who is going to get screwed in case of compromise). They can store all copies issued and turn over it to any three-letter agency, or they can in fact run a keyed RNG to recover keystream at will given only a message indicator.

Third, the generator is not being run on an securely sanitized airgapped system. Even if the site operator is benevolent, general purpose computers, operating systems and applications do leak data into pagefiles, /tmp filesystems etc; files are recoverable after being deleted. And the system is connected to the Internet, so it ALSO is subject to compromise by worms and exploits.

Fourth, conversely, you are not running a securely sanitized airgapped system. Think browser cache, print spool directories and trojan horses.

Fifth, those two are communicating over an insecure channel (plain http, not https+vpn), prone to eavesdropping and tampering.

Sixth, the code is not audited by a trusted and competent third party.

• 12. Adam Funk  |  February 18th, 2014 at 14:23 UTC

Another tip: make sure you don’t have the paper folded over or on top of the envelope while you’re writing the plaintext. The impression could be read by rubbing it with the edge of a pencil. (I think I learned this from Encyclopedia Brown or a similar source.)

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>