[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: VMs: Word Endings



Jeff wrote:
>
> I have tried an online auto-key cipher in java and this is not
> auto-key. You
> must have misunderstood. The plaintext is a key but not an auto key. The
> encoder can change the path or key at any time and produce a significantly
> different pattern to the text. Hence the change in 'languages'. With this
> encoding it is possible to produce at least x number of different
> 'languages' at will using exactly the same plain text. Where x is
> the number
> of letters in the plain text alphabet. Does that sound like auto key?

Yes, this still fits my definition of autokey.  Few things in this world
exactly match textbook examples, so a bit of additional comprehension is
always necessary.  Still, this fits my classification of autokey.  I can
see, taste and smell exactly what you're doing, with the few simple lines
you've offered.  Don't ask me why so much goes over my head and I latch on
to odd things like this - your examples are written in a language I can
understand, and that's enough.

You have one thing going for you, simply that you meet my first
pre-qualification for a workable VMS cipher, that being that it must have a
high degree of user interactivity built into the system.  Installing a host
of such mechanisms is simple, but extracting usable information back out of
these systems is another matter.  You've also met one of my early
observations, that being that the first glyph on any page designates the
'structure' of that page.  This is too important for me to go any further
on, but suffice it that this exists, and you've stumbled onto it.

GC









>
> The following is from an email I sent earlier (with corrections
> to my typos)
>
> F1r.p1
>
> Fourth word attain. Different ciphers from reverse encryption
> table version
> 1.
>
> attain (selected path in VMS)
>
> qdqszy, sbsqav, fofdni, peptyz, gngcoh, hmhbpg, u'uoct, xyxmer, ofoux',
> rcrr'x ,'u'jho, tatpbu,
> dqdflk, zvzkgp, epeemj, mhmxub, crcgkl, bsbhjm, jkj're, lilytc, vzvnds,
> iliaqf, kjkzsd, yxylfq.
>
> There will be twenty six versions of any word (assuming english alphabet).
> This example was not
> compiled with a useful table. It will not decrypt yet. It is an example of
> use of the table. The onerous task is to find the right order for both the
> alphabet table and the glyph indexes. Would anyone like to help?
>
> >
> > Correct me anyone, if you think I'm wrong, but what Jeff is describing
> here
> > is a first-character-initiated (non-keystring) auto-keyed look up table
> > constructed from a standard Vigenere tableau.  Before you get
> too excited
> > about this idea Jeff, I suggest you enact your ideas on a standard
> construct
> > and view the results.  I'm not certain if I ever checked for this in the
> > past, but I'm certain that auto-key cannot be responsible for
> the VMS text
> > statistics.  Auto-key leaves a signature that I don't see present in the
> > VMS.  Of course, I've been wrong before, will be wrong again,
> and oftimes
> > rejoice in my own dim light.  Google auto-key cipher, and find out about
> > what you're testing.... and keep us informed on your
> discoveries, always!
> >
> > GC
> >
> > ______________________________________________________________________
> > To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
> > unsubscribe vms-list
> >
>
> ______________________________________________________________________
> To unsubscribe, send mail to majordomo@xxxxxxxxxxx with a body saying:
> unsubscribe vms-list

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