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?

  • $\begingroup$ 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? $\endgroup$ – mikeazo Sep 1 '16 at 13:46
  • $\begingroup$ 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 :) $\endgroup$ – 8924th Sep 1 '16 at 14:00
  • $\begingroup$ 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?), ... $\endgroup$ – tylo Sep 1 '16 at 17:42
  • $\begingroup$ 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 $\endgroup$ – tylo Sep 1 '16 at 17:42
  • $\begingroup$ @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 $\endgroup$ – 8924th Sep 1 '16 at 21:46

The fact that as is, your cipher results in predictable ciphertexts when the plaintexts are similar and have same lengths does not inspire confidence. So while there are things you can do to try to "patch this up", there are likely fundamental issues with your cipher that patches will not really fix.

That said, I would suggest random padding for your cipher. Have the last byte indicate how many bytes of random padding are added to. So you would have something like this

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

How many bytes of padding to add should be randomly chosen.

|improve this answer|||||
  • $\begingroup$ That.. is actually pretty solid. And to think I had already read on the practice of padding the plaintext for block-based ciphers, but now I can't even remember why I considered the same approach impossible on substitution types. It's simple enough to implement and has the added benefit of producing truly random ciphertext from the exact same text and key. It was right under my nose the whole time.. I will implement the modification shortly and if all goes as planned, I'll be marking this as closed. I feel embarrassed for having missed it honestly. $\endgroup$ – 8924th Sep 1 '16 at 14:09
  • $\begingroup$ Now I understand better what you meant by "patch this up". While making this I have come to realize that while this method helps a bit, it's not true randomization since all it does is variate the message length. While the padding does depend on the key itself, it would still be a matter of time for the cipher to be broken. At this point I don't suppose there's much else I can try while still calling this a pure substitution cipher. Unless there's something else you can suggest for me to try or read, I do believe this is as far as this one goes. $\endgroup$ – 8924th Sep 1 '16 at 16:25
  • $\begingroup$ I wanted to edit my last comment but it timed out. Anyway, I was thinking that my linear substitution process is one field I could improve upon to counter this issue. Preferably this would all be all be done within a single pass, but if not, then i'll have to feed the output back into the encryption process and start from different points with different directions. Deciphering is gonna be more complex but it should eliminate predictability. --- I don't know if it's alright to post updates through comments like this, so if it's against the rules feel free to close this. I appreciate the help :) $\endgroup$ – 8924th Sep 1 '16 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.