Don’t forget that when you column shift or row shift it wraps around to the next line and pushes all rows or columns further along. That’s what makes scytale work the way it does.
Yes that is true. But the individual columns must connect to each other end to end somehow as well. I realized that my spreadsheet has a flaw that I will have to fix. With only row 1 added at the bottom, I can’t check for period 38 repeats occurring at rows 18 and 2. I need to add more rows at the bottom so that I can check for longer periods. I won’t be able to solve the 340 with this, but just working on a method to detect how columns connect to each other in Spartan messages.
Jarlve, didn’t you already try to solve these 19 columns transposed into rows irrespective of how they connect? Maybe you shouldn’t tell me how bad it is because I don’t want to lose enthusiasm for my latest spreadsheet. When you tried with the 54 or 55 fragments you did get a couple of actual words and I was very impressed. Yeah, don’t tell me what happened with the 19 columns right now. If you do then I will have to try to figure out a new project and I want to work on this one for the next several days.
EDIT: I found the Wikipedia page for Scytale ciphers and it is a very interesting short article. "Scytale" translates to "baton." 7th century B.C. battlefield commanders may have used this cipher for fast transpositions. But it seems that all the enemy would have to do is use trial and error to find the diameter of the baton. The circumference of the baton would have to be an increment of the width of the lettering, and that wouldn’t be difficult to figure out – unless the lettering was written in a different size and in a rectangular arrangement instead of on a strip of parchment.
Hi. smokie. I agree this won’t solve the cipher but it may be the answer to the transposition..it’s a simple action that brings the period 19s’ into alignment. Simplicity is what I’m looking for. The important part about the Spartan Scytale is that as it wraps around it changes its relationship with the column or rows adjacent and as you go along it steps down or up each row.. I really struggled to understand it and tried to replicate it with spreadsheets but could not. I really think it would benefit anyone trying to understand its workings to make one up on a spreadsheet, using the same size cell squares, drop in a dozen coloured period 19s’ and wrap it around something until you get your alignment. We don’t need to know the diameter of the shaft as the period alignments have been discovered as you wrap they come together.. All of this of course if this is the smoking gun. This is how I think z made this part of the code.. Maybe it’s period 15, 19′, or rows or columns or other but it is the simplistic nature of this as a substitution mechanism that I really like and the fact that it’s boy scout(ish).
I like it too for the same reasons. I re-tooled my scytale speadsheet and added rows at the bottom. When I change the period, the symbols fill in at the bottom accordingly and the spreadsheet colors the bigram repeats, adds them up and totals the score.
Below is period 57 with the first three rows at the bottom showing the columns to the left. If you look at the bottom of column 1, you can see that the last three symbols are the same as the first three symbol at the top of column 2. And I can make it go the other way if I want to. Or go 1, 2 or 4 rows at bottom.
On the upper right is the count of period 57 matches, with the total score.
Soon I will make some practice scytale messages. Now that I can do that very quickly with my new message making spreadsheet. I will change the period and shift the rows at bottom from left to right to see if I can determine whether the message read column to column left to right or right to left. If it works, then I will compare to the 340.
Probably tomorrow.
By the way, the width of 19 cells in my spreadsheet adds up to the exact circumference that Zodiac used for his baton – if he used a scytale transposition.
To get my bigram 19 lined up I needed two full columns and the first cell of the third column that way it ended up a one cell increment.. I posted my results up a day ago and am waiting on jarlve to run it through his solver. Not sure if I got it right as it was manually column shifted. Plenty of room for error..maybe you could test to see if the sequences are the same. I would like to copy your spreadsheet one day if that’s ok.
You seem to be a spreadsheet guru
Cheers.
Edit can you make the bigrams different (alternating) colors so that they are more visually distinguishable.
I posted my results up a day ago and am waiting on jarlve to run it through his solver.
The score is a bit lower than the base 340 so it’s very likely that this is not a solve.
Score: 20243 Ioc: 733 M: 185 C: 340 S: 63 mansplayt akeasonis renonchro undwarond amentehom eascarewa nthedinta inatidait trippener smmaiospe nnhilelin thetodesa ndstourtr ontforthe rlroespel inesmmill lentalcal ialpdrblo odooncyfo rtrasiler enrtthath itsnorhea rtandtheb odierstam oeasisaso niahaaper isontsinc hneschani aritterio usherelic kiamswher looptryin ashinantc rtsnloupo ntateform edmediati neoheatpm inaddnh 1 19 37 44 11 56 8 60 31 8 35 7 49 30 59 40 63 55 20 5 40 23 38 18 34 20 23 42 37 51 58 19 20 29 37 51 46 3 57 22 16 5 61 52 3 5 19 32 39 19 20 28 58 19 22 16 61 7 25 50 36 48 19 21 37 8 2 50 51 8 50 16 17 6 50 11 11 28 38 57 13 55 3 3 19 50 4 32 11 5 38 36 34 50 56 7 26 21 36 16 47 7 53 23 51 14 55 19 40 51 30 31 29 42 20 31 6 59 40 16 9 27 62 16 34 28 13 26 20 23 14 32 11 14 56 43 40 12 30 1 3 33 26 10 10 28 22 31 19 10 18 8 26 33 19 10 11 25 6 24 26 23 52 25 4 4 22 39 45 9 4 13 2 20 19 30 50 10 28 13 5 36 6 17 17 15 19 53 34 43 48 55 36 27 62 34 5 19 6 16 46 36 51 31 47 7 24 23 51 43 14 20 44 31 49 3 23 5 19 44 50 41 19 41 27 37 21 19 15 19 19 11 14 20 50 55 29 38 48 30 50 36 39 15 40 54 41 18 61 8 37 33 19 6 33 16 2 28 20 33 29 42 32 47 5 6 54 56 63 18 35 21 19 1 30 58 15 12 20 56 23 23 11 17 20 45 50 36 46 44 15 33 36 19 40 48 39 13 31 41 36 26 29 42 11 29 40 16 19 17 5 9 27 13 3 54 51 1 7 25 21 19 53 21 37 5 23 15 5 19 16 11 3 21 38 8 51 51 40 47
Thanks jarlve.. Interesting all the same some good lines but no solve.. I will double check my original z340 to make sure it was right and how I brought it to the current position.. Thoughts are that its on the right path.. Maybe rows instead of the columns.. I still like the line of scytale, lots of scenarios to follow .. Different starting points different results? Different periods different results. If you guys think it’s taking to much of this transposition thread I’ll move on..
All the best
Don’t move on. Find a job to do that suits your interests. I don’t do any computer programming, but have a lot of fun making spreadsheet contributions.
I keep thinking about skipped or added symbols, and would like to return to the heatmap idea at some point. I only have a couple of hours a day available, and cannot do everything that I want to do.
One idea that I had was that perhaps a particular symbol may be a null inserted in several locations to make un-transposition difficult. If I was a 7th century BC battlefield general, I would do that and the enemy would have a very difficult time deciphering my scytale messages. So maybe the heatmap would help with that.
Smokie ..Just read your bit about skipped or added symbols (nulls) and it made me think that if he used Scytale and had to use filler (junk) at the end then it would be interspersed through the code. Wonder if your heat map could find that. I would expect it to be offset or similar to candy cane wrap around somewhat like the 19 . Needle in a haystack. I know. 
Smokie, you had thoughts about a relation between transposition and prime phobia, this is something that I posted in another thread that could describe such a thing. And it seems to correlate well with "+" symbol observations.
I’ve come up with an interesting but rough hypothesis that could explain some of the unusual properties of the "+" symbol and perhaps even more of the cipher in general.
Let’s go through some of the unusual observations of the "+" symbol.
1. It has a count of 24 which is very high.
2. It does not seem to cycle well with other symbols.
3. Against expectations, only one of its positions is a prime number.
4. Two times it can be seen in a box pattern, and more box patterns appear through the cipher.
5. Sum all its positions, divided by 24 will yield 171. In other words, the symbol is perfectly spread around the middle of the cipher.The following image shows my rough hypothesis (it doesn’t have to be the dimensions or specific transpositions I listed). On the left sits the plaintext of the 408 (340 characters) in a 14 by 25 grid. 1 column is replaced with "+" symbols. Then moving on to the left, the next image shows the same text diagonally transposed. Then the text is casted in a 17 by 20 grid and a similar pattern to that of the 340 comes into existence.
1. The count is explained (but not the motive).
2. Could be explained that the symbol was not substituted more than one homophone.
3, 4 and 5. Could be explained by the mechanics of the transposition.
On second though the motive could simply be to make decryption harder and in that case the "+" symbol could be a null or a poly.
It is difficult to reconcile period 19 with prime phobia, but I am open minded about a relationship. Primes line up vertically in an 18 column message and the + symbol largely avoids those columns, and period 19’s line up vertically in a 19 column message.
Still working on the scytale analysis; other stuff came up. At some point I will probably rotate the message into 18 columns x 19 rows so that period 19 becomes period 1.
The one thing the Scytale does is change its relationship at about the eigtth line When testing it in rows using a two period skip to bring in the 19s’. Its helix action makes it mirror turning it on itself.. Jarlve if you used the + as filler at the end in a Scytale it would be randomly dispersed in a cipher.
The only way I can understand how it works is visually. Paper and tape and colors..
Scytale carries all the hallmarks of the substitution process.. I also believe it is rows not columns….
2 hrs to a new year. So ..be happy 
I also believe it is rows not columns.
Me too.
I just completed the changes, can you test if this works for you? https://drive.google.com/open?id=0B5r0r … 3ZmdVd0NDQ
Change Solver mode in the upper right corner to Test mode. The number of ciphers to process fields will determine the range for which the program periodically scans. For instance From: 1.txt, To: 10.txt will scan from file 1.txt to 10.txt. When one of these files is found it will be processed with the settings you started the program with (random restarts, iterations, etc). When all threads have finished processing the input file will be deleted in the Ciphers directory and an empty file named "finished.txt" will be created in the Results directory.
I have just found some time to test this and came across a problem. I put the program in "Test mode", and it is set to process from 1.txt to 1.txt. Then I clicked "Start processing". So the program is waiting for my file. I dropped my 1.txt into the Ciphers directory and the program detects it, but "Problems: 1" appears in red. When I exit the program, I see this in log.txt: "problem: 0.txt more than 10.000 or less than 7 characters, aborted."
Then I tried setting it to process from 2.txt to 2.txt. When I dropped 2.txt into the Ciphers directory, the same error occurs but like this: "problem: 1.txt more than 10.000 or less than 7 characters, aborted."
However, I can kind of work around it by setting it to process 1.txt to 2.txt, and dropping both a 1.txt and 2.txt into the directory. The 1.txt causes a problem but the 2.txt gets processed as a 1.txt, and it seems to work.
Actually, this might be caused by file write differences, since I am copying the files from my Mac (which will generate the cipher files) to my Windows virtual machine (which is running AZDecrypt). If instead, I copy the 1.txt file within the Windows virtual machine into the Ciphers directory, it seems to work fine.
My guess is that the Mac is making the not-yet-fully-written file seem prematurely available to AZDecrypt, resulting in it processing the file before it is fully written.
Jarlve, the program now works fine in Test Mode when I copy a 1.txt into the Ciphers directory. It finishes processing the 1.txt file, then waits until I place another 1.txt file in the Ciphers directory. But when I do so, it crashes (see the attached screenshot).
Makes me wonder if it is trying to re-lock files (such as log.txt) that are already locked by the first run.
UPDATE: The problem doesn’t happen when I run the 32 bit binary instead of the 64 bit binary.
