EnigmaX is a hobby project of mine. The precision of intricate devices is fascinating, as is the story of Enigma. Whilst there were definitely aspects of the Enigma’s design which provided attack vectors, the real cracking of Enigma was more due to the human factor: lazy or hasty operators, enemy acquisition of keys and devices, the fact that the rotor wirings were never significantly changed, and so on.
As a software developer, I wondered what it’d be like to design and build, from scratch, a new software based Enigma that wasn’t limited by the same physical constraints, hence EnigmaX (X for extendable). It currently includes an rough implementation of the Enigma I, and an original variant of my own invention called Calculus.
I have been working on for a while, and stems primarily from my background as a software developer and interest in history. It’s also important to note that I am not mathematically inclined, nor am I particularly knowledgeable in cryptography.
Application Download – available for Windows 10 devices, please see the Microsoft Store: https://www.microsoft.com/enus/store/p/enigmax/9nqq6gcfgbgq
User Guide – EnigmaX User Guide – v1.0 – 5April2018
Calculus: Logical Design
One way to understand Calculus is to compare it to Enigma I, specifically in terms of the logical design of the rotor components – excluding the Plugboard (Steckerbrett) which Enigma I also used.
Enigma I – Logical Rotor Design
 Rotor components: stator (input/output), three rotors, reflector.
 The rotors are arranged into “slots”, numbered from 1 to 3 (lefttoright).
 Data flow (via the stator) is initially righttoleft (i.e. from slot 3) before passing through the reflector and then back out lefttoright.
Calculus – Logical Rotor Design
For direct comparison, the example shown here uses three rotors, although practically you can use any number of rotors that your platform will support.
 Rotor components: stator (input/output), Nrotors, stator (input/output).
 The rotors are arranged into “slots”, numbered from 1 to N (lefttoright).
 Data flow is either:
 Righttoleft, i.e. (via the right stator) slot N to slot 1, then out through the opposite stator, or
 Lefttoright, i.e. (via the left stator) slot 1 to slot N, then out through the opposite stator.
As Calculus is software the physical concepts of left and right don’t strictly apply, however conceptualizing it in this way may make it easier understand.
Calculus comes with several rotorsets: 3 x 113 rotorsets (respectively called Calculus, George and Scherbius), and a collection of 37 x 31 rotorsets called Shark.
Comparison of Enigma I to Calculus:
Enigma I  Calculus  
Supported Character Set  26 characters: AZ  94 characters: AZ az 09 (space) ! @ # $ % ^ & * ( ) _ – + = { } [ ]  \ ; : ‘ < > , . / ? ` ~ 
Available Rotors  One rotorset of: 5 rotors, and 3 reflectors  Four rotorsets:

Number of Rotors used  3 plus a reflector  N (as configured by the key) 
Rotor Stepping  Rotors only (not reflector), single direction, regular stepping.  Single direction (forwards, reverse or static), regular stepping. 
Plugboard (Steckerbrett)  Yes  No (but may be added in future versions) 
Other differences:
 A side effect of the Enigma I’s reflector is that no letter can be encrypted as itself, which weakens cryptographic strength. Calculus does not have this limitation.
 Calculus is designed so that data flow through all the rotors, in one direction. The operator can choose which direction to pass the data, either righttoleft or lefttoright. This means that to successfully decrypt data the operator must the opposite direction to that which was used to encrypt it.
 Rotor reuse – there are two ways of looking at this: what is supported by the devices, and what is supported by procedure. Enigma I could reuse the same rotor design (wiring) more than once, but this was not the intended procedure. Calculus can reuse individual rotors as many times as desired as there is no physical limitation.
Key Size
I started trying to work this out myself, but I’m not a mathswiz by any means. The picture below gives you an idea of the factors involved, but in the end I asked the Crypto Stack Exchange community and got some really helpful input. See: https://crypto.stackexchange.com/questions/50444/howtocalculatethekeysizeofmycryptographicsystem
Operation
This is the main Calculus screen where you can encipher and decipher text:
Operation: Key Setting
Coming up with an efficient way to set keys was an interesting challenge.
From a cryptographic perspective it’s critical to get this right – a lot of the things that lead to the original Enigma being cracked came from flaws and mistakes in the operation of Enigma – not just the cryptographic strength of the device itself. But before we can get to this point I needed to come up with a practical way of just getting started – being able to create keys and keyparts.
Here’s the key creation screen, where you can define a key, including the five cryptographically relevant settings, which are:
 Rotor Selection
 Rotor Rotation Index
 Rotor Rotation Direction
 RotorSet (optional)
 Encipherment Direction (optional)
Creating a key that uses 250 rotors (or more) is bit of a challenge. I got around this (for now) by creating a simple algorithm that generates a sequence of random numbers – which a user can always modify.
The algorithm, RandomX, simply leverages the random number generation features of .Net, with some simple controls for limiting the number of items and maxvalue.
The keys need not be specifically tied to a specific rotorset. As rotorsets will have different numbers of rotors, and potentially support different charactersets of different lengths, the algorithm need to consistently handle inputs that fall outside the range of the arrays – such as when wanting to select 100 consecutive rotors, from a 113rotor rotorset, starting at index 100.
Calculus gets around this by conceptualizing the array as circular – rather than as a line with two end points. For example, assuming an array of 10 (and remembering that the valid indexes are therefore 09), a value of 10 would be index 0; a value of 33 would be index 4; and index of 3 would be index 7. It can also safely handle variables bigger than the size of the array – e.g. a rotor selection increment of 197 against a rotorset of 113 (giving us rotors 1, 85, 56, 27, 111, 82 and so on). This means that Calculus can consistently handle configuration values against any conceivable rotor and rotorset.
The RandomX algorithm is of course relatively simplistic and its predictability through regularity is no doubt a cryptographic weakness, but it’s an early example of the types of key generation approaches that Calculus could support.
RotorSet Selection
At runtime, rotors are pulled from whatever rotor collection the operator has chosen – which currently would be one of the three 113rotor rotorsets, or some combination of the the 37 x 31rotor rotorsets in Shark.
When using the Shark rotor collection, the operator can use all 37 rotorsets (in their default order), or, select any number of rotorsets in any order by specifying their zerobased indexes, separated by spaces, e.g. 0, 30, 5, 20, 10, or 17, 10, 17, 5, 30, 14, 27. this means that the same algorithm value can select different rotors, and the rotorset selection becomes part of the key.
Other Extensions
Because Calculus is software based it’s also possible to implement controls that help mitigate some of the operator errors that led to Enigma being broken:
 Automatically adding padding (random characters to the plaintext before encryption), and optionally the automatically removing such padding.
 Denying the reuse of certain key settings.
 Denying the reencryption of the same / similar message.
And for fun: taking every nLetter (i.e. every second letter) so that you had two streams of text, reversing one, then recombining before encryption through the rotors – such a process would help hide cribs.