From ed7ab8b92789111139fb98d23a9bf2249311b6a7 Mon Sep 17 00:00:00 2001 From: n1474335 Date: Thu, 14 Mar 2019 12:01:55 +0000 Subject: [PATCH] Created Enigma, the Bombe, and Typex (markdown) --- Enigma,-the-Bombe,-and-Typex.md | 350 ++++++++++++++++++++++++++++++++ 1 file changed, 350 insertions(+) create mode 100644 Enigma,-the-Bombe,-and-Typex.md diff --git a/Enigma,-the-Bombe,-and-Typex.md b/Enigma,-the-Bombe,-and-Typex.md new file mode 100644 index 0000000..81c124d --- /dev/null +++ b/Enigma,-the-Bombe,-and-Typex.md @@ -0,0 +1,350 @@ +## How to guides + +### How to encrypt/decrypt with Enigma + +We'll start with a step-by-step guide to decrypting a known message. You can see the result of +these steps in CyberChef +[here](https://gchq.github.io/CyberChef/#recipe=Enigma('3-rotor','','','','BDFHJLCPRTXVZNYEIWGAKMUSQO + + +In this case, if we extend our crib by a single character to `HELLO CYBER CHEFU`, we get a loop in +the menu (that `U` maps to a `Y` in the ciphertext, the `Y` in the second cipher block maps to +`A`, the `A` in the third ciphertext block maps to `E`, and the `E` in the second crib block maps +back to `U`). We immediately get a manageable number of results. You can see this +[here](https://gchq.github.io/CyberChef/#recipe=Bombe('3-rotor','LEYJVCNIXWPBQMDRTAKZGFUHOS','BDFHJLCPRTXVZNYEIWGAKMUSQOletter conversions to produce ciphertext from plaintext. It +is symmetric, such that the same series of operations on the ciphertext recovers the original +plaintext. + +The bulk of the conversions are implemented in "rotors", which are just an arbitrary mapping from +the letters A-Z to the same letters in a different order. Additionally, to enforce the symmetry, a +reflector is used, which is a symmetric paired mapping of letters (that is, if a given reflector +maps X to Y, the converse is also true). These are combined such that a letter is mapped through +three different rotors, the reflector, and then back through the same three rotors in reverse. + +To avoid Enigma being a simple [Caesar cipher](https://wikipedia.org/wiki/Caesar_cipher), the +rotors rotate (or "step") between enciphering letters, changing the effective mappings. The right +rotor steps on every letter, and additionally defines a letter (or +later, letters) at which the adjacent (middle) rotor will be stepped. Likewise, the middle rotor +defines a point at which the left rotor steps. (A mechanical issue known as the +double-stepping anomaly means that the middle rotor actually steps twice when the left hand rotor +steps.) + +The German military Enigma adds a plugboard, which is a configurable pair mapping of letters +(similar to the reflector, but not requiring that every letter is exchanged) applied before the +first rotor (and thus also after passing through all the rotors and the reflector). + +It also adds a ring setting, which allows the stepping point to be adjusted. + +Later in the war, the Naval Enigma added a fourth rotor. This rotor does not step during +operation. (The fourth rotor is thinner than the others, and fits alongside a thin reflector, +meaning this rotor is not interchangeable with the others on a real Enigma.) + +There were a number of other variants and additions to Enigma which are not currently supported +here, as well as different Enigma networks using the same basic hardware but different rotors +(which are supported by supplying your own rotor configurations). + +### How Typex works + +Typex is a clone of Enigma, with a few changes implemented to improve security. It uses five rotors +rather than three, and the _rightmost_ two are static. Each rotor has more stepping points. +Additionally, the rotor design is slightly different: the wiring for each rotor is in a removable +core, which sits in a rotor housing that has the ring setting and stepping notches. This means each +rotor has the same stepping points, and the rotor cores can be inserted backwards, effectively +doubling the number of rotor choices. + +Later models (from the Mark 22, which is the variant we simulate here) added two plugboards: an +input plugboard, which allowed arbitrary letter mappings +(rather than just pair switches) and thus functioned similarly to a configurable extra static +rotor, and a reflector plugboard, which allowed rewiring the reflector. + +### How the Bombe works + +The Bombe is a mechanism for efficiently testing and discarding possible rotor positions, given +some ciphertext and known plaintext. It exploits the symmetry of Enigma and the reciprocal +(pairwise) nature of the plugboard to do this regardless of the plugboard settings. Effectively, +the machine makes a series of guesses about the rotor positions and plugboard settings and for +each guess it checks to see if there are any contradictions (e.g. if it finds that, with its +guessed settings, the letter `A` would need to be connected to both `B` and `C` on the plugboard, +that's impossible, and these settings cannot be right). This is implemented via careful connection +of electrical wires through a group of simulated Enigma machines. + +A full explanation of the Bombe's operation is beyond the scope of this document - you can read +the source code, and the authors also recommend Graham Ellsbury's +[Bombe explanation](http://www.ellsbury.com/bombe1.htm), which is very clearly diagrammed. + +## Implementation in CyberChef + +### Enigma/Typex + +Enigma and Typex were implemented from documentation of their functionality. + +Enigma rotor and reflector settings are from GCHQ's documentation of known Enigma wirings. We +currently simulate all basic versions of the German Service Enigma; most other versions should be +possible by manually entering the rotor wirings. There are a few models of Enigma, or attachments +for the Service Enigma, which we don't currently simulate. The operation was tested against some +of GCHQ's working examples of Enigma machines. Output should be letter-for-letter identical to a +real German Service Enigma. Note that some Enigma models used numbered rather than lettered +rotors - we've chosen to stick with the easier-to-use lettered rotors. + +There were a number of different Typex versions over the years. We implement the Mark 22, which is +backwards compatible with some (but not completely with all, as some early variants supported case +sensitivity) older Typex models. GCHQ also has a partially working Mark 22 Typex. This was used to +test the plugboards and mechanics of the machine. Typex rotor settings were changed regularly, and +none have ever been published, so a test against real rotors was not possible. An example set of +rotors have been randomly generated for use in the Typex operation. Some additional information on +the internal functionality was provided by the Bombe Rebuild Project. + +### The Bombe + +The Bombe was likewise implemented on the basis of documentation of the attack and the machine. The +Bombe Rebuild Project at the National Museum of Computing answered a number of technical questions +about the machine and its operating procedures, and helped test our results against their working +hardware Bombe, for which the authors would like to extend our thanks. + +Constructing menus from cribs in a manner that most efficiently used the Bombe hardware was another +difficult step of operating the real Bombes. We have chosen to generate the menu automatically from +the provided crib, ignore some hardware constraints of the real Bombe (e.g. making best use of the +number of available Enigmas in the Bombe hardware; we simply simulate as many as are necessary), +and accept that occasionally the menu selected automatically may not always be the optimal choice. +This should be rare, and we felt that manual menu creation would be hard to build an interface for, +and would add extra barriers to users experimenting with the Bombe. + +The output of the real Bombe is optimised for manual verification using the checking machine, and +additionally has some quirks (the rotor wirings are rotated by, depending on the rotor, between one +and three steps compared to the Enigma rotors). Therefore, the output given is the _ring position_, +and a correction depending on the rotor needs to be applied to the _initial value_, setting it to +`W` for rotor V, `X` for rotor IV, and `Y` for all other rotors. We felt that this would require +too much explanation in CyberChef, so the output of CyberChef's Bombe operation is the initial +value for each rotor, with the ring positions set to `A`, required to decrypt the ciphertext starting +at the beginning of the crib. The actual stops are the same. This would not have caused problems at +Bletchley Park, as operators working with the Bombe would never have dealt with a real or simulated +Enigma, and vice versa. + +By default the checking machine is run automatically and stops which fail silently discarded. This +can be disabled in the operation configuration, which will cause it to output all stops from the +actual Bombe hardware instead. (In this case you only get one stecker pair, rather than the set +identified by the checking machine.) + +#### Optimisation + +A three-rotor Bombe run (which tests 17,576 rotor positions and takes about 15-20 minutes on +original Turing Bombe hardware) completes in about a fifth of a second in our tests. A four-rotor +Bombe run takes about 5 seconds to try all 456,976 states. This also took about 20 minutes on the +four-rotor US Navy Bombe (which rotates about 30 times faster than the Turing Bombe!). CyberChef +operations run single-threaded in browser JavaScript. + +We have tried to remain fairly faithful to the implementation of the real Bombe, rather than +a from-scratch implementation of the underlying attack. There is one small deviation from "correct" +behaviour: the real Bombe spins the slow rotor on a real Enigma fastest. We instead spin the fast +rotor on an Enigma fastest. This means that all the other rotors in the entire Bombe are in the +same state for the 26 steps of the fast rotor and then step forward: this means we can compute +the 13 possible routes through the lower two/three rotors and reflector (symmetry means there are +only 13 routes) once every 26 ticks and then save them. This does not affect where the machine stops, +but it does affect the order in which those stops are generated. + +The fast rotors repeat each others' states: in the 26 steps of the fast rotor between steps of the +middle rotor, each of the scramblers in the complete Bombe will occupy each state once. This means +we can once again store each state when we hit them and reuse them when the other scramblers rotate +through the same states. + +Note also that it is not necessary to complete the energisation of all wires: as soon as 26 wires +in the test register are lit, the state is invalid and processing can be aborted. + +The above simplifications reduce the runtime of the simulation by an order of magnitude. + +If you have a large attack to run on a multiprocessor system - for example, the complete M4 Naval +Enigma, which features 1344 possible choices of rotor and reflector configuration, each of which +takes about 5 seconds - you can open multiple CyberChef tabs and have each run a subset of the +work. For example, on a system with four or more processors, open four tabs with identical Multiple +Bombe recipes, and set each tab to a different combination of 4th rotor and reflector (as there are +two options for each). Leave the full set of eight primary rotors in each tab. This should complete +the entire run in about half an hour on a sufficiently powerful system. \ No newline at end of file