Forum

Challenge "Sigaba Part 2"

Challenge "Sigaba Part 2"  

  By: admin on Oct. 11, 2010, 3:53 p.m.

Decrypt the given ciphertext which is encrypted with the Sigaba machine.

Please give the letters in the key as capital letters.

This challenge has solutions that cannot be automatically checked. If you find such a solution and want to receive your points please write us an [email=mtc3@cryptool.org:31ydsrvr]E-Mail[/email:31ydsrvr].

 Last edited by: admin on Oct. 31, 2021, 2:54 a.m., edited 5 times in total.

Re: Challenge "Sigaba Part 2"  

  By: rr on Nov. 12, 2010, 1:53 p.m.

The German PDF file should be corrected:

On the third last line on page 4 the word Steuerrotoren has to be replace by Indexrotoren (which are initialized with 0).

Re: Challenge "Sigaba Part 2"  

  By: Schoetti on Nov. 12, 2010, 7:46 p.m.

Thanks!

Re: Challenge "Sigaba Part 2"  

  By: be on Dec. 20, 2010, 8:33 p.m.

Prof. Stamp confirmed, that his student's program behaves differently than the real SIGABA. The reversed rotors don't work correct. But, it doesn't really effect the attack, as long as you use the given source code (C) of the (apparently flawed) simulator.

If you succeed with this variant you are close to attack messages from unflawed sigaba simulators.

See the discussions in the forum of challenge "Sigaba Part 1".

Re: Challenge "Sigaba Part 2"  

  By: Yokozuna on March 6, 2013, 4:39 p.m.

I think, the challenge Sigaba2 is not solvable because there is not only a problem with the reversed rotors but also with the not reversed rotors.

The function simulator first initializes the arrays CipherRotors and computes then with the functions generateCipherOffsets and generateControlOffsets the corresponding offsets CipherRotorsOffsets and ControlRotorsOffsets from the arrays CipherRotors and ControlRotors. These offsets belongs to the initial position "A" for every rotor.
After this the arrays CipherRotorsOffsets and ControlRotorsOffsets will be adapted to the given initial settings for the cipher and control rotors (function setPosition).

Until now there is no problem. But now comes the critical part. For every reversed rotor the function reverse will be called. For the rotor to be reversed this function computes the reversed Permutation in the corresponding array CipherRotors or ControlRotors, depending on the data in the arrays CipherRotorsOffsets or ControlRotorsOffsets. Because the latter data has been already previously changed due to the corresponding initial setting, the data in the array CipherRotors or ControlRotors depend on the initial setting of this rotor.
After this the corresponding array CipherRotorsOffsets or ControlRotorsOffsets has to be updated with a call to the function generateCipherOffsets or generateControlOffsets. And this is the problem because these two functions generate not only the offset for the actual reversed rotor but also for all other not reversed rotors (this two function should update the offsets only for the actual reversed rotor). Because this two functions uses the data given in the arrays CipherRotors or ControlRotors, which belongs to the initial position "A", all not reversed rotors will be set back to initial position "A".

As a summary we can say, that the reversed rotor(s) depend on the initial setting but for all not reversed rotors every initial setting will be mapped to "A". If for instance rotor 5 of the cipher rotors has been reversed (00001) and the initial setting for the cipher rotors has been ABCDE, then all other initial settings xxxxE will also do the job (x stands for an arbitrary letter A..Z).

Because the initial setting is part of the solution and I cannot decide, which of all possible initial settings the author of this challenge has used, the challenge seems to me unsolvable with the given source code (I have only 5 trys).

The challenge Sigaba1 is not affected by this problem, because the initial setting is already given and is not part of the solution.

Re: Challenge "Sigaba Part 2"  

  By: stamp on March 7, 2013, 8:15 p.m.

I think, the challenge Sigaba2 is not solvable because there is not only a problem with the reversed rotors but also with the not reversed rotors.

The function simulator first initializes the arrays CipherRotors and computes then with the functions generateCipherOffsets and generateControlOffsets the corresponding offsets CipherRotorsOffsets and ControlRotorsOffsets from the arrays CipherRotors and ControlRotors. These offsets belongs to the initial position "A" for every rotor.
After this the arrays CipherRotorsOffsets and ControlRotorsOffsets will be adapted to the given initial settings for the cipher and control rotors (function setPosition).

