What about 6?

Better. Now that it is getting warmer you may want to check the CPU temperature again, just to be safe. If it is over 75 degrees I recommend shifting back to 4 or 5 CPU threads.

K I am getting about 16.5 to 17 MIPS on 6 threads at about 65 degrees. I get about multiplicity and comparing scores now. Thanks.

It looks like lowering the temp or alternatively increasing the shift % works better. My first 100 restarts at temp 50, shift 10%, shift div 2 only produced 3%, so I guess it wasn’t enough restarts for a good estimation.

I see that you are trying 6 grams. I will work on the two that I started nearest the bottom until 500 each, unless you help out. I get about 3 restarts per hour, so it takes about a day and a half to get 100. But that is fine. I will just keep going.

I wonder about 4 grams, 3 grams, etc, and if there is an optimum depending on how many null +skips, since the more misalignments, the shorter the chunks of actual message there are to score. I also wonder if there is an optimum shift % depending on how many nulls + skips there are.

I am happy about our work, and looking forward to a long process.

By the way, law enforcement caught the Golden State Killer. Don’t know if you know who we was, but he raped and killed a lot of people in California in the late 70s. He killed two people close to where I lived in Ventura. Some of the kids that rode my school bus got on at the last stop, at that neighborhood.

It looks like lowering the temp or alternatively increasing the shift % works better.

Indeed.

My first 100 restarts at temp 50, shift 10%, shift div 2 only produced 3%, so I guess it wasn’t enough restarts for a good estimation.

There may be a problem. Such that using a higher amount of threads increases the solve rate. I added another field for you "Temp 60, shift 10%, shift div 2". For this I have 6.4%. That may take a while but we have time I suppose.

I see that you are trying 6 grams.

For now it is doing very well, 17.39% solve rate. Though it is almost 3 times as slow. I will compare it later to about 120k hill climber iterations with 5-grams to determine its worth.

I wonder about 4 grams, 3 grams, etc, and if there is an optimum depending on how many null +skips, since the more misalignments, the shorter the chunks of actual message there are to score.

I fear that 3-grams and 4-grams may miss the solving strength that is required.

I also wonder if there is an optimum shift % depending on how many nulls + skips there are.

Each cipher has its own optimum settings, that is why I do not over-optimize on one cipher.

I am happy about our work, and looking forward to a long process.

The optimization cycle will pay off. And probably is necessary.

By the way, law enforcement caught the Golden State Killer. Don’t know if you know who we was, but he raped and killed a lot of people in California in the late 70s. He killed two people close to where I lived in Ventura. Some of the kids that rode my school bus got on at the last stop, at that neighborhood.

Thank you, I did not know about this case. I would not be surprised if Zodiac ever turns up to be ex. police or FBI. And there is hope yet.

There is definitely some variance. On row 15, labelled trial 8, I had 7 solves with score over 22222 in 400 restarts, but with the next 100 restarts, I got 8 solves with score over 22222. So that one jumped from 1.8% to 3%.

I am working on row 16, labelled trial 9 now, and will double back to row 17, trial 10 later.

Jarlve: I woke up thinking about something, a question about your null skip hill climber algorithm. Here is a simple example.

The current chosen positions for three possible nulls N1, N2 and N3 are 100, 200, and 300. The computer randomly decides to move N3 to position 50 to see if there is a better n gram score. Do the positions for N1 and N2 stay at 100 and 200, or do they slide to 101 and 201 because moving N3 to 50 shifts all of the symbols in the message after 50 over 1?

Another independent question, same initial positions for N1, N2 and N3. Let’s say that the n gram score is higher with N3 at its new position 50. Instead of 10% of the time select a new random position for N3 between 40 and 60, have a variable X3. X3 always starts at false. But the first time N3 changes and the n gram score is higher, X3 changes to true. And then, if X3 is true, 10% of the time select a new random position for N3 between 40 and 60.

Thanks.

