(2025-03-24) Let it be as simple as it can be... but no simpler
---------------------------------------------------------------
The topic of "hand" or pen and paper ciphers turns out to be much vaster than
I initially thought. Even in the modern era, new designs are constantly
popping out. Some of them are made just for fun and don't imply a lot of
security (being used, like, at school or for geocaching purposes), while
others are seriously preparing for even more dystopian scenarios than we
already are living in. The main problem of the second group of such ciphers
is a great deal of inconvenience: either with key material distribution if
we're talking about one-time pads, or, if we're talking about something
else, with encryption/decryption process itself which usually is too slow
and/or error-prone. Today, I'd like to focus on a single case of taking a
for-fun cipher from the first category and applying some slight
modifications to it in order to successfully (in my opinion) move it into
the second category without increasing the complexity too much. Let's go!
I must admit, I don't know much about ACA (American Cryptogram Association)
except for the fact that this organization turns 95 years old this year and
that its members still are proposing some interesting pen and paper cipher
designs to this day and challenge others to break them. In this very
context, the CONDI (CONsecutive DIgraph) cipher developed by Wilfred
Higginson in 2011 seems like a perfect candidate. It's quite easy to use in
the field and possible to crack for amusement. What's more interesting
though is that everything that makes it possible to crack can be mitigated
just as easily. So, let's first describe the original CONDI algorithm.
Message preparation (quoting the document): The Condi uses a simple keyed
alphabet and keeps the word divisions and retains
punctuation. Proper nouns are preceded by an asterisk (*).
Key preparation: write the keyphrase and the rest of the A-Z alphabet, then
strike out the letters that appear more than once. Then you may cyclically
shift the alphabet by some known position. You should be left with 26 unique
letters in a mixed order. Also, you must select a random offset from 0 to 25
as the initial offset.
Encryption (quoting the document): With a starter value or offset of #,
substitute the first plaintext letter by the letter found # places further
along the alphabet. Then the position of that first plaintext letter is the
new value for #, the offset for the next plaintext letter.
Decryption: With a starter value or offset of #, substitute the first
ciphertext letter by the letter found # places left along the alphabet. Then
the position of the found plaintext letter is the new value for #, the
offset for the next ciphertext letter.
As we can see, the design is simple but, although it's reported to be
"surprisingly difficult to crack even with a computer", it poses multiple
problems when it comes to serious analysis. Let's list those noticed by
myself alone:
1. Since the offset value comes from the plaintext letter we just have
encrypted, the initial offset only affects the first ciphertext letter and
nothing else. The rest of the ciphertext can be attacked as if the first
letter doesn't exist.
2. Word length, punctuation, proper noun and whitespace preservation might be
fun for recreational usage but not for any real secret communication in a
non-electronic setting.
3. Just like the original (non-interleaved) Playfair, this cipher encrypts
the same plaintext digraphs into the same ciphertext digraphs, and the
message like "aaaaaaaaaa" will encrypt into the same letter of the
ciphertext.
4. The keying scheme, while being popular at ACA, does not consider repeating
keyphrase letters at all. So, for instance, the keywords "routes" and
"routers" will produce the same alphabet.
5. The overall keyspace is too small for bruteforcing the keyed alphabet by
an adversary with modern equipment, as it corresponds to about 88 bits. This
is true for any hand ciphers that rely upon a single A-Z alphabet
permutation.
Now, how can we improve this without complicating things too much? Well,
three things come to mind: change the alphabet keying scheme, make the next
offset dependent on more things and, most importantly, introduce the second
key. Within several days of brainstorming, I have come up with something
that addresses all these points.
Enter the... DRACONDI. It stands for "Dual-key Rotating Alphabet CONDI". It
still is simple enough to execute on paper and in software but eliminates
all the original CONDI weaknesses. I have released the full design along
with some reference implementations on my Codeberg page ([1]), but here are
the main points:
1. The keying algorithm has been changed: every subsequent repeating letter
of the keyphrase is substituted with the previous unused one in the
alphabet, the process repeated if necessary. Then, the rest of the alphabet
is written in order. Then, the alphabet is cyclically shifted L characters
left, where L is the keyphrase length.
2. This keying algorithm is applied to TWO keyphrases to get TWO keyed
alphabets, KA1 and KA2.
3. The KA1 alphabet is used like in the original CONDI. Additionally, it's
used to prepend the initial offset value to the ciphertext. Unlike the
original CONDI design, this value is selected randomly for every new
ciphertext and then encrypted with KA1.
4. The KA2 alphabet is used in the next offset calculation step: instead of
the plaintext letter position in KA1, we use the _ciphertext_ letter
position in KA2 and then add (modulo 26, of course) the amount of already
encrypted/decrypted letters.
5. Finally, all word division, punctuation etc are ditched. DRACONDI
recommends (and, for software implementations, even mandates) dividing the
ciphertext into 5-letter groups, padding them with random letters at the end
to fill the last group if it's not 5 letters long.
This approach increases the keyspace size to the whopping 176 bits, makes
sure the initial offset affects the rest of the ciphertext, breaks any
digraph dependencies, makes every repeated keyphrase letter count, and
prevents revealing any information about the plaintext structure. All while
adding a single offset calculation step using the second keyed alphabet
which would still allow to maintain reasonable encryption/decryption speed
when doing things fully manually. As of now, I can't think of a simpler
substitution cipher design which would be just as secure as this one, but I
think the key is... never stop looking. Have fun!
--- Luxferre ---
[1]:
https://codeberg.org/luxferre/dracondi