Until now there is no problem. But now comes the critical part. For every reversed rotor the function reverse will be called. For the rotor to be reversed this function computes the reversed Permutation in the corresponding array CipherRotors or ControlRotors, depending on the data in the arrays CipherRotorsOffsets or ControlRotorsOffsets. Because the latter data has been already previously changed due to the corresponding initial setting, the data in the array CipherRotors or ControlRotors depend on the initial setting of this rotor.
After this the corresponding array CipherRotorsOffsets or ControlRotorsOffsets has to be updated with a call to the function generateCipherOffsets or generateControlOffsets. And this is the problem because these two functions generate not only the offset for the actual reversed rotor but also for all other not reversed rotors (this two function should update the offsets only for the actual reversed rotor). Because this two functions uses the data given in the arrays CipherRotors or ControlRotors, which belongs to the initial position "A", all not reversed rotors will be set back to initial position "A".

As a summary we can say, that the reversed rotor(s) depend on the initial setting but for all not reversed rotors every initial setting will be mapped to "A". If for instance rotor 5 of the cipher rotors has been reversed (00001) and the initial setting for the cipher rotors has been ABCDE, then all other initial settings xxxxE will also do the job (x stands for an arbitrary letter A..Z).

Because the initial setting is part of the solution and I cannot decide, which of all possible initial settings the author of this challenge has used, the challenge seems to me unsolvable with the given source code (I have only 5 trys).

The challenge Sigaba1 is not affected by this problem, because the initial setting is already given and is not part of the solution.

I have been able to reproduce this problem, but haven't yet had time to dig into the code. This is definitely a serious issue and I'll correct it, but it might be a while before I get a chance to work on it. In the meantime, it is worth mentioning that this bug actually makes the challenge easier, since there are almost certainly a substantial number of equivalent keys—the exact number depends on the number of reversed rotors. Of course, if you only get 5 chances to submit a solution and only one of the (many) valid solutions is accepted, that is a problem. However, if you solve it (you'll know it when you do…) and if your solution is not accepted, PM me and I'll make sure that you get the glory that is due a solver of such a challenging challenge.

Mark Stamp

Re: Challenge  

  By: fmoraes on Dec. 3, 2014, 8:33 p.m.

I am retaking my efforts to solve this one. Anybody else working on it?

I have about 32K survivors from phase 1 attack, but my phase 2 attack is way too slow. I am not %100 sure on how to reduce the number of index permutations down to 2^8 as suggested in the papers, but I will take another look at it.

Would it be possible to confirm if the correct setting is among one of the survivors I've got? I've tried to narrow it down as much as I could, but it seems most settings survive no matter how much of the plaintext I use. Very few are shaved off if I use all letters of the plaintext as the number of possibly matching paths explodes and I had to implement a cutoff to keep the running time safe.

I've used the weakness mentioned to cut down the number of rotor positions from 26^5 to 130.

Any thoughts or suggestions? Right now, my second phase attack takes way too much time per survivor to be usable or likely to find the solution.

[Moved] Aid to solving  

  By: jerva on April 19, 2015, 8:46 a.m.

If you do want to solve this, you probably need to know:

  1. The error that has been mentioned in the C code is that within each Control or Cipher group of offsets (i.e. the 5 letters e.g. AFGDE), if any wheel of the 5 is reversed, then all non reversed wheels default to an offset of A, and all reversed wheels other than the first default to an offset of A. The first reversed wheel uses the correct offset. Therefore there are many equivalent keys. e.g. if control wheel reversal pattern is 01100 and intended offsets are XYZPQ then this acts as if the offsets were AYAAA. Hence ?Y??? are all equivalent keys.

  2. I believe the figure in the literature of 56,567 possible index rotor permutations is wrong. I get this exact figure if I calculate all permutations, discard those not in a canonical form and skip any duplicates. However I think the correct procedure is to convert to a canonical form and then skip duplicates, giving 113,400 (remaining as 10!/32 - i.e. they all actually exist).

  3. I think there is a second error in the C, that means the Control wheels all start their turnover pattern 13 characters into the message, rather than when 'O' shows in the indicator (this is when 'O' would show from a start of 'A').

  4. One of the effects of (1) and (3) is that you can't expect to confirm a plausible decrypt by 'restarting' the machine n characters into the message at the wheel position you have reached. There is effectively a hidden state variable.

Hope this helps

Jerva

[Moved] Re: Aid to solving  

  By: be on April 21, 2015, 10:14 p.m.

If you do want to solve this, you probably need to know:

Hello jerva.
Thanks for your input. Could you please move or copy your post under the according subject (challenge). Best regards, be


Currently 21 guests and 0 members are online.
Powered by the CrypTool project
© 2009-2021 MysteryTwister team