Unless you can present the code you have written to decipher any document I post in encoded format here, then I think we all will reserve our opinions of what you have said until you can back them up here.

Speaking for everyone, are you? I'll just let that embarrassing line speak for itself.  :-)

As to the rest:

1. What I said is that in your original post you used the term "encoding", not "encrypting". No code is needed to back this up, as those are the words in the post.
2. I also complimented Anonymous Monk's warning to any future hobby crypotologists who might find this thread that they would be wise to avoid simple substitution ciphers. No code is needed to back this up, as simple substitution ciphers are generally considered "easy" to break by cryptological standards, and anyone who needs that proven with code is, I suspect, Google-impaired.
3. I also said that I downvoted your post at node 1123638 because it was childish. No code can back that up, for the assessment is subjective in nature. I suppose it might be possible to write code proving I downvoted the node, but I seriously doubt that needs proving. Eighteen of my fellow Monks, as of this writing, also downvoted it, and their opinion likely matters more to me than yours ever will.
4. You then introduced the concept of somebody breaking your code. As I never mentioned anything about it, there is nothing to prove and no code to write.

And, since you seem to have troubles with comprehension of what you read, I'll add that I was defending your original post.

In an effort to be thorough, I respectfully decline your invitation to write code to break your encryption.

While I have cracked some interesting ciphers in my younger days, I was always far better at designing encryption algorithms than decryption attacks; I can't imagine that's changed much since my last serious effort in that space (which was 1985, if memory serves).

And I'd barely qualify as even a hobby cryptologist these days, my last gentle effort in that space probably being around 2003 or so. And the exercise we went through then had restrictions of a type completely incompatible with what you propose -- we had to use a system that could be reasonably remembered by a normal human, and employed without a computer or a calculator (or eating up a ream of scratch paper). Neither a computationally nor algorithmically tasking effort, to be sure. It did, however, present the team with some interesting challenges in usability and efficiency; lessons which I hope they took forward with them in their careers.

So -- if I've failed to address any of your otherwise mostly irrelevant points, feel free to re-raise them. I may or may not respond, as my mood and time permit. If you show no signs of improvement in your maturity in your next response, as compared to the previous two I've addressed, it will be more than abundantly clear that you aren't worth the time it takes to hit the reply link -- much less craft any actual response.

I will reiterate, even though you will probably find some way to take this compliment as an insult, that the code you presented in the original post was pretty cool, and even got me thinking about a few things I might do in my spare time to employ the concepts you presented.

So, in case you make it impossible to be worth responding to you, I'll end with this: Thank you for sharing the original code -- there's no small amount of cool stuff in there, and lots of potential applicability. In that, at least, your contribution to PerlMonks is appreciated.

Your example answers a question I had about how this would actually be used, and it certainly is much more secure than I had initially assumed. However, it requires that your correspondent update their database every time you send a message. Yes, you can send your encrypted messages in the open but they will be logging in to the secure FTP site anyway. Why not just deliver the messages that way and skip the whole encrypt/decrypt? You will save a lot of time and effort.

There is a sound basis for NOT sending your messages in the open, even encrypted. Historically, a great deal has been revealed by learning who is talking to who, and the timing of their messages, without reading a word of the plaintext.

Your challenge to decrypt a message is truly childish, and demonstrates a poor understanding of the topic. Those methods only work on a body of data, not 1 or 2 messages.

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.