Hi, yes I have solved #1 to #6 and am happy to indicate some outline of what I have done. As you know #3-#6 are Level III, which MTC3 suggests “represent current research topics that are believed to be very difficult to solve. Thus, practical solutions may not even exist and ready-to-run tools almost certainly do not.” So these should not be easy.
Ultimately the challenges need to be broken into phases or use MITM – simply because the overall keyspace is > 2^95 which won’t submit to brute force. Stamp and Chan (Stamp, Mark & Chan, Wing. (2007). SIGABA: Cryptanalysis of the full keyspace. Cryptologia. 31. 201-222. 10.1080/01611190701394650) indicate a two phase method whereas Lasry (A Practical Meet-in-the-Middle Attack on SIGABA, in the challenge material) uses MITM.
The challenges get 26^2 times harder at each challenge, as an extra pair of letters become undefined. The breaking into phases can likely make each phase only around 26 times harder. But even then, #6 is 26^5 times harder than the one you have solved. So even generously assuming you are prepared to allow as much as a year of computer time to solve #6, you’d need to be solving #1 in under 3 seconds to use the same method – which I suspect is the problem you’ve identified.
And Dr Lasry, in his MITM paper, speaks of taking ‘a few days’ to solve something equivalent to #2. So (unoptimised) that method would not scale.
So you either need a bigger computer or a better method, perhaps both. What I have done (outline only) is conceptually based on Stamp and Chan’s work in that I solve for likely candidates of Cipher rotor settings first, then only apply a second phase to the most likely. Specifically I use dynamic programming to tame the exponential growth in the Phase 1 element. In effect that means reusing results from previous calculations rather than following different paths and hence seeing exponential growth.
I do that phase on a GPU using CUDA. It is work that is well suited to a GPU. The downside is that this is holistic - effectively you have to do as much work for #6 as #1. So I don’t use that method for #1,#2,#3 as simple brute force enumeration is easier, but it is very good for #4,#5,#6.
Another downside is that the dynamic programming loses some signal to noise, so I then have to reprioritise based on actually enumerating the most likely paths in full, but there are vastly fewer to check.
The next stage of course is to match the result to a specific location in the Control and Index wheel settings. I think I’m happy to hint that you can take the index wheels out of that equation, which makes things about a million times easier. And again, this phase was well suited to CUDA on a GPU.
None of this was easy and did take me some time, but it was interesting, and I’m glad I did it. My early code probably wasn't much faster than yours.
So, can you use your current code to hope to solve #6? No. Is No 6 possible to solve in days with the right code on a domestic computer? Yes.