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

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?

• In short: Are you worried about an attacker recovering the AES key if it is used more than once then? – Paul Uszak Jul 5 at 9:40
• Exactly @PaulUszak . I'm worried that if an attacker 1) has knowledge of the procedure 2) has access to many messages created with the same secret key, Then, the attacker is able to either 1) recover the key, and thus the plain text or 2) recover the plain text, even not being able to recover the key – user1528976 Jul 5 at 10:11
• Ok, but you actually also have a problem with a leaky initialization_vector = SHA(plain_text). The Zeitgeist suggests that repetitive identical messages should be disguised, otherwise they indicate 'same as before'. – Paul Uszak Jul 5 at 23:07
• Hi @PaulUszak please have a look at the Edit. Thks – user1528976 Jul 9 at 1:19
• eheh, corrected :) – user1528976 Jul 9 at 2:18