Zodiackillersite.com

Jarlve wrote:As I've said before I believe the limited vocabulary artificially raise the multiplicity. So it's a multiplicity problem more than anything else.

You probably mean something like "word entropy", right? Since multiplicity (length of cipher divided by number of unique ciphertext symbols) of my last cipher is actually better than Z340 and almost as high as Z408 (if you drop the last 18-symbol filler at the end of Z408). My plaintext also uses 23 letters out of 26, same as Z408. IoC (0.075, I think) is a tad high but still within the expected range for English. I think the main reason why my latest cipher wasn't auto-solved is because the corpus used to build 4-grams/5-grams stats doesn't represent my plaintext too well. This issue was already demonstrated by my previous Zodiac signs cipher. Once you updated AZD to use 5-grams from a wider corpus, it is now solved quite easily, whereas the currently available version of ZKD/AZD still can't solve it. I believe if the 4-grams/5-grams are updated to represent a good variety of numerals spelled out as words, my latest "unsolvable" cipher will fall to automatic cracking quite easily too.

Jarlve wrote:I agree that some ciphers may be unsolveable due to the nature of the plaintext and multiplicity of the cipher. It's fair to assume that such a scheme is not actual in the 340 because there are not much patterns and it scores much lower than your 3rd cipher in both of the solvers.

Yes, you are correct of course. Z340 is sufficiently different from my cipher to rule out that its plaintext is similar. However, what I'm worried about is this. It's almost certain now that Z340 was manipulated in some additional ways besides homophonic substitution. Be it reversing rows, or using rail fence, transpositions, bifid encoding, what-have-you. I believe a lot of cracking attempts along this attack vector involves brute forcing all possible permutations of a given manipulation and then feeding the results to AZD/ZKD without too much manual analysis of each intermediate step. And that's what I'm worried about -- you might come across the correct extra manipulation that Z did to plaintext, but then you'll miss it because AZD/ZKD will potentially fail to solve it. Even though the original Z340 doesn't have a lot of patterns, it's quite possible that those patterns will emerge if full force if you transpose columns using the key "ZODIAC", for example. And it will be missed because that intermediate result will be among hundreds of other possible transpositions that were fed to auto-solvers without any manual analysis. Maybe we need to incorporate automatic merging of repeated cycles into auto-solvers, which is how my latest "unsolvable" cipher was cracked?

With IoC 0.075 a reasonable automatic solve came through, though it wasn't the highest scoring example.

Code: Select all

Don't scroll down this box if you don't want to see the solution yet to daikon's 3rd cipher.












moriacvictedsmalla
bothirtolightsseve
ndthirtythreednort
honahundrastwentot
herallmendtwentyse
venswasthaniciathi
rtoeightsfimadinfo
rtyonldnorthenehun
dresthentotworeigh
tdthirtyaightswast
lakeharrolsdathirt
yeightsthirtothree
dfortyeightsnorthe
nahundrasthentotwo
rthirtalndfiftyfou
rswestdanfrancisco
thirtosevensfertys
emandninateandnort
honlhundresthentot
wortwentysevandtha
ntofimeswasthesiac


You are correct about the corpus not really adhering to the message, I was still asuming an IoC of around 0.0667. glurk was kind enough to send me the solution but I didn't check the IoC.

Your worries are understandable. But with for instance, reversing of rows and many other schemes, there is allot of overlap. Meaning that the solution will be recovered multiple times. Also better solutions will score higher, and the top results can easily be checked manually. But yes, there is the risk that the solution might be overlooked. You are probably aware that I've done allot of work in this direction and I have thought of doing tests over again with better versions of my solver.

I'm not sure about merging patterns because there are not many of them in the 340. I feel it's a niche.

Jarlve wrote:With IoC 0.075 a reasonable automatic solve came through

Hmm, interesting. It didn't occur to me to adjust IoC for automatic solves. I couldn't even find how to do that in ZKD when I looked just now, but I can adjust it easily in AZD. Perhaps an improvement could be made that you could specify an IoC range, and the program will randomly pick an IoC within the range for each random restart? Maybe even use normal/Gaussian distribution, so it hits mostly close to IoC but once in a while picks something relatively far from the expected IoC?

Jarlve wrote:, though it wasn't the highest scoring example.

I've seen that happen in ZKD when I was reducing the number of unique symbols in ciphertext -- as it was iterating over the solution, I could see some of the correct words develop, but then it would blow right past and scramble everything again, with something that scored higher, but was farther away from the correct solution. I think using 5/6-grams would help with that.

