Designing a secure and convenient encryption algorithm that doesn’t require a computer program or a machine is quite a challenge. The Handycipher is an interesting method of this kind.

Imagine a spy operating in a foreign country, who needs a method for encrypting messages to his contact person. Using an encryption machine, like the Enigma, or some other cipher device is prohibive in this situation, as this might raise suspicion. Nowadays, a computer program would do this job, but computers were not available until a few decades ago.

For the reason mentioned, the design of purely manual ciphers has played an important role in cryptography for centuries. However, this has proven a hard problem. It is extremely difficult to design a purely manual cipher that is both secure and convenient – especially if it is desired that such a cipher withstands modern cryptanalysis.

Today, the Double Column Transposition (DCT, also known as double cube), is considered one of the best manual ciphers. George Lasry has pointed out that ADFGVX (a World War I cipher) is another interesting candidate, provided that the second step of this method (a transposition) is carried out twice.

Others have suggested encryption algorithms that use unsuspicious aids, such as Rubik’s cube encryption and Solitaire (uses a deck of cards). Recently I heard of a new manual cipher named Elsiefour – I will certainly take a closer look at it soon.

The Handycipher

Today I am going to introduce another manual encryption system: Handycipher. It was created by Bruce Kallick a few years ago.

Handycipher encrypts each plaintext letter into a letter group. This means that the ciphertext is longer than the plaintext. Such a property is usually not desired. Among other things, it results in the fact that an encrypted file needs much more storage space than the plaintext file.

However, when it comes to manual ciphers (especially, spy ciphers), writing five letters instead of one is acceptable, especially, if this avoids a lengthy and cumbersome encryption procedure.

Handycipher encrypts text strings taken from a 31-character alphabet comprising the 26 uppercase letters together with the five
symbols “,”, “.”, “-“, “?”, and “ˆ”. Here’s an example of a plaintext:

A Handycipher key is a permutation of the 50 letters of the ciphertext alphabet and the symbol “ˆ”. Here’s an example key:

QjufGCtwbUSNLqHAgVDOoansIhyBKJWFdxvPk^peXMTlirYRmcE

The key (without the “ˆ” character) is written in a table with ten columns and five rows. Using our example key this looks as follows:

A second table is derived by omitting the 20 lowercase letters f-y and substituting the characters “Z”, “,”, “.”, and “?” for the letters a, b, c, d, and e. As Q is the first letter in the table above that is not omitted, it is assigned to the number 1. G, the second letter not omitted, is assigned to 2. C is assigned to 3, and so on. Here’s the second table:

The numbers in the lower line range from 1 to 31. For the encryption process we need the binary representation of each number: 1=00001, 2=00010, 3=00011, …, 31=11111.

As an example, let’s now encrypt the plaintext character “?”, which is represented by 21 = 10101. As one possibility, “?” can be encrypted to QuG, because the first line of the left half of the first table is QjufG and 10101 indicates that the first, the third and the fifth letter have to be taken. Alternatively, “?” can be encrypted to SLH, because the second line of the same table is SNLqH.

Stupid question perhaps, but how is this actually uniquely decryptable? For example, the letter L could stand for 00100 in the second row, or for 01000 in the third column. So in our example it could be the encryption of “,” or of “L”. Am I missing something? Are single letters always considered in rows?
Also, I think there is an additional limitation: When you write the ciphertext without spaces, as intended, you have to be careful not to use the same row/column/diagonal twice in a row. (Otherwise, again, unique decryption is impossible: oasI could decrypt to 11011 or 11000 00011 or 10000 01000 00010 00001 or many other combinations.This is especially difficult, again, if one of them is a single letter. Then it cannot be in the same row/column/diagonal used in the one before or in the same row/column/diagonal used in the one after it. For example, if you encrypt 31 as SNLqH and wish to follow up with 8, it mustn’t be encrypted as S, N, L or q. H would be possible, since there is no confusion there, but still… I’ll have to read up the specification more closely.

Ah, yes, that makes sense. Thanks for clearing that up. Do you also know why the “^”-symbol is part of the key? Wouldn’t we get more or less the same situation if the key consisted only of the 50 letters and we just substituted in the “^” like the other extra symbols, for example instead of “f”?

Regarding Moritz’s comment #7, it’s perhaps more helpful to say that the eight additional diagonals are regarded as “wrapping around” the left and right edges of the square.
Also, rFLaW is not correct (it should be rfLaW).

Reading from top to bottom, there are five left-to-right diagonals {QNnxr, jLsvM, uqIWT, fHoF1, GSadi} and five right-to-left diagonals {QHsdT, jSIx1, uNovi, fLaWr, GqnFM}. (I’ve typed 1 here for the lower-case L to distinguish it from the upper-case I.)

This is neither convenient nor secure. It’s just an extremely cumbersome homophonic cipher. Having to memorize the first 30-something binary numbers (or even write them down) is extremely time consuming. If you want something that’s ACTUALLY convenient and secure, check out the Hutton cipher.