Prev: Announcing: First-ever collection of declassified Chaocipher-relatedcorrespondences
Next: Looking for Participnts
From: Mok-Kong Shen on 7 Oct 2009 15:40 Mok-Kong Shen wrote: > The following is my layman's speculation with reference to your > progress Report No. 1: > > If one has doubled plaintext letters, say in the sequence 'aab', > couldn't it be that the second character 'a' is processed by an > extra rule different from the normal one of shifting thereafter > one, two, or three positions? (This extra rule could be a shift > of n positions, with n not in [1..3].) That is, one first > processes as if the second character 'a' were missing and > subsequently insert the cipher character corresponding to the > second 'a' into the right place. (Or some other procedure quite > equivalent to that.) Since doubled plaintext letters occur with > comparatively low frequency, this could eventually resolve the > issue of incompatibility you stated in the summary of your > findings, I would think. Pardon. As I wrote the above, I had the gut feeling that my writing somehow couldn't be quite right and now I found that the introduction (for the case of doubled plaintext letters) of an extra rule of the sort I indicated in parentheses above couldn't be ok. But the following seems to function: Recall that in the playfair cipher one sacrifies one character of the plaintext alphabet, commonly the 'j', in order that a 5x5 square can be built. In the present case we can do the same and employ the now free character 'j' to transform sequences like 'aab' to 'ajb' before applying the procedure with the sliding alphabets. Of course, this implies unfortunately that one has to, like in the case of playfair, to manually do an edit of the recovered plaintext, in order to restore those 'j' that were previously replaced by 'i'. Thanks, M. K. Shen
From: mosherubin on 9 Oct 2009 08:48
On Oct 7, 9:40 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > Mok-Kong Shen wrote: > > The following is my layman's speculation with reference to your > > progress Report No. 1: > > > If one has doubled plaintext letters, say in the sequence 'aab', > > couldn't it be that the second character 'a' is processed by an > > extra rule different from the normal one of shifting thereafter > > one, two, or three positions? (This extra rule could be a shift > > of n positions, with n not in [1..3].) That is, one first > > processes as if the second character 'a' were missing and > > subsequently insert the cipher character corresponding to the > > second 'a' into the right place. (Or some other procedure quite > > equivalent to that.) Since doubled plaintext letters occur with > > comparatively low frequency, this could eventually resolve the > > issue of incompatibility you stated in the summary of your > > findings, I would think. > > Pardon. As I wrote the above, I had the gut feeling that my writing > somehow couldn't be quite right and now I found that the introduction > (for the case of doubled plaintext letters) of an extra rule of the > sort I indicated in parentheses above couldn't be ok. But the > following seems to function: Recall that in the playfair cipher one > sacrifies one character of the plaintext alphabet, commonly the 'j', > in order that a 5x5 square can be built. In the present case we can > do the same and employ the now free character 'j' to transform > sequences like 'aab' to 'ajb' before applying the procedure with the > sliding alphabets. Of course, this implies unfortunately that one > has to, like in the case of playfair, to manually do an edit of the > recovered plaintext, in order to restore those 'j' that were > previously replaced by 'i'. > > Thanks, > > M. K. Shen Hi Mok-Kong, I appreciate your taking the time to read some of the progress reports on The Chaocipher Clearing House, and your posting here on sci.crypt. In your first posting, regarding doubled plaintext letters, you ask whether Chaocipher could have a special rule for handling such doubled pt letters. Even if the second pt letter were enciphered using a different method, the question would still be, why isn't there a single case of a doubled pt pair enciphered into a doubled ct pair? The question can be stated even stronger: why are there no doubled pt letters with 1, 2, 3, 4, 5, 6, or 7 intervening letters where the corresponding ct letters are also doubled? In other words, there are no examples of: pp cc p.p c.c p..p c..c p...p c...c p....p c....c . . . p.......p c.......c where the two p's are identical AND the two c's are identical. I think you would be hard put to handle identical pt letters at all this distances and make sure they never lead to identical ct letters. The remarkable observation is that Chaocipher somehow does exactly this! This is one of the indications that Chaocipher ciphertext is not as random and chaotic as Byrne believed it was. This is a significantly causal observation that will eventually lead to solving the system. In your second posting you posit an idea of replacing the second letter of a pt double with a different letter, e.g., 'j'. There are some questions that then arise: (*) The point made in the previous paragraph still stands: not only adjacent identical pt letters, but even identical pt letters at a distance of 1 to 8. This cannot be done manually, and I doubt if it could be mechanized. (*) Byrne, in his description of Chaocipher, makes no reference to such a method. (*) There are operational issues that arise. What would happen with a sentence like "I will jump"? The second 'ell' is substituted with a 'j', but now we have two adjacent j's! The encipherer would now need to use a second, different letter, etc. This is possible but leads to a system that is not as clean as Byrne alludes to. This same problem can occur with a classic Playfair, too. I encountered the same issue when implementing the Wheatstone Cryptograph for Dirk Rijmenants's "Cipher Classics" software package (http:// users.telenet.be/d.rijmenants/en/cipherclassics.htm). The Wheatstone, like the Playfair, has to substitute a duplicate pt letter with a different letter (not doing so leads to two ambiguous plaintexts). Since I was writing a generic automated algorithm to encipher _any_ plaintext using the Wheatstone, it required some clever use of two different low-frequency letters to handle all cases. I hope my replies make sense <g>! Once again, thanks for taking the time to post, and I look forward to any other comments you, or others, may have. Regards, Moshe |