[BUG] Module May not Be M4/Enigma Compliant

[ZAdamMac]

Describe the bug User Michael Zimmermann michael_zimmermann@gmx.de reported that he was having trouble decrypting a known-plaintext message generated on an original Enigma M4. This message was originally produced during the war and is fully decryptable using other emulation platforms.

To Reproduce Steps to reproduce the behavior:

1. Create an enigma machine instance with the appropriate settings (detailed below)
2. Set the wheelpack correctly.
3. Parse the encrypted message.
4. If reproducing, the wrong plaintext is sent.

Expected behavior A new key should be generated and written to configuration, and that key should be used throughout the rest of the backup process.

Log/Console Output Where possible, add the output of the Logs or Console when the problem occurs.

Desktop (please complete the following information):

• Not obtained. There's nothing platform-specific in this machine so... shouldn't matter.

Additional context Add any other context about the problem here.

Reflector: C Greek: B Wheels: 568 Wheel positions: YOSZ Rings: AAEL Plugs: AE BF CM DQ HU JN LX PR SZ VW

Message indicator groups: DUHF TETO

Ciphertext (without indicator groups): LANOTCTOUARBBFPMHPHGCZXTDYGAHGUFXGEWKBLKGJWLQXXTGPJJAVTOYJFGSLPPQIHZFXOEBWIIEKFZLCLOAQJULJOYHSSMBBGWHZANVOIIPYRBRTDJQDJJOQKCXWDNBBTYVXLYTAPGVEATXSONPNYNQFUDBBHHVWEPYEYDOHNLXKZDNWRHDUWUJUMWWVIIWZXIVIUQDRHYMNCYEFUAPNHOTKHKGDNPSAKNUAGHJZSMJBMHVTREQEDGXHLZWIFUSKDQVELNMIMITHBHDBWVHDFYHJOQIHORTDJDBWXEMEAYXGYQXOHFDMYUXXNOJAZRSGHPLWMLRECWWUTLRTTVLBHYOORGLGOWUXNXHMHYFAACQEKTHSJW

Plaintext:

KRKRALLEXXFOLGENDESISTSOFORTBEKANNTZUGEBENXXICHHABEFOLGENDENBEFEHLERHALTENXXJANSTERLEDESBISHERIGXNREICHSMARSCHALLSJGOERINGJSETZTDERFUEHRERSIEYHVRRGRZSSADMIRALYALSSEINENNACHFOLGEREINXSCHRIFTLSCHEVOLLMACHTUNTERWEGSXABSOFORTSOLLENSIESAEMTLICHEMASSNAHMENVERFUEGENYDIESICHAUSDERGEGENWAERTIGENLAGEERGEBENXGEZXREICHSLEITEIKKTULPEKKJBORMANNJXXOBXDXMMMDURNHFKSTXKOMXADMXUUUBOOIEXKP

[ZAdamMac]

We've eliminated configuration issues. However, Michael found a mention in an old article that the Engima steps prior to encoding. This is the opposite of how my system steps (stepping after encoding).

It should be relatively trivial to change this behaviour and test.

[ZAdamMac]

It's worthwhile noting as well that the M4 used "UKW C Thin" from the default catalogue, not the normal C reflector.

[ZAdamMac]

I had a chance to review some other similar implementations in source and I can confirm, absolutely, that the wheels need to step first.

This still does not directly solve the issue, so I now need to determine if the wheels are stepping correctly. Gross.

[ZAdamMac]

Recent changes merged to master resolved this issue. Full blog post on the "why" forthcoming, but in general, the following changes were made:

• Rotor stepping process now correctly takes place prior to encoding a character (true Enigma rotors rotated prior to the signal passing through from keyboard to lamp.
• Rotor stepping now correctly models the behaviour of the M3 and M4 ratchet mechanism, including the "double stepping" behaviour.
• A whole new way of modelling the position of the rotor, by modelling two "faces" on either side of it that remain stationary relative to the rotor, is used. All signals are translated from this netural state to the actual rotor entry pins, and then put back in that netural state based on the actual rotor exit pins.
• Ringstellung offset adjustment was similarly overhauled entirely.