Regarding the final note, expandability -- I had considered what the limitations might be if it were simply reduced to three-digit sequences only -- the encoded textstream could then be transmitted without delimiters (relative to the encoding, anyway).

You might need to introduce delimiters in order to facilitate effective use of the intended transmission media; E-Mail text copy/paste operations often have limits, transmission packets often have fixed sizes which facilitate efficient packet routing if honored, etc., but your system wouldn't need delimiters for its own uses if the keywords were always fixed-length.

And then I hit that wall (okay, more like a hedgerow) of "what happens if we exceed the number of keys generatable in that keylength?"

There are several natural evolutions where this could go, of course; the required keylength could be determined in advance and the chosen length could be encoded directly into the header of the codestream; or a clever mechanism for shifting keysize when needed without specifying the key length on every translation, etc., and so on.

But the ability to simply expand the key by one character to get another order of magnitude of keys -- yes, that kind of flexibility would be an example of good engineering.

One interesting thought as regards direct use of such a system for encryption: Typos would be an interesting variable, often singletons in the stream. I seem to recall that in WWII, the Brits finally started making headway against Enigma (prior to a capture of one of the devices, anyway) when a German operator was forced to retransmit a message (and the Brits already knew the "retransmit" command, so they knew that's what was going on). The second transmission had typos and abbreviations which were not in the original, and doing the rough equivalent of a diffoperation between the sequences finally gave the codebreakers something they could work with. They had already deduced the encryption was likely based on a typeset machine (or whatever the device was called), but it took two almost-identical messages to give them the break they needed to develop an attack scheme against the code.

I'm definitely looking forward to more of your presentations.

In reply to Re^3: Non-Formula based Text Encoding - with Compression by marinersk
in thread Non-Formula based Text Encoding - with Compression by locked_user erichansen1836

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.