Enigma-X 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 Enigma-X (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/en-us/store/p/enigma-x/9nqq6gcfgbgq
User Guide – Enigma-X User Guide – v1.2 – 29-October-2018
Previous versions:
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 (left-to-right).
- Data flow (via the stator) is initially right-to-left (i.e. from slot 3) before passing through the reflector and then back out left-to-right.
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), N-rotors, stator (input/output).
- The rotors are arranged into “slots”, numbered from 1 to N (left-to-right).
- Data flow is either:
- Right-to-left, i.e. (via the right stator) slot N to slot 1, then out through the opposite stator, or
- Left-to-right, 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 rotor-sets: 3 x 113 rotor-sets (respectively called Calculus, George and Scherbius), and a collection of 37 x 31 rotor-sets called Shark.
Comparison of Enigma I to Calculus:
| Enigma I | Calculus | |
| Supported Character Set | 26 characters: A-Z | 94 characters: A-Z a-z 0-9 (space) ! @ # $ % ^ & * ( ) _ – + = { } [ ] | \ ; : ‘ < > , . / ? ` ~ |
| Available Rotors | One rotor-set of: 5 rotors, and 3 reflectors | Four rotor-sets:
|
| 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 right-to-left or left-to-right. 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 maths-wiz 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/how-to-calculate-the-key-size-of-my-cryptographic-system
Operation
Note: the following content as per v1.1, which is sufficiently similar to v1.2, se the user guide for precise information.
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 key-parts.
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
- Rotor-Set (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 max-value.
The keys need not be specifically tied to a specific rotor-set. As rotor-sets will have different numbers of rotors, and potentially support different character-sets 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 113-rotor rotor-set, 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 0-9), 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 rotor-set 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 rotor-set.
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.
Rotor-Set Selection
At runtime, rotors are pulled from whatever rotor collection the operator has chosen – which currently would be one of the three 113-rotor rotor-sets, or some combination of the the 37 x 31-rotor rotor-sets in Shark.
When using the Shark rotor collection, the operator can use all 37 rotor-sets (in their default order), or, select any number of rotor-sets in any order by specifying their zero-based 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 rotor-set 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 plain-text before encryption), and optionally the automatically removing such padding.
- Denying the re-use of certain key settings.
- Denying the re-encryption of the same / similar message.
And for fun: taking every n-Letter (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.
Singularity
Singularity is a One-Time Tape implementation.
One of the cool features of Singularity is that you can use images to generate key-tapes: either by loading an image stored on your system or accessing one via URL.
One of the practical problems with OTT’s is how to securely share key-tapes, although the idea of accessing images from the internet will not be risk free, it does provide a potential way of sharing the largest critical part of the key – requiring a much smaller amount of information to be shared via other means.
Peruse Muse Infuse 