# Hypothetical encryption technique, is it secure?

This to me, sounds like a great idea, but with all rosy-tinted ideas it needs some grounding in reality. Here are the steps of the hypothetical system (with the hypothetical part highlighted):

User runs program to encrypt a file.

Prompts for user password.

Hypothetical part (is it secure?):

• Program has a list of encryption techniques stored (assume the techniques are publicly known: they can be any level of complexity but how they encrypt is known) and their decryption counterparts.
• Each symbol in the password selects a different technique (assume what symbol picks which technique are known: it can be changed but the changes are publicly known).
• The program progresses through each symbol in the password encrypting the file with a different algorithm at each stage.
• Each encryption technique can take one or all values from the password: the sum of symbols up to the current position (in the password), the sum of the entire password, and the position. These are used to modify the internal encryption process (the sum up to current position used as part of a modulus, for example). Which means if the letter is in the wrong place, it won't decrypt correctly.

Am I correct in assuming that:

• A longer password adds more layers of encryption in this hypothetical scenario and thus adds more security and thus encourages longer passwords (a double positive trait)?

• Even with the encryption algorithms known, because the password determines what order it's encrypted in, and how many layers, an attacker cannot guess how it was encrypted besides obtaining the password?

• That no file (assuming each password is different) will be encrypted the same way twice?

• The password is the only major vulnerability?

In short, is it secure?

Are there any flaws people could see with this idea?

• An immediate problem is that the size of a ciphertext depends on the size of the password; in other words, the size of ciphertexts leaks the size of the password Oct 8, 2015 at 15:05
• What are the advantages of this over using any existing encryption algorithm? Certainly not efficiency. Oct 8, 2015 at 15:36
• The password is not the only vulnerability. You also have to store a lot of secret keys in a secure way.
– user27950
Oct 8, 2015 at 15:40
• @cygnusv I'm not sure how the size of the ciphertext would leak the size of the password because you'd need the original file as a comparison to know what size it should be normally. Oct 8, 2015 at 18:00
• @bmm6o This isn't about efficiency but security. I'd much rather have a slower encryption algorithm if it ensured better protection. Oct 8, 2015 at 18:00

First, I would like to point you to this answer. Copying the TL;DR from there:

Multiple encryption addresses a problem that mostly doesn't exist.

You are better off using a single well chosen algorithm.

That said, here are answers to some of your questions:

A longer password adds more layers of encryption in this hypothetical scenario and thus adds more security and thus encourages longer passwords (a double positive trait)?

It is not generally true that more layers equals better encryption (cf. Cascade Ciphers: The Importance of Being First). In particular, in those cases where it can be proved that it is as strong as even one of the layers it is assumed that the keys are independent. Your keys are clearly not independent.

That no file (assuming each password is different) will be encrypted the same way twice?

If by "same way" you mean into the same ciphertext, then that is already the case with any secure encryption algorithm (with high probability). If you mean with the same cascade, then probably so, if you have as many techniques as different symbols. I.e. a-zA-Z etc. all give a different algorithm. Otherwise some passwords that differ will still lead to the same cascade.

The password is the only major vulnerability?

No, the algorithms can also leak information about the password through e.g. implementation mistakes or even weaknesses in the algorithm. And the more algorithms you implement, the higher the chances one of them is buggy. As an example of such a mistake:

The program progresses through each symbol in the password encrypting the file with a different algorithm at each stage.

This is probably almost impossible to implement without timing attacks, so in any situation where the attacker would be able to observe how long it takes to encrypt/decrypt something, they could learn things about the password, narrowing down a brute force or dictionary attack even if they are unable to recover the whole password.

If you nonetheless wish to use more than one algorithm to guard against breaks, I recommend:

1. Use just two, always. That is simple enough to limit issues and the chance that both are broken should be small with modern well vetted algorithms.
2. Use stream ciphers (or block ciphers in CTR mode). Their cascade is provably as strong as the stronger if the keys are independent.
3. Use independent keys that you derive from the password using a strong password hash.

For example, you could use AES-GCM(ChaCha20(m)), with keys derived using scrypt.

