Incorrect output with certain settings about python-enigma

[ZAdamMac]

Highly improbable you're doing it wrong, considering the source; I'm an idiot, and it wouldn't be the first time there was a gap in the logic.

Just for my own clarity, are you using the latest version from pypi?

[ZAdamMac]

(Intended as a note to myself more than anything)

• Validated that the wheel settings in my catalog.json match what the example is also using for the same wheels.

• Validated the flow the main codebase goes through to ensure that we haven't missed a step in encryption.

• Validated notch positions, provided:

  • python-enigma expects the notch position to be the state the wheel is in before moving that would indicate a step for the neighbouring wheel, and;
  • chef example expects the notch position to be the state the wheel is in after moving that would indicate a step for the neighbouring wheel (if this is not the case, the chef example appears to be using the wrong notch positions)

• Validated that the issue isn't the stator:

  • Chef stator not given, but;
  • Neither the military or civilian stators are used by chef; possible the statoring step is simply skipped, but even then, doesn't quite explain the discrepency.

  I need to come up with a good way to diff the performance of the pair. Since a previous issue was raised using historical example messages, I suspect we could start there.

[ZAdamMac]

I guess just as a small update, the reflectors are ALSO set up correctly, which pretty much rules out the catalogue.json as being a culprit (I was hoping; it would have been the easiest fix.

I suspect that by making this M4 compliant in #4 I may have made the M3 compliance broken; need to look at the possibilities as to why. I validated this by using both tools against the first operation barbarossa message: http://wiki.franklinheath.co.uk/index.php/Enigma/Sample_Messages

The chef package did the job properly, python-enigma did not, so definitely our bug to fix.

[brainrecursion]

Just to confirm using latest pypi "python-enigma (1.1.0)".
Seems to be a glitch with certain settings as been doing lots of Enigma challenges and they have all worked flawlessly apart from one.

[ZAdamMac]

See that's almost more confusing, since I'm almost unable to get it to work correctly /at all/ now that I've begun testing. Can you provide an example where it worked as expected?

[brainrecursion]

If you change the rotors around to:

rotors = [("IV", "A"), ("II", "B"), ("III", "C")]

Then it works as expected.

[ZAdamMac]

That's deeply peculiar, given that that's certainly not how you're set up in chef.

I'm curious if this is somepeculiarity of tuples I've yet to grasp. I'll need a day or two to play with this.

[ZAdamMac]

My earlier comment about the barbarosa messages being invalid turned out to be operator error. It really does seem to be something magic about rotors = [("II", "A"), ("IV", "B"), ("III", "C")] as a wheelpack.

[brainrecursion]

Sorry I meant setting both the python and chef to these settings you get the same output.

I had a look and couldn't get my head around what is going wrong.

[ZAdamMac]

Just as an additional note to myself: this isn't chef's fault. The Cryptii interpreter shows agreement with chef, so it's DEFINITELY the emulator.

I've followed individual letters through the rotor stack in this project's code and I cannot for the life of me figure out why it's wrong. I definitely want to get this solved, but I'm currently out of ideas and it might take me another few days to work it out.

[ZAdamMac]

Nailed it down: we're seeing the leftmost rotor step when it should not, because of the stepping logic, which in retrospect is pretty obviously wrong.

        self.rotors[0].step_me = True  # The rightmost rotor always steps.
        indexer = -1
        for rotor in self.rotors:
            indexer += 1
            if rotor.position in rotor.notch:  # If a rotor is at its notch, the one on the left steps.
                rotor.step_me = True
                try:
                    self.rotors[indexer+1].step_me = True
                except IndexError:
                    pass

Time permitting I'll fix this and release the tested fix in the next couple of hours. Otherwise it'll take a day or two to complete the testing.

[ZAdamMac]

This should now be corrected on master. Please try installing v 1.1.1 from pypi.

The issue here was that the old phrasing of the step logic (above) would set a rotor to step if it was in its notch position. This was not actually correct; the correct thing to do would have been to check that the rotor was GOING to step, then step the rotor to its right.

Replace rotor.step_me = true with if rotor.step_me: for the appropriate behaviour.

[brainrecursion]

Just tried to test but looks like the pypi v1.1.1 source hasn't updated correctly as it doesn't have the fix in?

[ZAdamMac]

Well, that's baffling. I'll look into updating that tonight.

[ZAdamMac]

The v1.1.2 package updated tonight has the change; I downloaded it myself on a fresh machine and confirmed it.

[brainrecursion]

Looks good to me. Getting correct output now.

Thanks!