[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
VMs: RE: VMS evolving table encipherment
13/12/2003 8:20:45 PM, "John Grove" <John@xxxxxxxxxxxx> wrote:
>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?
That would not worry me at all. One just has to redefine the
'alphabet'.
Let us have a closer look (this is the first time in all those
months that we've had a description which would allow me code the
encryption algorithm).
When you have generated <ii> you turn to the "ii" substitution
table to encipher the next plaintext letter. But that next letter
once enciphered, can only be (from memory) <i>, <r>, <n> and
<l> (Frogguy: i, 2, v, x -- I'm not fluent in EVA). Doesn't
look good: far too ambiguous. Solution? Decrete that the
next Voynich character is a null. So whenever you see <ii>
you know that the next EVA letter is a null. Fine with me.
Fine but... it falls down immediately. If this was how
the VMS was enciphered, you would observe that, for
every sequence of two characters (except the "null announcers"
like <ii>) the next one follows the same frequency distribution
as the letters of the plaintext. And in particular, if the
plaintext uses a 20-letter alphabet, you will find a similar
variety in what follows any two-character sequence (except
of course, the "null announcers").
For instance, following <da> you should see sometimes
<i>, sometimes <a>, sometimes <o>, sometimes <n> and so
on, in brief: the whole set of Voynich letters.
Not so at all. In fact, I cannot think of any two-character
sequence that occurs followed by even half of the Voynich
set of letters, let alone the whole of it. And that is
whether you take <iin> as a single letter, or two, or
three.
______________________________________________________________________
To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
unsubscribe vms-list