Gyassa home

Gyassa

General code and thoughts from an owner of Gyassa

Pseudo Blog maintained by sampwhite Hosted on GitHub Pages — Theme by mattgraham

Enigma Machine and Deduction of the Plugboard

Aug 6, 2026

I have just come back from a trip to England where I was part of an excellent tour examining the history of computers and cryptography with a particular focus on the origins. As part of this tour, I prepped by reading various books on the same subjects, especially as it related to England. During the tour, one of the primary topics was the Enigma machine, the usage of the Germans during World War II of the machine, and the work done at Bletchley Park in England to crack the encryption.

The Enigma machine, in simple terms, has two key parts. A scrambler that combines four (or five) permutations – three rotors that turn, a fixed reflector, and on the naval machine an extra fourth rotor that does not turn. The second is a plugboard that swaps letters on the way in and on the way out. Both the scrambler and plugboard have settings that can be configured before doing the encryption, and the primary agenda at Bletchley Park was determining those settings. In the books, there were good accounts of how the scrambler settings were determined. The books showed how the failures of the Germans to use the Enigma machine correctly combined with cleverness on the part of the decoders allowed mathematicians, crossword puzzle mavens, and primitive forerunners of computers to crack the scrambler settings. It made it clear that this was a massive effort made by hundreds of people and a great amount of specially built hardware.

But the books were essentially dismissive of the labor required to deduce the plugboard settings once the scrambler settings were determined. In one book, the labor was declared to be equivalent to breaking a simple substitution cipher typically broken by frequency analysis on the cipher letters. The comparison to a substitution cipher did not make sense to me. A substitution cipher can be attacked by doing frequency analysis on the text output. The cipher of the letter E would still be the most common character in the cipher text. But the scrambler flattens the frequencies, and because the plugboard is applied at both input and output, applying the deduced scrambler to the cipher text would still yield text with flattened frequencies.

For this investigation I used Claude Opus 5 to create a Groovy script that could be executed in an online Groovy Web Console. The general instructions to Claude were to create a Groovy code simulation of the Enigma machine in a way that could be used both for instruction and as a test bed. I wanted Claude to create something I could learn from, and I did not want the code divorced from its source material. This creation was done iteratively as we first built out a model of the Enigma machine and then built out a test harness for the decryption attacks. Claude wrote 99% of the code, but I gave fairly constant feedback. In some cases, I adjusted how it did comments and prompted it to write additional comments on the trickier parts of the code.

One of the primary problems for simulating an attack on the plugboard was simulating how a code breaker can look at the output and see fragments of German words appearing. I did this by using the plain text as an oracle. A test run would start with a given piece of crib text (text where plain text and cipher text were both known) of a given length and then do trial runs with different plugboard settings. If after such a run, the candidate decrypted text matched the plain text for four contiguous characters, then those characters would be added to the known crib text.

The key result was that success was surprisingly sensitive to the starting crib size. Below about eight characters of known plain text the deduction essentially never completes, and giving it twenty times the computation budget barely changes that. You can read the comments in the result generated by the execution of the code for more on this.

Going into this, I expected having thirteen swaps on the plugboard would be harder to deduce than ten. However, the number of possible plugboard configurations is the greatest at eleven cables, so thirteen is actually a smaller search space than ten. Also, when you do a trial swap and look at the output, you need to figure out if the swap improved the outcome. With thirteen swaps every letter is plugged, so a wrong guess produces visibly wrong text immediately. With six swaps, fourteen letters are left unplugged, and a wrong guess still decrypts a good deal of the message content correctly, which makes wrong guesses harder to rule out.

I should be clear that using the plain text as an oracle is a more generous scenario than the reality suffered by the actual decoders. A real codebreaker would sometimes be wrong when they deduced that they had a German word appearing in the examined text. This can lead them down a wrong path, a scenario not simulated by our test code.

Here the Germans tended to be generous, using the same phrases in many of their messages. So it is quite believable that the plugboard was cracked without too much effort. But the effort was in getting the crib, not in the deduction that followed, and the books did not emphasize this fact.

The code can be found at Enigma Plugboard Deduction Investigation. When you run the code, the main results are shown under the “Result” tab. The “Output” tab shows the results of each trial run. Since the code grew iteratively, the results start with a basic validation of the simulated Enigma machine and showing how enough crib text can forcibly deduce the plugboard settings. The output from this test code makes up most of the body of the results. The actual plugboard deduction trial runs occur towards the end of the main source code, and it is the last result of eight different tests.

In this eighth test, twelve runs initialized with random configuration are run against variations in the amount of starting crib text and the number of swaps present in the plugboard. To simulate the limited amount of time and lack of access to real computers on the part of the decoders, the trial runs track the number of “computations” done. A trial run fails if it exceeds a cap on the number of computations. Much of this is explained in the source code itself.

The two key books in question are the following.