Chapter 3: Project specification, or, How does the Enigma work, anyway?
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:
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.
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…
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.
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.
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
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: 1 $outChar=$myEnigma->getOutputCharacterForInputCharacter($inChar);
(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.
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 the 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.
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.
Likewise, we don’t need to simulate this to create and test the core functionality.
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 an Enigma Rotor class with the function getOutputCharacterForInputCharacter($char).
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.
It turns out that all our encryption elements have a function of similar format – so we’ll define an Enigma Encryptor Interface that guarantee the presence of this function.
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’ll create an Enigma Rotor Slot class which will also provide the Enigma Encryptor Interface; to use it we’ll need to insert an Enigma Rotor and specify its position.
Another Enigma Encryptor Interface – it takes in a character and outputs a different one – this will be another very simple class.
Finally, the plugboard. Yet again this displays the 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.
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 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 chapters.