(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