• Hi otus, thanks for the reply! Why is it "not generally true that more layers equals better encryption"? Could you substantiate this point? "Multiple encryption addresses a problem that mostly doesn't exist." - this is only if it assumes the single encryption is unbroken - regardless of how unlikely. Heartbleed, SSL vulnerabilities, the RSA backdoor, Swordfish, dodgy certs etc are all examples of broken singular encryption algorithms - this solves the issue because even if one file is broken, the rest aren't. Bugs are to be expected in any code, but is the concept secure (assuming no bugs)? Oct 8, 2015 at 18:06
• @JFlynn, Heartbleed and many SSL vulnerabilities were not due to broken encryption algorithms, but incorrect implementation (a buffer overflow in the case of Heartbleed). Those issues become more likely, not less, if you use multiple encryption. As for why more layers even well implemented is not necessarily better, I'll edit a link or two into the answer.
– otus
Oct 8, 2015 at 18:19
• Thanks for the citation. I don't agree with your answer (even your source says the cascade is "at least as strong" as the strongest component - implying that it can be and is stronger than the strongest component suggesting multi-layers are a good idea), but you put in the most effort. The common suggestion is the ciphertext could be analysed to deduce password (but if you figure that you probably already know the original text at that stage anyway), so I think my primary goal would be to obsfucate analysis of the text. Randomised stacked XOR streams here I come! Oct 10, 2015 at 0:51
• you might want to read your source material. Maybe I entered the twilight zone but your source says: "However, breaking only the first cipher with the oracle's help is equivalent to breaking this first cipher without the oracle's help." That is not logically legitimate. Oct 10, 2015 at 1:14
• @JFlynn, at least as strong as the strongest applies only for commuting ciphers, which is why at the end I suggested stream ciphers. That too requires independent keys, however. If you do end up using multiple layers, you should definitely use key derivation.
– otus
Oct 10, 2015 at 4:06

I think I can spot an implicit assumption that you're making that could easily trip this up:

• Assumption: None of the ciphers is its own inverse.
• Counterexample: Stream ciphers are a popular class of algorithms where encryption and decryption are the same function: encyrpt(key, encrypt(key, plaintext) = decrypt(key, encrypt(key, plaintext)) = plaintext.

So let's assume, for sake of argument, that:

• You naïvely chose all the ciphers in your scheme to be stream ciphers.
• The key that you use for each stream cipher instance are determined by the corresponding symbol in the password.

It gets even worse because stream ciphers are based on XOR of the plaintext with a pseudorandom keystream. And since XOR is an associative and commutative operation, the "self-cancellation" property I mention above implies things like:

• The passwords "ABAB" (or "ABBA", or any permutation thereof) "encrypts" all plaintexts to themselves;
• The password "ABBAS" (or any permutation thereof) is equivalent to just "S".
• We forgot to add your third requirement: "Each encryption technique can take one or all values from the password: [...]."

So any password could be rewritten to an equivalent one that contains only one instance of each symbol that appears an odd number of times in the original. Which means that the set of truly distinct passwords would be equivalent to the power set of the alphabet—so for example, if there's 26 distinct symbols, no matter how long of a password you picked, there'd only be 2^26 truly distinct choices!

This may be a bit of a worst-case example, but I think its one of the easiest to explain of the potential pitfalls. And it only gets more complicated from here on!

@JFlynn - Consider the following scenario: You have a list of 3 encryption algorithms. The first algorithm - let's call it Wonderland - is an unbreakable cipher whose ciphertext is highly recognizable i.e. you can tell at a glance that the ciphertext was generated using Wonderland, but you can't tell anything about the plaintext. The second algorithm = we'll call it LookingGlass - is a strong cipher which preserves characteristics of the plaintext. Maybe it's some sort of anagram cipher. The third algorithm is a Vignere cipher.

You break the Vigenere cipher. You know you've broken it because the resulting plaintext looks like a LookingGlass encryption of a Wonderland ciphertext. That gives you the password. Once you know the password, it's game over.

Do you really think this is stronger than simply using the unbreakable Wonderland cipher by itself? I don't. (Because obviously, it isn't.)

I am no expert in cryptography, so this method of encryption sounded pretty good until you explained how the password was the only thing that seemed to matter.

While this does mean that if someone gets the encrypted password it will be difficult to decrypt. It also means that this method would be very prone to brute force attacks.

This is why RSA is so widely used. If they get the encrypted file it would be almost impossible to get back to plaintext without the private key, an if are forced to brute force it, it will take hundreds of years.