The current chosen positions for three possible nulls N1, N2 and N3 are 100, 200, and 300. The computer randomly decides to move N3 to position 50 to see if there is a better n gram score. Do the positions for N1 and N2 stay at 100 and 200, or do they slide to 101 and 201 because moving N3 to 50 shifts all of the symbols in the message after 50 over 1?

The positions for N1 and N2 stay at 100 and 200. I thought of that.

Another independent question, same initial positions for N1, N2 and N3. Let’s say that the n gram score is higher with N3 at its new position 50. Instead of 10% of the time select a new random position for N3 between 40 and 60, have a variable X3. X3 always starts at false. But the first time N3 changes and the n gram score is higher, X3 changes to true. And then, if X3 is true, 10% of the time select a new random position for N3 between 40 and 60.

Sounds like a good idea. Fine tune only after a good change is found. When do the X variable change back to false? When the ngram score is lower for that N?

The positions for N1 and N2 stay at 100 and 200. I thought of that.

Yeah, but shouldn’t N1 and N2 slide to 101 and 102? I mean, the symbol before N1 and the symbol after N1 should remain the same, and the symbol before N2 and the symbol after N2 should remain the same. Otherwise there would be a gradual position drift that the algorithm would have to constantly be adjusting for with the fine tuning.

I noticed that the 15% shift had more solves, that’s what made me think of it. I was wondering why, and this was the idea.

When do the X variable change back to false? When the ngram score is lower for that N?

I don’t know. Maybe X would never go back to false. Every time we move N and the n gram score goes up, we keep the change. So, X would only be false for every N for a short time. I don’t know if it is worthwhile.

The positions for N1 and N2 stay at 100 and 200. I thought of that.

Yeah, but shouldn’t N1 and N2 slide to 101 and 102? I mean, the symbol before N1 and the symbol after N1 should remain the same, and the symbol before N2 and the symbol after N2 should remain the same. Otherwise there would be a gradual position drift that the algorithm would have to constantly be adjusting for with the fine tuning.

I noticed that the 15% shift had more solves, that’s what made me think of it. I was wondering why, and this was the idea.

N1 and N2 do not drift after changing N3. That is what I meant and as such it is programmed.

Say the key is Nulls(50,100) or whatever.

1. The positions are marked in the original unchanged cipher array.
2. The original cipher is copied over to a new cipher array leaving out the marked positions.
3. The new cipher is sent to the substitution solver.

What I mean is that the positions stay the same in step 1.

Add in step 2b. The cipher is untransposed as the specified period.

O.k. it took me a while to wrap my head around that. You always delete suspected nulls and insert nulls at locations of suspected skips in the original message, and you do not do this to a version of the message that has been changed by deleting and inserting.

O.k. it took me a while to wrap my head around that. You always delete suspected nulls and insert nulls at locations of suspected skips in the original message, and you do not do this to a version of the message that has been changed by deleting and inserting.

Well, not quite. The nulls are simply left out while copying the original message over to the array of the modified message 1 character at a time.

It is looking like I am not getting as many solves over 22222 as you. Any ideas why?

When I downloaded the latest versions of the program, the ngram and other folders were not included, so I used ones from a previous version. But it is still on performance mode 5 grams. Or perhaps I have a setting incorrect. Or perhaps test a little while longer.

It is looking like I am not getting as many solves over 22222 as you. Any ideas why?

When I downloaded the latest versions of the program, the ngram and other folders were not included, so I used ones from a previous version. But it is still on performance mode 5 grams. Or perhaps I have a setting incorrect. Or perhaps test a little while longer.

Yes, only the program file was included with that download. It surely is 100% related to the number of threads we are using. You do have nulls & skips on 8 right? Lowering or increasing the temperature could fix this problem for you. I could run multiple instances of AZdecrypt with 6 threads to simulate your computer. I will make some new entries for this in the spreadsheet. Sorry that the optimization is taking so long!