In AES-256-CFB, does using a pseudo-unique key circumvent the weakenesses of reusing keys?

Question

Disclaimer: I'm not very familiar with the subject. Apologies for how that reflects in the question.

Goal: Encrypt multiple messages using the same key

Hypothesis: If we use, as the actual encryption key, a reused secret key concatenated with a publicly known yet varying (and never repeated) part, would that prevent exploits based on key reuse?

For example,

INPUT

- secret_key
- plain_text

ALGORITHM

- pseudo_key = SHA(plain_text) + secret_key
- initialization_vector = SHA(plain_text)
- encrypted_message = SHA(plain_text) + Encrypt_AES-256-cfb(pseudo_key, plain_text)

DECRYPTION would naturally be:

plain_text: Decrypt_AES-256-cfb(SHA_part_of_encrypted_message + secret_key, remaining_of_encrypted_message)

Let's suppose a resourceful attacker knows the algorithm and has access to 100 used messages

Would he/she be able to crack them? (taking into account the procedure above, and specifically, that the secret_key is the only unknown)

If he/she would, could a different base encryption algorithm make this stronger? Or another method/procedure?

I assume that this doesn't make it any safer, otherwise a similar procedure could be incorporated in the encryption algorithms themselves.

Nonetheless, it is not clear to me how some attacks mentioned in the context of key-reuse could work given that the actual encryption key would be different.

Is there any mode of operation of any modern cipher - if needed in combination with a procedure like the above - that allows us to reuse the same "secret" key without introducing vulnerabilities?

EDIT

(in light of Paul Uszak comment about a leaky initialization vector)

If I understand correctly, the comment means that according to the procedure above identical plaintexts will have the same initialization vector and key (which is constant, "by pre-condition/setup") and therefore the same encrypted text, which in turn is a weakness (?).

Assuming this interpretation to be correct, I'd like it if we could consider the following adaptation to the procedure:

INPUT

- secret_key
- plain_text

ALGORITHM

- R = randomNumber (e.g. Rand(0000-FFFF))
- pseudo_key = SHA(plain_text + R) + secret_key
- initialization_vector = SHA(plain_text + R)
- encrypted_message = SHA(plain_text + R) + Encrypt_AES-256-cfb(pseudo_key, plain_text)

DECRYPTION:

- plain_text: Decrypt_AES-256-cfb(SHA_part_of_encrypted_message + secret_key, remaining_of_encrypted_message), with SHA_part as IV

Note that:

• "R" could be used only in the initialization_vector (and not in the pseudo_key also). I used it in both to "simplify" the full message transmitted. Please let me know if either including it or not in the key part impacts strength/vulnerabilities in any way.
• Perhaps "R" could be a "top-level part" of the initialization_vector (instead of part of the argument of the SHA). But I'm not sure whether the fact that the attacker knows how the SHA of the plain_text and the random number are combined to form an initialization_vector (the whole procedure is public) would help "cracking something", having access to multiple encrypted messages (with the same sacret_key, same plain_text, and where the random number would also be transmitted "publicly").

In any case, focusing on the actual procedure, and not in the notes above:

Would this random component make the procedure stronger?

Evaluating the procedure as a whole and going back to the initial question:

Does this procedure circumvent the weaknesses of reusing keys when the attacker has access to multiple messages encrypted using the same base key?

Thanks in advance.

Answer 1

Goal: Encrypt multiple messages using the same key

That's what an IV is for! You can mitigate all the dangers of key reuse by using a unique initialization vector. The reason they exist is so that you can encrypt multiple messages without needing to go through the expensive process of changing keys (whether by generating a new random, truly independent key or by expanding one key into a number of keys with an algorithm like HKDF).

Hypothesis: If we use, as the actual encryption key, a reused secret key concatenated with a publicly known yet varying (and never repeated) part, would that prevent exploits based on key reuse?

Your entire scheme is excessively complex and I haven't analyzed it. What I can say though is that you usually can concatenate a secret key with a public counter or other unique identifier and still treat the key as secure. A vulnerability that allows an attacker to violate some security principle of the cipher when multiple keys are used that are all secret but which differ in specific known ways is called a related key attack. Only ciphers that are badly broken, such as RC4, are vulnerable when used this way.

There is a better, standard way to expand one key into multiple though, and that is HKDF. It is a hash-based algorithm which expands a single key into any number of unique keys that can be treated as independent. This is useful because you don't have to sacrifice any part of the key by turning it into a public value. You can start with a 256-bit secret and derive any number of 256-bit secrets.