Re: VMs: RE Analysis of word dependency ...

[Nick Pelling <incoming@xxxxxxxxxxxxxxxxx>]

Hi Chris,

> RE Analysis of word dependency
>                                   Couldn't strong dependency between
> the final of the previous word and the initial of the next word also
> indicate obfuscation of individual words by arbitrary insertion of
> spaces -  lik et his (like this) ?

I've found a few examples where it looks as though a frequent letter-pair 
may have had an arbitrary space inserted (or moved around).

For example (...opens CopyFlo at random...), f15v line 2 has <or oro 
raiin>, which would seem far more likely to really be <or or or aiin>.

However, I think that if you build up a set of (say) 50-60 Currier-groups, 
you will find that adjacent-yet-split versions of these are very rare (I 
don't have a definitive list, sorry) - deciding whether these were put in 
for obfuscation or were merely scribal errors may require more data.

I think f15v line 2 is interesting, as writing <or or or raiin> instead 
might have made it obvious (to a code-breaker) that the text was structured 
in pairs... if this is indeed an example of the obfuscation you're talking 
about, then this does indeed point to an underlying pair structure.

You have to be careful with your logic here because if the underlying 
alphabet is largely expressed as a set of pairs, you may well get a large 
number of apparently structural artefacts, which are merely internal to the 
cipherbet itself. For example, if I were to build a VMS-like paired-glyph 
cipherbet of my own...

        a       <-->    ol
        b       <-->    dy
        c       <-->    of
        d       <-->    ok
        e       <-->    ee
        f       <-->    or
        g       <-->    on
        h       <-->    op
        (etc)

...then I might well end up with a large number of *apparent adjacency 
rules* which are actually alphabet-structural (ie aren't 
syntactic-structural and aren't semantic-structural). This is a very 
significant possibility here, so shouldn't be ignored lightly.

> 1. Assume that each pair of 'letters' in the VMS codes for a single
>    deciphered letter, (please forgive me if the terminology is wrong)
>    so letter 1 and 2 in the VMS gives the 1st decyphered letter,
>    letter 2 and 3  in the VMS gives the 2nd deciphered letter etc..

Can I please ask you to output your Currier adjacency-matrix in a slightly 
different way?

If you were to normalise each table-entry value into a percentage, and then 
merge the two tables so that each pair of similar values is adjacent, ie 
something like...

                a       b       c       d
        a       80/70   12/10               (%age without space / %age 
with space)
        b       0/0     1/5
        c
        d

...it should make it much easier to see what's going on between the two 
tables. :-)

Thanks, .....Nick Pelling.....

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