Re: VMs: Re: RE: VMS evolving table encipherment

["Jeff" <jeff@xxxxxxxxxxxxxxxxxxxxxx>]

----- Original Message -----
From: "Larry Roux" <lroux@xxxxxxx>
To: <vms-list@xxxxxxxxxxx>
Sent: 14 December 2003 18:22
Subject: Re: VMs: Re: RE: VMS evolving table encipherment


> Jeff:  See  http://web.syr.edu/~lroux/VoyChartEx.htm
> This is what I *think* you are doing.  What happens is you start with a
character (say "f") - that determines the chart to use.  Then you go down
the F line to the character you need.  Maybe "t".  Once you have a f->t
number anc character you write that down.  Then you go to the t column and
go down to the next letter...etc.
>
> Just wondering - is this the idea?
>

No the ft combination is the initiator. This pair has its own table with the
valid letters used to make up a triplet. Say we pick s. This gives us fts.
This means that the sequence fts gives say plaintext letter a. fto would
give a different letter, say e.

This portion of the table would look like this

ft <--- table initiator
s A <--- ciphertext triplet completor followed by plaintext input or output
o E

Plaintext is an input during the table build phase when the very first
encipherment takes
place. Once the table has built its own paths only occasional additions will
be needed
when a new language combination is met in the plaintext that has not been
encountered
before.

fts starts a plaintext sequence beginning with the letter a. fte starts a
sequence beginning
with e

This would limit the list of valid triplet completors (is there such a
word??) because
of restraints placed upon the system by the underlying language structure.

If we want to build the words apple or egg we might proceed thus. First see
if we have
a paragraph initiator for a. We have ft as our only initiator so far so we
llok down its list
and find ft with s gives us a. So we write fts as the start of out
ciphertext. We so far have
nothing to represent p. We now use the pair ts at the end of fts to start a
new table. ts
becomes a new table initiator. We can now select a glyph to follow this to
represent p.
Let's choose h. This gives us the first table entry for the pair ts.

ts
h P

We now have the partial ciphertext ftsh which represents the ap of apple and
two linked
paths through the language structure.

We now need another p. This is where the method would really mess up
statistical analysis.
We have the sh ending of tsh as our new table initiator. We can now choose
any glyph we
like for the second p. However any double p combinations in the plaintext
will sometimes,
though not always show this pattern.

Making up our new table we have sh as initiator. Let's choose o as our first
triplet
completor for this list. This gives a new table.

sh
o P

So our ciphertext now reads ftsho and the equivalent plaintext app.

Now if we had the word apart to encipher instead things would be different.
Let's review
the tables so far.

ft
s A
o E

ts
h P

sh
o P

For the word apart we already have our initiating triplet from the ft table.
So we start the
ciphertext fts. We also have a p present in the ts table so we can write
ftsh. We now
deviate from the path we had last as the sh table currently has no
representation for
the letter a. We can add this using the glyph e.

sh
o P
e A

So where we got ftsho for the plaintext app above, for apa we get ftshe.
This new combo
now takes us on a diverging path through the links. Same word start.
Different word
ending. The underlying language structure as well as glyph choice make this
system
very flexible for the endoder and a true nightmare for the decoder. BTW A
while back
I had been doing just what you seem to have been doing on your website with
the pairs
and found it too easy to determine patterns. This one just scrambles
everything up
completely.

Jeff


______________________________________________________________________
To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
unsubscribe vms-list