0
$\begingroup$

Is it safe to use the same IV when decrypting the exact same encrypted message. From my understanding, there is a security flaw when using the same IV for numerous different messages, as attackers can deduce patterns.

Also is aes-256-cbc the correct encryption method and mode for this scenario. If not, which ones are better?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

First of all IV is decided while encrypting, you must decrypt using the same IV that was used during encryption. So, the question should really be about encrypting same message with same IV not about decrypting.

In CBC mode, using same IV and same key for different messages can help you detect the common prefixes in the message which diverges after encountering the first different block. That's why using same IV is never semantically secure as you can easily see where the messages diverge, that is information is leaked even if you are not allowed to repeat messages. Back to the question and similarly, using same IV and key for the same message will always produce same ciphertext, thus you can easily see repeated encrypted message for seen ciphertext. If this much of information reveal is acceptable to you, it's OK but it may not be OK to everybody.

There is no "correct" encryption mode in this scenario, it depends on what type of security you want and is important that you know the risks involved. CBC mode has some flaws and should not be used unauthenticated. It is vulnerable to bit flipping attacks (flipping bits on ciphertext produces predictable change in the next block) and can be devastating if the application accepts random block just before the targeted block or if it is the first block (in which case you can achieve the same by bit-flipping the IV). Similarly, it may be vulnerable to padding oracle attacks depending on what type of system it is used with and what kind of information it reveals deliberately or unwittingly. My best advise is using authenticated encryption modes like GCM or GCM-SIV.

Using same IV on different message wouldn't be as bad in CBC mode as it would be for CTR or OFB or GCM mode (for these, consequences can be devastating) and using same IV for same message in these modes would pose the same problem, detection of repeated messages due to repeated ciphertext and it all depends on whether if they are OK with it.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks for your extensive response, this makes sense. I should probably change the question to be more specific to my scenario. I want to encrypt the message with some key and IV beforehand, store this somewhere in the app. And when required for use, prompt the user to input the key. Given the correct key, the program will decrypt the message to its correct original message - that is not stored anywhere on the application, for use. For this use case, I can't see how I can decrypt the message to its original message without using the same key and IV. $\endgroup$
    – jayyunit
    May 17, 2021 at 12:45
  • 1
    $\begingroup$ I will advise against that. Key is to be safely stored with proper access control not entered by person. A key is often a random sequence of bits that you cannot expect a person to remember. And a human chosen key will inevitably have low entropy making it vulnerable to guesses. If you write the key somewhere, well it just makes it insecure there and it is much safer to let a program read it than a person. This is not a proper place to discuss how to properly store keys however it can be asked in infosec stack exchange. $\endgroup$
    – Manish Adhikari
    May 17, 2021 at 13:33
  • 1
    $\begingroup$ Yep after digging a little deeper into bash. I can see that it's possible to retrieve the bash history so this is probably not the best idea. I'll take your advice and head over to the infosec stack exchange to get recommendations. Thanks! $\endgroup$
    – jayyunit
    May 18, 2021 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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