Hypothetical encryption technique, is it secure?

Question

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?

Answer 1

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.
4. Add authentication.

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

Answer 2

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!

Answer 3

@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.)

Answer 4

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.