Jarlve wrote:I'm not sure about merging patterns because there are not many of them in the 340. I feel it's a niche.

Yes, that's true for "vanilla" Z340. But once you start applying transpositions/bifid/etc., patterns might show up as you get close to finding the correct extra step.

The IoC range is a good idea. I was thinking either to allow some adjustable sway in the IoC or to add a module that tries to solve just one cipher going over an adjustable range of IoC, for example (0.0534 -> 0.0800), scoring renormalized by IoC afterwards. I once had a secondary hill climber which figured out the IoC, so that's another thing to consider.

For now I want to focus on maximizing results from 5-grams, probably for quite a while. But you are right.

Edit: also testing a weighed IoC model as in ZKDecrypto.
Edit 2: testing IoC target and weighed IoC model together produced superior results, will allow to adjust the strength of both. This is exactly the adjustable sway I was looking for.

General question to you crypto heads: Is there a term for a cipher which simply "doubles" the same basic substitution?

Example: % = 1 = A?

Now, that particular one would be pretty pointless. But what if I settled on something like this:

% = 0
# = 1
001 = A

The plaintext would be "A" and the cipher would read "%%#".

Is there a term for this sort of thing?

Norse,

Not that I'm aware of (not good with terms). Maybe we could call them tokens?

Jumping a bit ahead. I like the idea in relation to the 340. But such a scheme, even partially, would greatly increase bigrams/trigrams counts. In the 340 the opposite is actual, more or less.

But still an interesting idea that could be expanded on, reversed.

For instance:

LL = ++
TT = M+

@daikon, you really should come back and make another challenge cipher. This time with similarly repetitive plaintext but with unpredictable homophone cycles.

Hi!

Maybe you want to try to solve the following cipher? (I will call it „Largo_04“)
It is written in normal reading direction. Homophonic symbols are non-cyclic (choosen by random). No fillers or fake letters were used. No transposition was applied. The plaintext is maybe not the kind of text that you would expect but it is a valid message without abbreviations or misspelled words. It contains something that should prevent autosolvers from solving it. And no…it is not a german text
I have not tried to resemble the characteristics of z340 since I just want to test an idea I had some days ago. If you are not able to break the cipher we maybe have a clue why z340 is not solvable. I have tried to solve Largo_04 with zkdecrypto and AZDecrypt without success. Unfortunately I have not so much experience with these tools and usually I just press the „solve“ buttons. In zkdecrypto I have also used the file for cribs and userdict. I am curious what you guys can do with the following test cipher. Probably you will break it within a minute.
The strange thing is that AZDecrypt produces a quite high scoring but the result contains no readable (valid) parts. Here we go:

Code: Select all

C0m0CRn2UAr7KdUZ4
SFU-NyI14+IQEdajV
dJGTSKzgQMg5VfABF
L6klDRlDCCnoW8M3h
UgqKOJ24b87G4drgB
i+3tPmDw0CunGKebP
dUe7XbpV-3d8ABt37
pkx0xlDCungPKKB1U
LhpSJP+N+IdzbXItq
2zI5B1qiEWE2ZN+VU
zIABFL+vDmDCwndjM
Yr+8tp7736fSdZ3oW
zpYZjF8sLAYLPMUoi
-c2XSFGgBFL6JPcDx
v0CwngMBT6WQ2KS8Y
15+doEo8Y4sJWOc57
IbTY1OhUgBiS3tOkl
DkkDCwncfL1GK46Ec
7rJ4I3UWrXFWKJgBF
LyHUI3NonwDJtcInl


I tried to solve Largo_04 with AZD on progressive mode for 57 attempts, and the solver locked in on this:

Score: 21504 Ioc: 718 M: 185 C: 340 S: 63

lanallystbertstho
ngtiandsondeasout
stsanteherhotobeg
icncalcallytheren
thatitsomersosehe
rnedonalallystomo
storimitiesebeder
insascallyhottest
inintonandsemidda
sedoesarahashantt
edbegincanallysur
renedirreconsheth
eirhugefibriorttr
ipsingshegictopas
callyhreachestner
sonstaterofthipor
dmarsinthernedinc
annallypoisstocap
retodetheighttheg
instdeatylatdpdyc

It looks like there may be a lot of repeated phrases. I marked some consistencies in red.

Hi!

Thanks for trying to break my cipher smokie treats!
Is someone trying to solve it at the moment or do you want me to post the solution so that we can discuss how to auto-solve a message like Largo_04?

Maybe a small hint:
The repeating pattern "ally" does not represent an exactly repeated pattern in the plaintext. The parts are similar to each other but differ a bit.