Wikunia
Can't get it to work
I have been trying out your program but I can't get a result. Maybe I am doing something wrong? I use Cryptool to encode: VONGE NERAL JBUSH ENHAG ENJFU RGENE RALOB ERSTJ DIETL JOPER ATION using settings:
III/V/I (left to right) UKW B Ring settings 25,3,7 (left to right) Plugboard: BL CK DG FP IR MO QW ST UZ VY Initial rotor setting GBU
and I get the following encrypted message: RGOXT IVDHR FQGIK PUKXK CTISB GRIKM MYAAA SMWFH ZGLBU ZGOFG MGOJF
But if I test this with your program it doesn't find anything:
julia> crack_message = "RGOXT IVDHR FQGIK PUKXK CTISB GRIKM MYAAA SMWFH" "RGOXT IVDHR FQGIK PUKXK CTISB GRIKM MYAAA SMWFH"
julia> hint = "GENERALJBUSHENHAGENJ" "GENERALJBUSHENHAGENJ"
julia> bombe = BombeMachine(crack_message, hint) BombeMachine([1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5], [1, 2, 3, 4, 5, 6, 7, 8, 9, 10 … 17, 18, 19, 20, 21, 22, 23, 24, 25, 26], [1, 2, 3, 4, 5, 6, 7, 8, 9, 10 … 17, 18, 19, 20, 21, 22, 23, 24, 25, 26], [1, 2, 3, 4, 5, 6, 7, 8, 9, 10 … 17, 18, 19, 20, 21, 22, 23, 24, 25, 26], [1, 2, 3], "RGOXTIVDHRFQGIKPUKXKCTISBGRIKMMYAAASMWFH", "GENERALJBUSHENHAGENJ", [1, 2, 3, 4, 5, 6, 7, 8, 9, 10 … 12, 13, 14, 15, 16, 17, 18, 19, 20, 21], false)
julia> enigmas = run_cracking(bombe; log=false) EnigmaMachine[]
Thanks for opening the issue. Can you try to encodes the message with my package and check that it produces the same result?
I would guess the problem is that my package doesn't distinguish between ring setting and initial rotor setting.
This is currently more a proof of concept. I need to reread the difference between them again.
No, message from your program is different to that supplied by Cryptool. Not surprising as it's not taking into account the initial rotor settings at all.
So the ring position is missing. Will look up the difference of the two again as I didn't really get it last time
OK. Cheers. I'm still trying to understand it too. :-)
It often seems to be assumed that they are AAA.
"It became clear during the tests, that the ring position is not crucial when trying to find the starting state. Moving the rings relative to the core wiring of the rotors gives actually 26x26x26 equivalent states, and therefore 26x26x26 equivalent solutions. Inserting a rotor with Z up is the same as calling Z an A and inserting it with A up. It ends up in the same position! To decrypt a message we only need to know the relative positions. The objective is to find a solution which we can use for the decryption of a message, i.e. given an Enigma knowing how to set it up correctly. It is therefore sufficient to find the relative position of the rotors, no matter how these are called by changing the rings. We set the rings to AAA by default in the program therefore."
https://www.cs.miami.edu/home/harald/enigma/index.html
I like the Julia program though. Once I understood the commands it's very easy to install and run.
Yeah that reads like it's not really relevant that's what I thought. Therefore my bombe should still be able to crack it, right? One way to verify it would be to try calculating the position for my algorithm and check that it computes the same thing. If that is the case the bombe has an issue.
I see that cryptool also has the possibility that when one wheel rotates fully the next one does not rotate automatically. This is not supported by this package.
OK - further testing, and it gets interesting! Using your program, I did this:
julia> set_rotors!(enigma, 3,2,1)
julia> set_rotor_positions!(enigma, 1,1,1)
julia> set_plugboard!(enigma, "AB CD EF")
julia> set_ukw!(enigma::EnigmaMachine, 2)
julia> message = "VONGENERALJBUSHENHAGENJFURGENERALOBERSTJDIETLJOPERATION"
julia> encoded = encode!(enigma, message)
"FLLAM PNEUG BWPZQ UAXND MCKPE WRSXG TFYFZ VSFWI WPILN KQGDI WDDEC"
This is the same encoding I get with Cryptool using initial rotor setting AAA.
When I use your program to decode, it gives these 4 results: VZNGE NERAL JBUSH ENHAG ENJFU RGUNE RALZQ EWITP DSTTL JZPEW ATSZN VSNGE NERAL JBUSH ENHAG ENJFU RGDNE RALSM EYOTY DZXTL JSPEY ATZSN VONGE NERAL JBUSH ENHAG ENJFU RGENE RALOB ERSTJ DIETL JOPER ATION VONGE NERAL JBUSH ENHAG ENJFU RGWNE RALOX EVZTJ DIETL JOPER ATION
So, 3rd one is correct! Maybe if it is coded with AAA then it can decode, but if another settings is used it can't? Or maybe it can't handle the extra number of plugin settings? I'll keep testing and see if I can work out more.
I re-encoded the message in Cryptool using same settings, except BBB for initial rotor settings. The new encode was: GLBUX GULIH YVMPM VVYUQ YBNAJ UDLKK JXAVV CWBZH YNCKZ WVLBI FWBTD
Running it through your program gave me two results this time:
VONGE NERAL JBUSH ENHAG ENJFU REENE RALOB RRSTJ CIWTL JOPER ATIOE VONGE NERAL JBUSH ENHAG ENJFU REENE RALOB RRPTJ CIWTL JOSER ATIOE
So, close to correct.
I just tried another message, this time coded using initial rotor setting AAA but 10 plug pairs in the plugboard. One result: VONGE NERAL JBUSH ENHAG ENJFU RGENE RALOB ERSTJ DIETL JOPER Perfect!!
Yes I think the problem is that the ring position changes the point of when the rotor rotates the next rotor. So when the ring position is BBB it does it probably one step earlier for all of them.
I agree. I think the problem is the further we are away from AAA the more "out" it gets. I'll do some more testing to confirm this.
A few more test results. Ring position used for coding, followed by the output:
AAC VONGE NERAL JBUSH ENHAG ENJFU RGENE RALOB ERSTJ DIETL JOPER ATION
CCC VONGE NERAL JBUSH ENHAG ENJFU RGENE RALOB ERSTJ DIETL JOPER ATION
GNU KOEGE NERAL JBUSH ENHAG ENJFU RGENE FALOB ERSTJ CIETL YOPER ATIOA
XXX VPNGE NERAL JBUSH ENHAG ENJEU RGENG RGLPB ERSTJ DIETL MPOER AHIPN
Yeah that makes sense the length is not really long so I assume the last A is the only important one. If you do XXA it probably produces the correct result.
Yes. XXA does return the correct result.
Is there some way to get around this? I don't mind running something 26 times to test each letter placement.
I need to implement the extra detail and it would slow down the cracking quite drastically by a factor of 26^3 but maybe one can get around some of that for shorter messages
Yes, I can see that if it is included it will slow down a lot. But I can see this being a really powerful and useful tool, so it does need some way to handle those extra options. As shown in my initial post, I tested it with a known example and it just didn't work for me.
Could there be an option to initially only test 26 options for first wheel? If that fails then 26x26 could be enabled and tested. Last resort - 26x26x26 (but I can't see that ever being needed).
The program doesn't really know whether it was cracked. Maybe there were some results without hitting the correct one but I think it makes sense to have the default option and something like a more powerful option similar to enable ambiguous.
Will take some time until I can work on that though
Yes, I was thinking something the same as the enable/disable ambiguous setting.
That's fine. I'm just revisiting something I tried to crack 5 years ago. I can wait. :-)