Sigaba

[hettysymes]

I would like to submit a pull request for an emulation of the WW2 SIGABA machine. Please let me know of any comments. Thank you.

[s2224834]

Nice work! We're looking into ways of getting some better test data before we merge. (This is definitely not a criticism of your work. It's just that as we're something of an authoritative source, we're a bit wary of muddling the historical record due to a typo!) Can you tell us where the implementation here is from - have you based it on an existing simulator, or implemented it from scratch from the public documentation? Has it been tested against existing simulators?

[hettysymes]

Thank you for the feedback. I implemented the program from scratch by looking at public documentation on how the SIGABA machine physically works. One of the papers I looked at was a master's thesis by Miao Ai from San Jose State University on "CRYPTSIM: SIMULATORS FOR CLASSIC ROTOR CIPHERS" (https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1237&context=etd_projects). In the paper there is test data in Appendix C for the SIGABA machine, which was tested against an existing windows simulator (https://cryptocellar.org/simula/sigaba/index.html). The test data in the paper matches with that from the simulator I have written, however I agree that having more test data would be better. Do you have any more suggestions for improvement?

[hettysymes]

Hello @s2224834. Thanks for looking at this pull request. Is there anything I ought to do to move this forward? Let me know if further information is needed.

[oilulio]

Hi - I'm no .js expert, but I think the medium Control Rotor steps on at each 26th step from the start of the message in this code and the slow one at each 26^2. That seems wrong - stepping as a function of the point in the message, rather than the wheel settings. Pekelney suggests something like movement of the next rotor when the previous one shows 'O' although I think there are some inconsistencies between documentation and code. Not sure anyone knows what is right, but that is an area I'd check if possible in order to get this historically accurate.

[hettysymes]

Hi @oilulio. Thanks for looking at my code. After looking at different sources I see that many simply say that the control rotors step every 26 and 26^2 encryptions, with no indication of where they step, but after doing some searching I did find a source which indicates that it steps when the previous rotor steps from O to N (something which I haven't incorporated into my code) here: http://www.quadibloc.com/crypto/ro0205.htm where it states "When a rotor changes from the letter O to the letter N is when a carry takes place to the next slower rotor." However this is the only source I have found which mentions this, though this is likely. I plan to try to get further information by emailing a museum which has a SIGABA machine so as to make sure that this assumption is correct.

[oilulio]

Hi @hettysymes If it helps, I've tried to disentangle some of this in Sigaba.java in my repository. The comments in that code explain what I know. That code has three flags to mimic various alternatives (mainly so it can solve MTC3 challenges about Sigaba). I think the useful reference is Cryptologia Vol XXIII No 3 July 1999, but again, I'm not really sure anyone knows. Good idea about a museum.

[hettysymes]

Hi @oilulio. Thank you for the links to the SIGABA resources. I managed to contact Mr Patrick Weadon who is the curator of the National Cryptologic Museum in Maryland, who helpfully brought me into contact with Dr. Timothy Mucklow, an expert on the SIGABA machine and author of the following source: https://www.nsa.gov/Portals/70/documents/about/cryptologic-heritage/historical-figures-publications/publications/technology/The_SIGABA_ECM_Cipher_Machine_A_Beautiful_Idea3.pdf?ver=2019-08-07-124409-850. However, he too seemed to be uncertain as to whether the second control rotor steps with every 26 encryptions from the start of encryption, or only once the first rotor reaches a certain point in its rotation. It seems that without finding a real SIGABA machine it may be difficult to fact-check this.

[s2224834]

Thanks very much for your research and work here. It's a shame you weren't able to get a good answer. History is hard! We probably can't merge without being able to figure this out - as I mentioned we don't want to accidentally muddy the historical record. We'll have another go at getting some more information as well, but given the current disruption I wouldn't hold your breath on getting answers any time soon.
Thanks again.

[oilulio]

Hi @hettysymes, @s2224834 I did not reply immediately because it occurred to me that it might be useful to check the Sigaba patent

To quote the relevant section (my additions in [ ]):

“Each of the wheels 61 [code] and 70 [control] has a peripheral boss 122 (FIGS. 4 and 5) which on the third control wheel, once each revolution, moves contact strip 123 to close a circuit … to the stepping magnet 93 of the fourth control wheel 70 and cause the fourth wheel to rotate one step. In its turn, the boss 122 on the fourth control wheel operates … and so connect the stepping magnet 93 of the second control wheel.”

Now Fig 5 in particular makes it clear that the boss 122 is a feature of the wheel not the machine and hence I submit that the logical conclusion is that the advance occurs when the wheel is in a particular position, not a particular number of steps after the start of the message.

Incidentally the drawing appears to show a second boss, but the text is clear the advance is once per revolution. Either artistic licence or a boss for the wheel in reverse may be the answer.

Hope that helps. {later edit to correct terminology, main thrust unchanged}

[oilulio]

@hettysymes
And finally from Vol 3 of the History of Converter M-134-C, I find on p144 of PDF, "Another circuit is routed from the stepping contact "B" to the number three rotor magnet of the control maze, so that it advances its rotor once for each revolution of the main shaft. Every time the letter "O" of this third rotor is aligned with the white reference marks on the cipher unit, a stud on its periphery closes a pair of contacts, completing a circuit to the number four rotor magnet. When the letter “O” on of this fourth rotor is aligned with the white reference marks on the cipher unit, a similar stud on its periphery closes a contact. When contacts at the third and fourth positions are closed, a circuit to the number two rotor magnet is completed. That is to say, the third rotor is advanced once for each revolution of the main shaft, the fourth rotor is advanced at least once for every 26 revolutions of the main shaft, and the second rotor is advanced at least once for every 676 revolutions of the main shaft. The first and fifth rotors in the control maze are not advanced during plain, encipher, or decipher operations". Which seems definitive as a primary source.

[hettysymes]

Thank you very much @oilulio for finding this source! I have not come across it before. It does indeed seem like definitive proof that the control rotor steps with every "O" reached on the previous rotor. I shall set about modifying the pull request soon to implement this.

[oilulio]

Hi @hettysymes. Not a problem. I think now your algorithm would match the Java code in George Lasry's MITM paper, which may help with your testing (and also my repo code with the Match Lasry flags set).

[s2224834]

Excellent work! Once you've got the changes made and have some testing done against the other implementation mentioned I think I'm happy enough with the sourcing to go ahead with a code review and merge once that's done. What do you think @n1474335?

[hettysymes]

Just did a rebase to master. I will now look at making the changes.

[hettysymes]

The program has now been modified so that the next control rotor steps once the previous one has reached "O". I have checked it against the test available in George Lasry's MITM paper as commented by @oilulio. The output has also been tested against @oilulio's repo code and the results agree. In addition to this the tests for the SIGABA have been extended with longer tests so that all rotors are covered. I hope this covers any testing issues. Please let me know if there are any more comments.

[n1474335]

Happy for this to be merged now I think. The only thing I would request is that you add a line into the operation description stating that whilst this has been tested against other software emulators, it has not been tested against hardware. Our other cipher machine emulators of that era have been tested against hardware and I think we should maintain that aspiration where possible, so as to provide the most trustworthy source available.

[hettysymes]

@n1474335 thanks for the comment. I have updated the operation description to include that note, and have also made the commenting consistent with the other emulators. Hope this looks okay now.

[hettysymes]

@s2224834 I think the changes have been made now, and I have tested it against other simulators. Please let me know if there is anything else needed for this pull request. Thanks.

[hettysymes]

@s2224834 I'd just like to check on the status of this pull request. Is there further action I need to take or do you think it is acceptable? I'd welcome any feedback. Thanks.