VMs: Re: RE: VMS evolving table encipherment

["Jeff" <jeff@xxxxxxxxxxxxxxxxxxxxxx>]

John Grove John@xxxxxxxxxxxx wrote
14 December 2003 00:20
Subject: VMs: RE: VMS evolving table encipherment


> fa   ao   oi   ii   in   ns   sh   ho   ok   ka   ar
> o C  i O  i U  i L  s Y  h O  o U  k T  a A  i K  r E
>                n D
>
>        Doesn't it bother you that 'i' does not exist as a separate entity
> and is
> probably just a portion of single character? In your process above...
there
> is
> no such thing as 'iin' : that's only an EVA version of what is most likely
a
> single character> for the sake of your encryption method - lets assign it
> 'N'
> like back in the FSG transcription...
>

It does not bother me if that was the intention of the author. Take the
English
word endings ing & ion. These would tend to stand out in a cipher. However
if these word endings were masked by the addition of a forced repetition
attached
to other word endings it would be much harder to isolate them.

We know that the structure of the VMS
is rigid. This is a construct developed by the author. Either to make an
artificial
system language like or mask the underlying properties of the plaintext. He
went to enough trouble to make it uncrackable that we are still here
discussing
it today. I am still convinced that it is in Italian, as this is the only
language pattern
that comes anywhere near to matching. I would just like to ask anyone
reading
this where they think it could possibly go next or whether it is useful at
all.

All comments will be considered.

> fa ao oN Ns sh ho ok ka aR etc... might be easier to argue out. Although,
> the
> problem is that all those 'i' and 'e/c' type characters/glyphs vary in how
> many
> strokes begin them; thus forcing the invention of EVA et al to depict the
> variations
> of what appears to be a similar letter into '@',an,ain,aiin,aiiin or the
> e-versions
> of b,cb,ccb,cccb. This of course is the same effect on a number of the
> end-ligatures
> like an a/r wierdo, ar,air,aiir,aiiir and aj,aij,... maybe even the
> aith,etc...
>
>         If an encryption process is used, it should be one that the author
> could
> pick out quite readily without lenghty look-up tables I would think.
> Especially,
> where labels are concerned. The recent posts of the Tranchedino cipherbets
> provides
> a little view into the minds of some encryption processes. Yes, there are
a
> number
> of VMS-type characters coincidentally represented there - but many more
that
> are not
> and many others that aren't in the VMS. What is interesting in the pages
> from
> Tranchedino is the tendency toward using very similar looking characters
for
> consecutive
> plain text letters.
>
>     Take the '1r' page for example and look at the encrypted characters
for
> g through i
> which all have variations of an 'o' and '+' or look at the Reverse
Syllabics
> like
> ub,ac,ec, ic?,oc,uc which are all similar 'g' shapes. And for the VMS
lovers
> in all of us...
>
> check out the encrypted forms for as,es,is,oS,uS,ar,er,ir,or,ur which
amount
> to VMS 'q'
> (for the s) and a VMS 'y'(for the r) with a vowel ligature/marker. I guess
I
> could also
> suggest that the 'p' syllables are VMS 'c' with the same markers...
>
>
>    This tendency to represent the same consonant within the syllabic set
> seems rather natural
> in my view. I also think that if someone was to invent an alphabet there
> would be a tendency
> toward slight variations in consecutive order like those seen in
> Tranchedino. The reason is simple:
> The author wants to be able to read his own text without having to ALWAYS
go
> back to the chart.
>
>    Once the brain is engaged to the method used, it should be able to
> continue reading without too
> much reflection back to the source table.  Just looking over a couple of
the
> Tranchedino pages
> shows the tables were designed as quick glance references (IMHO). The 1v
> page plain alphabet
> letters pqr for example make it simple enough to see the creator used the
> numbers 1 through 7 in
> reverse order as cipher characters, any upgright T form with dots in it
> would be a 'g', any wavy line
> is an 'i' etc...
>

1 to 7 is significant as 7 was regarded as a special number in alchemy I am
told.
This also leads me to suggest that it might in fact be artificial a la
Enochian and
may in fact have been produced by a table form that John Dee had created. In
which case we are with the wrong dog barking up the wrong tree.

As for Reverse Syllabics this would really foul things up in some respects
but
would not necessarily destroy the underlying language structure. IMHO I feel
that analysing the structures of proposed plaintext languages might be a way
to
go. If the author made it easy enough for himself to decipher without
reference
to table then the structure must be fully intact. If a table such as the one
I have
produced was used merely to trace the legitimate pathways through the
expected
languages then a heirarchy of lanuage units could be built as a template
against
which to analyse the structure of the VMS. Has anyone on the list tried this
approach?

>       Granted, these don't represent a polyalphabetic system that might
> require a little more look-up
> time, but a manuscript as large as the VMS wouldn't be much use to its
> author if he lost the polyalphabetic
> charts (or worse) to be able to read his own manuscript (Unless f57v is
it).
>

