6
$\begingroup$

How much harder is it to determine the secret key for a mono-alphabetic substitution cipher, if each word is translated into a different language before the cipher is applied?

If somehow computers could create their own language or set of languages such that there is a one-to-one correspondence between words and they are optimized such that the significant information obtained from the multi-language frequency table is minimized, would it result in something better?

$\endgroup$
2
  • $\begingroup$ Is it assumed that the choices of language are kept secret (possibly determined by another key)? $\endgroup$
    – mikeazo
    Oct 1, 2011 at 23:01
  • $\begingroup$ yeah, no one would know for certain the order of languages unless they found the other key $\endgroup$
    – Scott
    Oct 2, 2011 at 19:25

2 Answers 2

6
$\begingroup$

This is a lossy algorithm. You will lose information during the translation and reverse-translation steps. Introducing loss into any algorithm obviously increases the difficulty in pulling the clean plaintext out, since it's potentially impossible to pull the clean plaintext out even with the key.

Even so, fairly normal cryptanalysis should apply here. You just need to use a multi-language frequency table. I assume that all languages involved will use a single alphabet? You would drop accents from languages that have them? This is no different than the common step of merging "I" and "J" in ciphers. If you rely on Romance languages, cognates would hurt you. If you go beyond Romance languages, then you're faced again with possibly lossy transliteration, particularly if you mix in Asian or Middle Eastern languages.

This is not dramatically different than the common technique of intentional misspellings. Take a look at Kryptos for a very advanced example that involves the kind of complications you have in mind.

I'd say that your idea makes analysis harder, but not fundamentally different.

When you make this a non-lossy translation, you're describing a homophonic cipher. A book cipher is an example. The idea is that you have different symbols representing the same letter or word. In your case, you're replacing the symbol "road" with either the symbol "rue" or the symbol "camino" or the symbol "lu" for example. You are then applying an alphabetic cipher to the result. This has been used for a several hundred years to prevent frequency analysis. Look at the Great Cipher for a sophisticated version of this approach. Note that as you've describe it, I strongly doubt you'd be able to devise a group of languages that resisted frequency analysis. You'd eventually have to start creating more random symbols (words) until this looked very unlike the original design in my estimation.

$\endgroup$
0
3
$\begingroup$

First, linguistically this sounds like a stupid idea. Words in different languages don't correspond one-to-one to each other. Try to translate a text with Google translate between several languages and back to see how good this works. And good translation programs have the possibility to look at the context - your word-by-word translation doesn't have this luxury. So, getting the original text back after encrypting and decrypting seems like quite difficult.

Then, while different languages don't have the same letter distribution, similar languages have still similar distributions. Assuming you only use languages with the latin alphabet, for example, you still will be able to identify the set of vowels.

While this might complicate cryptanalysis compared to a single-language monoalphabetic cipher, the added entropy in the key for choosing the translation languages would be better invested in a polyalphabetic cipher. (Assuming you need a cipher doable by hand on paper - if you have a computer, use a modern cipher.)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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