From: Mok-Kong Shen on
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
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