# Same-length plaintext results in predictable ciphertext. Can a substitution cipher avoid this issue?

I started with a basic mixed-monoalphabetic substitution cipher. To work against predictable ciphertext generation, I introduced a modulo in my cipher whose purpose is to scramble the substitution in such a way that would render frequency analysis impossible. So far I believe I have been successful, but only up to a point.

The reason I called on all of you for help is because I can't think of a way to solve a same-length/similar-text scenario. For example:

test  > X0{.
testa > (*ks?
tess  > X0{f


The ciphertext results for messages that are of similar content but have the same length are predictable, and so long as this isn't rectified my cipher would continue to be weak by all interpretations of the word.

Are there any suggestions as to what I could/should try to fix this?

• Ultimately, what is your goal with this cipher? Are you hoping that everyone around the world will use it, or is it just a toy cipher you are using to learn with? – mikeazo Sep 1 '16 at 13:46
• Considering i've been dealing in cipher lingo and practices for roughly 2 days, I'm mostly curious to see how far far I can bring a simple system to something that offers an ounce of security. It's an interesting challenge to design one and I learning even the basics is a welcome addition to my background in programming :) – 8924th Sep 1 '16 at 14:00
• Classical ciphers are a really good exercise to get into the basics of cryptography, but keep in mind they offer no relevant security from today's point of view, you can also check out the history of cryptanalysis to put this into context. Your claim "that would render frequency analysis impossible" is probably false (my guess would be, you have a version of Vigenere?), ... – tylo Sep 1 '16 at 17:42
• and I would like to point out a popular statement by Bruce Schneier, saying that everyone can design a cipher, which he can't break himself. It's difficult to design one, which no one else can break. One step for further improvement would be to actually state how your encryption works, because if the seurity relies on keeping the algorithm hidden, that's quite bad. See Kerckhoff's principle – tylo Sep 1 '16 at 17:42
• @tylo I'm well aware of kerckhoff's principles. The OP used to be a lot longer and detailed with my implementation to help understanding but it was immediately branded as off topic so I had to cut it down to 1/5th. I'm well aware my cipher is breakable, it's symmetric mixed-alphabetic; my aim, however, is to see how far I can push such a simple concept. Ideally, a "pain in the ass" rating is what i'm after. The code is here but I'm afraid going into details about the language itself is not gonna work in a tiny comment box :P – 8924th Sep 1 '16 at 21:46

<plaintext> <random padding of up to 255 bytes> <1 byte indicator of how many bytes of random padding there are>