Short version of the backstory
A college professor of mine stated that one could not come up with a single-step encryption method that used an algorithmic process (as opposed to pre-shared randomization, like a one-time pad) to reliably and un-crackably encode messages, insisting that the better method would be to layer multiple methods with entirely different processes so that a code-breaker would not get any meaningful results from their attempts. That, aside from meeting in person and sharing one-time pads, you couldn't put out something that was secure against a persistent and well-equipped codebreaker. I, being young and stupid, disagreed.
I started by developing terrible methods. For example, rather than a standard shift cipher of a set amount, I tried doubling the value of each letter in the message. Yeah, like I said, stupid. But, from there, my process grew.
Ultimately, I came up with a system that I think works pretty well. I would love to test it out on someone, but my local area is not exactly brimming with cryptanalysts. So I present to you, Stack Exchange, the beta version. It is simpler than my actual process in several ways, but follows the same general process. I fear the full method may be too difficult, so let's see how this goes.
Are you done talking yet, MisterB? Get on with it!
To be clear, the same encryption process is applied to each of the following examples, and is the same as it would be when applied to any message. When I say "a single process," I mean that it is not a combination of multiple alterations/replacements/etc. It could be "shift first letter up one, second letter down two, third letter up three..." (which it ISN'T), but that's still a single instruction as it could be explained in general for the Nth step, as opposed to "Vignere the message, then AtBash the message, then Playfair the message." Hopefully I'm explaining that well enough.
Here are a handful of examples of plaintext and the encoded result. I can provide more. I'm putting them pre-formatted so there's no ambiguity in the letters (upper-case I vs lower-case L, for example). Note that this formatting is not important, and it could just as accurately be handwritten in cursive, or presented in any other font or format that was legible.
No pre-shared key is necessary. There is no password that must be known to encode or decode the messages. Everything necessary for any message is present in the message itself, and receiving the encoded result is sufficient to find the plaintext, so long as you know the process.
Plain: Sample Encoded version: Wevttn Plain: A longer sample Encoded version: IgNxvjhvfUattml Plain: ABCDEFG Encoded version: Gfhkjgj Plain: ABCDEFGHIJKLMNOPQRSTUVWXYZ Encoded version: Akldfolilotntvsxtrsvbxyazz Plain: This is a test phrase Encoded version: YpkxgNyiEiYj x Phxf m Plain: This is a test phrase with more words Encoded version: TpkzfKxcAbBmuuiVpzjanfDmvleOotefCoxfs Plain: This is a test phrase with even more words in it Encoded version: Bjqu DucAb jxtiQovbsmgDmwnfExhrhVsxlgCptft JsbMu Plain: Stack Exchange Encoded version: ZxbipgHeiohqpi Plain: Puzzling Stack Exchange Encoded version: WcdgojsicVucjliJadmjukh Plain: Puzzling Stack Exchange might solve this Encoded version: Swcdqnqi VwgjphKcfqjunmgMqopzeWrsvkgXkrt
Now for your challenge: I'd like you to show your understanding of the process by doing two things:
1) Decode this:
2) Encode this:
I know how to encode this phrase
Another important thing: you'll want a computer for this. It is technically possible to do by hand, but it would be cumbersome, as with many ciphers. The longer the message, the more difficult it becomes. But the ability to write programs is not at all required. I encoded all of these without any programming (and without using an online encoding/decoding program).
I've seen you folks on Stack Exchange solve some ridiculously complex codes and puzzles using what can be described as nothing less than wizardry. So if anyone can do this, some subset of you can. The "unbeatable" was a bait title, sure. But in upholding my stance against my professor, I'm hoping it can be done with a reliable (but difficult) algorithm to detect. I'd like it if safe encryption can be accomplished this way, rather than simply won by one-time pads.
I'll offer hints if there is interest in the challenge and it remains unsolved, but the Stack Exchange sorcerers may not even need them. And, if this is too easy, I can present my final product and see if that fails in short order, as well. I'd rather you all find it than my professor!