Part 2: Architecture of the Enigma Machine
26/12/2009
One death in particular was a particular tragedy. Alan Turing, a leading codebreaker at Bletchley, who gave his name to one of the key principles of computer theory, was a homosexual, in a time where the official response to this was bigotry and persecution. After working tirelessly throughout the war to defend his country, he was afterwards hounded to death by a government which would no longer tolerate what it thought of as an aberration. Alan Turing, father of modern computer science, took his own life in 1954 at the age of 41, after having been prosecuted for homosexuality and having all security clearances revoked.
Due in large part (if not entirely) to an online campaign, Alan Turing posthumously received an official apology from Prime Minister Gordon Brown in September 2009.
Bletchley Park and the National Museum of Computing are both desperately underfunded and under-appreciated volunteer-run institutions, with many of the old "huts" where the codes were broken still in a critical state of repair. I hope if I can send a few pounds and a few people their way, I'll have done something to help support one of the most important sites in both Military and Computing history. For more information on visits, events and donations, visit http://www.bletchleypark.org.uk/
Architecture of the Enigma system
The Enigma hardware was an electromechanical system, weighing about 12 kilos and measuring about 30 cm square by 15 cm deep. It was built in a number of increasingly complex formats from the late 1920s and throughout the Second World War, was highly configurable, and would always be operated by one, or a pair of, trained operators.
In appearance, it looked more like a typewriter than anything else, but instead of striking keys and a roller for paper, it had a set of three or four vertically mounted rotors and a lightboard displaying the output for each letter.
The Enigma was a fully stateless machine that operated letter-by-letter, with the output for each input character depending entirely the on rotor position and configuration that applied when that letter was input.
The vital elements of the Enigma were:
Keyboard
This provided the system input, one character at a time. The keyboard was of 26 letters in the QWERTZP layout; there were no numbers, spaces, punctuation or case shift keys.
Rotors and Rotor Slots
The electrical signals from the keyboard pass through a series of rotors, which rest in three or four rotor slots. The order of the rotors varied as part of the system configuration, and later versions of the system had up to 8 rotors to choose from.
The rotors were wired internally in a deliberately complex fashion, such that any of the 26 positions on one side of the rotor would correspond to any other position on the other side.
Each rotor would also had a peg on its left hand side which would, once per revolution, cause the next-left rotor to move up one position. The rightmost rotor would move on every keypress.
Reflector
Once it had passed through the rotors from right-to-left, the signal would encounter a reflector, similar to a rotor, but one-sided such that any of the 26 inputs would route to another input, thus effectively causing the signal to do a U-turn and route back via a different path through the rotors.
Since the signal had to leave the reflector (and therefore pass back though the rotors) on a different path from the one it entered on, no input letter could ever be encrypted as itself. This will be important later…
Lightboard
The lightboard was a set of 26 bulbs in the same layout as the keyboard. The electrical signal back coming out of the rotors would cause one of these bulbs to light up, depending on the exit position of the signal on the right-hand rotor.
Plugboard
Most of the later models of Enigma had a panel of sockets on the front, through which signal paths corresponding to particular letters could be swapped in pairs, to add extra complexity to that provided by the rotors. I’ll cover this in more depth later as we’ll be ignoring it in our initial development.
Operator
It might seem odd to represent the operator as part of the system, but there are a few reasons that we should consider him:
The Enigma machines had no internal memory . Only the operator had the faintest idea what stage of a message had been reached.
The operator had to convert a full natural language string message into a limited character set sequence of letters – therefore he was doing some essential part of the signal processing.
He was the weak link in the system. Most Enigma keys were cracked as a result of operator error rather than brute-force mathematics.
Object representation of the architecture
The “box”
To allow us to use the code we’ll develop flexibly, we want a single object that can act as a black box, to take an input character and give us the encrypted output. In code terms, presuming we’ve set the enigma up with the right rotors and positions, we want to call:
(You’ll notice I can be very verbose in my function names. It’s a tendency from Objective C coding which I find very useful).
We’ll call this our Enigma_Machine class, and it’ll be the main external interface to our code.
Note that the encryption function is character-based, not string based. This is how the hardware worked, and I want to stick closely to that model.
The Operator
Despite the fact that our machine is character based, I don’t want to have to manually convert it (to reduce it to letters only) or split it into characters. So, at some point, I’ll create a class to do that for us, which I’ll call Enigma_Signaller. I’m avoiding the word operator in the class name, as it has a very specific meaning in development and I don’t want to cause confusion.
Anyway, we don’t need this yet. We need to concentrate on our character-level simulator first.
Keyboard
I’m not going to simulate this, as it’s only a system input that does no conversion. We can feed inputs to, and read outputs from, either the whole system via the Enigma_Machine object, or the individual elements.
Lightboard
Likewise, we don’t need to simulate this.
Rotors
This is where it gets interesting. The rotor is the basic unit of encryption in the Enigma, and even one can be used, one-way, to encrypt a message – and so we can model it as a class Enigma_Rotor with the function getOutputCharacterForInputCharacter($char).
In fact, all our encryption elements have a function of similar format – so we’ll create an interface called Enigma_Encryptor_Interface that encapsulates this:
A single-rotor encryption is a genuine encryption method, but a trivially simple one. The strength of the Enigma’s encryption comes from multiple rotors, of unknown type, in unknown orders and positions.
Rotor Slots
The behaviour of a rotor in a slot depends which position it’s in. If it’s in the A position (ie, A showing in the rotor slot’s window) then its contacts line up line up 1-1 with the same contacts on the rotor. If the rotor is advanced one position to “B”, then inputting an A to the slot will send a signal to the rotor’s B input, across the internal wiring the in the rotor to (let’s say) the L output contact, which will be then connect to the “M” output contact of the slot.
So, we need something in out code that will model the position of a rotor in a slot. We can simply call this class Enigma_RotorSlot , and it too can provide the Enigma_Encryptor_Interface; to use it we’ll need to insert an Enigma_Rotor and specify its position.
Reflector
Yes, it’s another Enigma_Encryptor_Interface – it takes in a character and outputs a different one – this will be another very simple class.
Plugboard
Finally, the plugboard. Yet again this is an Enigma_Encryptor_Interface, but its behaviour will depend entirely on a configuration, corresponding to the connections to be made, that we’ll give it before use.
Assembly
So how do we put all of this code together? Well, initially we won’t, because we’ll test first the rotors alone, then the slots, and so on. But once we’ve done that, we’ll give the class Enigma_Machine class the responsibility for passing the signals between blocks, as its wiring would in the hardware version.
You might well think that the above is a bit vague. Well, it is, but that’s deliberate, mainly because I don’t want to get bogged down in detail at this stage. All will become (hopefully) clear as we build each element in the following posts.
All content copyright Richard George (richard@phase.org), 2009-2010
Navigation
Contact
Sponsored links to recommended books: