Test-driven development of an Enigma Simulator

• Part 1: Developing an Enigma Simulator with PHPUnit     26/12/2009

  Back in August this year, I finally got around to visiting Bletchley Park near Milton Keynes, somewhere that I'd been meaning to visit for years but never quite got around to. It proved to be a fascinating day out, and I've since developed a real interest in the Park and its history. For those unfamiliar with the place, Bletchley Park was the site of the British Government Code and Cipher school in the Second World War, the place where German and Japanese secret codes were broken, giving the Allies vital information to help shorten and finally win the war...

• Part 2: Architecture of the Enigma Machine     26/12/2009

  This is part 2 of my TDD Deciphered series, written to increase interest in Test-Driven Development, to encourage more people to visit Bletchley Park, and to help give a bit more credit to those who worked there during the war. The work of the codebreakers of Bletchley Park was classified “Most Secret” not only throughout the Second World War, but right through the Cold War almost to the turn of the 21st century...

• Part 3: Toolchain and Project Setup     02/03/2010

  I'll be using a number of freely available tools to help develop this project: - PHP 5.x as the development language (Install Guide). - PHPUnit 3.x for testing (Download / Install). - Subversion for version control (Download / Install). - Eclipse PDT as my editor. (Download / Install I'll be writing the code according to Zend Framework coding standards as I find these provide the best interoperability, although I won't be using any of the framework in the main development. Project Structure The basic directory structure will be: / /library /library/Enigma /tests /test...

• Part 4: First test     02/03/2010

  As promised, it's time to start coding. I've set up a repository with the directory structure mentioned in the previous post at: http://services.phase.org/svn/tdd-enigma/trunk ...

• Part 5: Why test first?     30/12/2009

  For most of us, testing is something done to either check a system's functionality or verify a hypothesis. Software or site testing generally follows the development - either we build a module and check it does what we expected, or we go through the whole site and then say "that seems to work"...

• Part 6: Setting the Rotor     02/01/2010

  So far we've made one very simple comment about the Rotor class - that it's an encryptor - but we've made no attempt to actually model the real rotor's behaviour. In order to do that, we need to more closely specify the rotor's properties and capabilities: - A rotor has 26 inputs on its right hand side, and 26 outputs on its left hand side...

• Part 7: Handling the Ring Offset     09/01/2010

  We noted in the previous installment that a rotor's behaviour depended on its core mapping, and on the rotation of that core with regards to the wheel, specfied either alphabetically or numerically. We didn't say, however, what that offset actually meant...

• Part 8: Putting the Rotors in place     16/01/2010

  In the last installment, we got the rotors working. Now, we'll work on the framework they sit in, starting with the rotor slots As we did with the Rotors themselves, we need to analyse the behaviour we need from the slots: - Any time a letter is sent to the right-hand rotor in slot 1, it will be turned over by one position before the electrical signal is sent. - If the rotor in a slot is in its pre-turnover position, and it turns over, it will cause the rotor to its left to turn over before the electrical signal is passed. - The position of the rotor in the slot must also be taken int...

• Part 9: Implementing the real rotors     16/01/2010

  We can now go on to populate the first five rotors that were provided with the German Military Enigma Machines, rotors I through V, as classes Enigma_Rotor_I to Enigma_Rotor_V. That's a lot of very fragile data, of course, and we need a good way to check it. How can we do this? There are two risks: 1) We get the data completely wrong; ie, we populate data for the wrong wheel. This is reasonably unlikely, and we can visually check it quite easily. 2) We make a minor error in copying the rotor specification into our class; for example we miss an input/output pair, or get the wrong o...

• Part 10: Assembling the Machine     01/02/2010

  There are still two electrical elements of the system we've not simulated; the reflector and the plugboard. Both of these, as mentioned above, will implement Enigma_Encryptor_Interface. The reflector is extremely simple, and we can implement it in a simpler version of the technique we used for the wheels: Enigma_Reflector_Abstract sets up the basics and implements the required getOutputCharacterForInputCharacter function, and the concrete implementations Enigma_Reflector_B and Enigma_Reflector_C will include the mapping data, which we can again find at http://www.codesandciphers.org.uk...

• Part 11: The final pieces, and a real decrypt     08/02/2010

  As mentioned previously, there was a large family of Enigma machines. In previous installments, we've put together most of the elements of the original machines, of the commercial types released between 1923 and 1927...

• Part 12: Spare Parts     13/02/2010

  In the last installment, we managed to decode a genuine wartime message, but to do so we had to draw in new wheels and a reflector which we didn't then take the time to test. We'll do that housekeeping now, and include the code for the remaining wheels and reflectors. However, let's first look at the reason those wheels existed...