Well hiding the solution with the cipher is the in plain sight method used
by
some cryptographers.

>   What use is a single page in the manuscript if the author has to spend
> three hours deciphering his own work?
>
>            John.
>
>


I previously wrote this
>
>
> Please view this in a fixed pitch font so that the table columns line up.
> Otherwise it will make no sense at all!
>
> The method:
>
> We take our cipher alphabet to be acdefghiklmnopqrsty.
>
> The phrase from Jacques Guy was:
>
> "Could you take another shot at explaining your approach"
>
> First we need some simple rules. So we will assume that f & p are
> paragraph start markers. We now have two choices for start character.
>
> Let us use f in this instance. We now have an output string that
> starts with f...
>
> At this point we need to make a choice for the second character.
> This pair will make up the initiator. Let's choose fa as this starts
> page one of the VMS.
>
> Now we have fa. This will become the first element in our lookup table.
>
> fa
>
> We now need a character to complete the triplet to represent the c of
> the word could. In this case we will NOT choose c so that we deviate
> from the VMS. We can chose o instead. o now becomes the first letter
> in the list of triplet endings for fa.
>
> fa
> o
>
> As this represents c we will capitalise it place it in the list as
> an output.
>
> fa
> o C
>
> We now have a new pair, the ao of fao. This now automatically becomes
> the second lookup entry in the list.
>
> fa   ao
> o C
>
> To represent the o in 'could' we now need to complete this triplet.
> Let's try i.
>
> fa   ao
> o C  i O
>
> Now we get faoi. If we skip a few steps to complete the word we will
> have a table and output thus.
>
> fa   ao   oi   ii
> o C  i O  i U  i L
>                n D
>
> faoiin
>
> This shows the recursive nature of the algorithm as the pair ii can
> complete to both iii & iin within the same word.
>
> To start the next word we need to define an inter word initiator
> triplet. This triplet CAN be mid word but because of language
> structure may tend to only appear inter word. We already have the
> start pair of this triplet using the in ending of iin.
>
> As the form in.s seems to appear quite a lot in the vms we will
> use this here
>
> fa   ao   oi   ii   in
> o C  i O  i U  i L  s
>                n D
>
> The second word of the plaintext is you so y will appear as the output
> here. The table now becomes thus.
>
> fa   ao   oi   ii   in
> o C  i O  i U  i L  s Y
>                n D
>
> We have a word form .sho. in the VMS so we will use this to complete
> the word you.
>
> fa   ao   oi   ii   in   ns   sh
> o C  i O  i U  i L  s Y  h O  o U
>                n D
>
> This now produces the output
>
> faoiin.sho
>
> To review a little. The combination fac initiates the sequence and
> also represents the plaintext letter c at the start of a paragraph.
> aoi will always represent the plaintext letter o, oii the letter u
> and iii the letter L etc. These depend upon the sequence leading up
> to the related letter. If a different path is taken through the table
> then different triplets will represent these letters.
>
> This is seen in the letter u in could and you. In could u is represented
> by oii and in you by sho. The path to the plaintext letter is different
> in each case.
>
> Let's continue. We now have the words 'could you.' The next word is
> 'take.' We have ho as the new pair from the sho combination. This is
> the next inter word triplet. A quick scan through the EVA sample shows
> that c, k, s & t are the most popular cipher letters to complete
> the inter word triplets. Let's choose k. If we want to reproduce a
> four letter EVA word to represent take we could choose something
> like kair or kshy. To improve the statistics for the ai pair and
> increase recursion we will choose kair. We now get this.
>
> fa   ao   oi   ii   in   ns   sh   ho   ok   ka   ar
> o C  i O  i U  i L  s Y  h O  o U  k T  a A  i K  r E
>                n D
>
> faoiiin.sho.kair
>
> This completes the encipherment for the partial phrase 'could you take.'
>
> As an excersise try completing the whole phrase by mapping in existing
> EVA words of the same length. dain, daiin, dair or any other EVA grouping
> can be completed easily. These patterns should echo through other words
> with the same endings later in the text (as long as the path that got you
> there comes from the same initiating sequence.) A high degree of recursion
> seems to be necessary to produce true voynichese, requiring a lot of short
> loopbacks to previously used pairs.
>
> Hope this helps. If not let me know. All comments welcome. BTW once a
> plaintext
> is entered into the table this also becomes a lookup. For instance if the
> last
> enciphered text ends oii and the next plaintext letter is L or D then it
can
> be
> seen from the above table that the sequences iii & iin are already present
> and
> do not need to be compiled. The last letter is simply inserted as a
> replacement.
>
> This cipher method grows and evolves as the text is enciphered, but can be
> restarted and subtly changed at will. This could be per page, per section
or
> at the whim of the author.
>
> Jeff
>
> P.S. In Nicks table he seems to use loopbacks too. Where certain letters
can
> appear
> at ends of words as well as in the middle. This method simplifies the
> ruleset used for
> these mappings if nothing else.
>


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