Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug report: Possible bug in Lorenz SZ40 advance #973

Closed
oilulio opened this issue Mar 7, 2020 · 5 comments · Fixed by #978
Closed

Bug report: Possible bug in Lorenz SZ40 advance #973

oilulio opened this issue Mar 7, 2020 · 5 comments · Fixed by #978
Labels

Comments

@oilulio
Copy link

oilulio commented Mar 7, 2020

For a Lorenz SZ40 the Psi wheels should only move when the 37-tooth motor wheel shows an 'x'. That wheel moves if the 61-tooth motor wheel shows an x. The 61-tooth wheel moves at each encryption. These wheels have no other effect than advancing the Psi wheels.
This is described in Colossus, by B Jack Copeland and is what the comments in the code (Lorenz.mjs) say.

From this it should follow that if every cam is set ('x') on the 37-tooth motor wheel, then the settings on the 61-tooth wheel are irrelevant.

This counterexample has every cam set on the 37, only one set on the 61, yet toggling that single cam radically changes the decryption. Further, the cam is in the middle of the 61 wheel (i.e. not close to the active cam) yet changes the decryption from the beginning.

@oilulio oilulio added the bug label Mar 7, 2020
@oilulio
Copy link
Author

oilulio commented Mar 8, 2020

And I'm fairly certain the problem is that the code (Lorenz.mjs) reads the arrays as M37 then M61 in the lines
chosenSetting.M[1] = this.readLugs(lugm37);
chosenSetting.M[2] = this.readLugs(lugm61);

But in INIT_PATTERNS had the arrays declared instead with 61 as array index 1 and 37 as array index 2..
"M": {
1: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
2: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

That would explain why figures apparently in M61 affect M37. Recommended solution : reverse the empty arrays in INIT_PATTERNS.

@VirtualColossus
Copy link
Contributor

Hmm .. you're right and yes, appears the custom arrays are being loaded reversed! I'll work on amend and re-test.

@VirtualColossus
Copy link
Contributor

Pull request has been entered that should fix this.

Example of working pin settings based on your Psi and Chi wheels for Gil Haywood's daffodil Tunny test on fixed code: example

It adds just the Chi plus null Psi initially until Chi wheel with 23 pins has fully rotated then shifts M37 once so Psi wheels then continue stepping adding new Psi values completing the text.

@n1474335
Copy link
Member

Fix merged

@oilulio
Copy link
Author

oilulio commented Mar 12, 2020

Thanks, yes - that's what I was looking to produce, as per https://oilulio.wordpress.com/2014/07/20/encrypting-to-known-text-with-tunny/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants