Enigma-E : Encryption Inspired by History
328 Views, 4 Favorites, 0 Comments
Enigma-E : Encryption Inspired by History
Who doesn't know WW2, but more interesting in knowing the brilliance of electrical engineering at that time, if you have guessed it right yes, I am talking about the Enigma which was considered one of the most unbreakable code encrypting methodologies of all time, but it came with a very sneaky flaw, symmetry; beautiful to see but as worse as nightmare for the machine. That's why bringing it back to life in the modern age, removing the component (aka, reflector) which caused this flaw and still maintaining the complexity would be the goal of my project, making it implemented by C++.
Supplies
For the software part,
Any cpp compiler should be working great, but I chose to use VS Code for the purpose.
Link for the download- Download Visual Studio Code - Mac, Linux, Windows
Online compiler- C++ Online Compiler (JDoodle)
Furthermore, I would like to be thankful of and provide courtesy to Jared Owen for his informational videos on YT which helped in visualization of the working part.
https://youtu.be/ybkkiGtJmkM?si=UKomE-syqhy6xeNE
Understanding the Hardware & Flaw of Enigma
Out of the whole machine being depicted, the parts which actually contribute to the logic (main part of our project) are :-
- Plugboard
- Rotors
- Reflector
The bulbs were used for output, the keys for the input; in our case we would be using the terminal.
1) PLUGBOARD : for swapping of one letter with the other (in the image illustrated by the interconnected letters by wires)
we would be doing so by maintaining a char/string array (both are fine), representing the pairs.
2) ROTORS : for dynamically switching one alphabet to other (in the image illustrated by the visible gears)
we would be again using a string/char array again, to be noted that in the original device it had 3 rotors which used to be updated every character, every 26 characters and every 676 characters encrypted respectively, however our design is subject to removal of reflector so it brings is up to 6 rotors and the pattern of updating continues; 1, 26, 676, 17576, 456976 and 11881376 characters respectively
3) REFLECTOR : after the character typed was once processed by the 3 rotors it would send it back to them at some other letter; eg, A would be changed to H etc. (in the image illustrated by the metallic cylinder on the top left)
*** NOT to be confused with the plugboard which had 10 pairs of alphabets (the number chosen optimally for maximum permutations and combinations); however, this has like all things paired up!
This is where it gets interesting, we can see that we have some letter entering but we would never have the same letter leaving, and for one cycle of the enigma we would be having the rotors static so since the wiring is already fixed for the input so even the output of the rotors won't be same as the input, and plugboard which is meant to be static for every encryption session would also return some different letter than the input finally !!
Thus, indicating the fact of never being able to map to itself! Which can be used to eliminate the guesses leading up to the same input.
ONE CYCLE OF ENIGMA MACHINE :
char c as typed (i/p via keyboard and o/p via light bulbs)
↓
either switched by the plugboard to char d or kept c
↓
goes through all three rotors.... to become char e
↓
reflector changes to compulsorily diff. char f
↓
EVERYTHING IN REVERSE (from rotors onwards)
Removing the Flaw and Knowing the Required Components
Since, now we know reflector isn't something desirable in our project, we would be removing it to keep it simple, but that reduces the further complexity added by the reverse cycle of rotors, so we rather compensate it by adding three more rotors to the circuit which makes it better than the original machine itself when it comes to permutations because now we can have even more distinct mappings possible via individual rotor in the new 3, which were previously being borrowed down by the three present originally. So, each rotor becomes a different puzzle to solve.
Now, we can conclusively say that we only need to design/handle the interface for:
- The i/o via the terminal, standardizing the input to upper case and for the output, bringing it back to the lowercase alphabets (vaguely, can be said destandardizer).
- The plugboard entries before every encryption/decryption session would be taken taking in care that no letter is paired twice in the code and only letters are allowed in the pairing
- Rotors would be the ones which would be the dynamic components and updated as discussed before keeping the counter for the number of characters encrypted/decrypted till then and changing the indices of accessing the array which would be containing the switches modularly mod26.
The Plugboard Function
The sole objective to be fulfilled is to get 10 pairs of letters from the user taking into account that the user might possibly forget at the last few pairs what was paired initially, and as a typing mistake might also put in some numbers and so.
Primarily we would be using string arrays as data structure for storing the pairs, which can be possibly optimized via using unordered_(map/set), and looking forwards towards entering the first pair as a successful event we would be defining a Boolean to keep a check on that, and keep in repeating via a while loop which would be true only when;
- firstly, we want letters as the input, so we check if the input got is a letter or no by checking the length of the string and then the ascii values lie withing 65-90 or 97-112! else we output invalid input
- we have two distinct chars or else we output saying different letters are required
- lastly, we check if the two letters got are already present or no, if either of them is, then we output saying we want distinctive pairs else we are good to go adding it to the array.
At the end we just setup the function required for shifting the characters which would be mapped by the array as illustrated by the plugboardShift function.
The Rotor Function
Here, the first noticeable thing to see is that the encryption and decryption modules would be reversed and the rotors would be in the same data structure as the plugboard's pairs but in this case, they would be predefined as in the original enigma machine the rotors wiring couldn't be manipulated but their positions is something which we would be updating via the counter by adding it to the index being accessed mod26!
Keeping it short the letter shifting would be in the same manner as the plugboard shifting, here just the array's subarrays would be mapping the letters from one to another.
***NOTE that the letters which can be taken as input would be upper case only, however while taking input we don't specify anything like that to user to reduce complexity and also keep the output in lower case for more familiar reading
Miscellaneous Functions
Here is where we add or subtract the difference between lowercase and uppercase alphabet in the standardizer (to uppercase!) and destandardizer (to lowercase!) as ascii values for getting the input and output in useful form respectively.
EnigmaE at Maximum-output
You can go through the video for showing its working, and for more info related to the code and implementation you can also refer to the GitHub repository attached!