Nothing special, the 1941 dictionary in use http://www.enigmaathome.net/download/00trigr.1941 has much lower scores for trigrams than Naval dictionary http://www.enigmaathome.net/download/00trigr.naval so the overall message score is low.

---

M4 Project homepage
M4 Project wiki

OK. And what is the difference between yngzo50 and yngzo100 ?

The first number after the letters shows the length of the ciphertext. There's no yngzo100 because the ciphertext is only 50 (55) letters long, so I assume that the question should be 'what is the difference between yngzo50_1 and yngzo50_XX'.
The last number in the ciphertext is the number of re-runs with different settings. For example, the 'yngzo' has missing letters at the end, so I replaced the first missing letter with each letter from the enigma alphabet, which produced 26 'ciphertexts' - yngzo50_1-26. The last two - _27 and _28 are the same like first one, just using other set of dictionaries.

Next I'll cut part of message starting at the second missing letter and I'll replace the first one with all possible combinations. This will produce shorter ciphertext, but should still be breakable - perhaps the missing letters are confusing the hillclimb algorithm. If that won't help, I'll try the last set of dictionaries I have, but I'll have to modify the server to use them.

There's also a minor problem with the work distribution. I was going to run only 30 walks on each settings, but it seems impossible with the current server software. The Enigma M3 keyspace is so short that it has only 60 workunits (120 including UKW C which probably wasn't used). Just feeding the BOINC queue until it's full when running a single ciphertext exceeds the 30-walks limit 10 times.
It's not a big deal because until the message is broken, any work done is not redundant. There is also another issue caused by this: not equal workunit distribution. At the end some parts of the keyspace have their number of walks much higher than others. To avoid this, I'll put a limit of 50 workunits in progress for each subrange.

---

M4 Project homepage
M4 Project wiki

OK. Thank you very much for all the information you share with us.It is interesting to get a better knowledge about what we are doing together.

Today all my WU have been completed and validatet, but they all look like this one :

<core_client_version>6.10.18</core_client_version>
<![CDATA[
<stderr_txt>
Unrecognized XML in parse_init_data_file: hostid
Skipping: 21634
Skipping: /hostid
Unrecognized XML in parse_init_data_file: starting_elapsed_time
Skipping: 0.000000
Skipping: /starting_elapsed_time
Unrecognized XML in parse_init_data_file: computation_deadline
Skipping: 1261297209.136000
Skipping: /computation_deadline
running enigma2_0.76_windows_intelx86.exe
2009-12-12 13:06:15 enigma: working on range ...
2009-12-12 14:28:11 enigma: finished range

</stderr_txt>
]]>

Validate state Valid
Claimed credit 20.650391181668
Granted credit 21.236
application version 5.22


There is no validator info, score and text, but I think it is in order anyway, may it is just some bugs somewhere.

It's not a bug, the process which updates stderr is set to run only if the average database load is low, because the result table is the largest one and updating it eats a lot of resources. This causes a lag between receiving the wu and writing info to the db. Usually not very long, but in extreme cases could be few hours.

---

M4 Project homepage
M4 Project wiki