# Should I add randomness at the end before AES?

Seen AES, changing a character drastically affects the encrypted text. I want to make it harder to decrypt AES I send. So, it seems this can be done by adding some special code and some random bytes RNDBYTES at the end of plaintext, and when decrypting removing the ramdomness after the special code. This way encrypting the same text will look different, which is what I need. But is this secure? Should I use a special algorithm for this or a CSPRNG is enough? How long should it be?

I'm using it in CBC mode, but the implementation doesn't add the randomness I want, the same message when encrypted looks the same. But the receiver of the encrypted code should be able to decrypt knowing the key without the need to know the RNDBYTES. This is just to prevent someone smart outside the connection to observer the repetition pattern.

Edit: A hacker might know other ciphertext AND some parts of the plaintext.

• Use a random IV. – CodesInChaos May 16 '16 at 16:04
• @MaxTheBackspace Yes. The IV is prepended to the encrypted data, so it's available to any attacker. If the IV isn't made public, then it's going to be difficult to use a different random IV for each message. – r3mainer May 16 '16 at 16:19
• the reciver of the encrypted code should be able to decrypt knowing the key without the need to know the RNDBYTES — This is wrong. The IV affects every block of the ciphertext. – r3mainer May 16 '16 at 16:49
• But is RNDBYTES still secure? – MaxTheBackspace May 16 '16 at 16:52

I want to make it harder to decrypt AES I send.

Fundamentally, the thing you are trying to do is completely unnecessary. If AES does ever become broken, the scenarios in which this makes any measurable difference are exceedingly unlikely. If AES isn't broken, then doing this was wasted effort in the first place.

There is zero plausible reason why your idea would make AES harder to decrypt in any scenario.

Virtually any other use of your time would be better spent. AES, when used correctly (e.g., a well-regarded mode like GCM, non-repeating nonces, and a cryptographically random key or strong password with suitable PBKDF), is going to be the strongest part of your cryptosystem by multiple orders of magnitude. Focusing extra time on this part of the problem is, to paraphrase Bruce Schneier, like protecting your house by planting a single stake into the ground and hoping the attacker runs into it, instead of building the rest of the fence.

Edit: Upon rereading your question, it appears you're gravely misusing CBC mode by using a static (or no) initialization vector (IV). An initialization vector should never be reused between encryptions with the same key. Additionally, CBC IVs have the requirement of being unpredictable to an adversary. Your encryption library should have a function to set the initialization vector before encrypting any plaintext, and before decrypting any ciphertext. Generate one with a cryptographically secure random number generator, pass it to your encryption library, and then send the IV alongside the ciphertext so the receiver can decrypt it.

• Your answer is fully right, but doesn't answer the question of the OP. In my opinion an answer should always answer the asked question, even if the question itself is based on not needed assumption. – Nova Jun 12 '16 at 23:23
• In that case, the simple answer is "no". – Stephen Touset Jun 12 '16 at 23:53
• Yeah, but an explanation would be good, containing things like that random bytes at the end of the plaintext only change the end of the ciphertext in CBC mode. – Nova Jun 13 '16 at 0:36
• In my opinion, answering questions like this with responses like that just encourages the whack-a-mole of "well, should I prepend randomness then?" The deeper answer is that no, you shouldn't try and be clever because a) the designers were smarter than you, and if it were necessary or useful it would already be done for you, b) you're more likely to fuck up catastrophically than achieve any meaningful benefit, and c) even before implementation, your approach has undefined security properties until demonstrated otherwise, and undefined is way more likely to be bad than harmless or good. – Stephen Touset Jun 13 '16 at 1:56
• A good answer contains both, a real answer to the question and a guildline like your answer. – Nova Jun 14 '16 at 13:00

"I'm using [AES] in CBC mode, but the implementation doesn't add the randomness I want, the same message when encrypted looks the same."

This is a problem. If you were using CBC mode correctly (i.e. with a random IV), then encrypting the same message twice would produce completely different ciphertext.

Since you're not using CBC mode in the way it's supposed to be used, it can leak information to an attacker. There are several different ways in which this can happen, but the obvious one, which you've already noted, is that using CBC mode the way you're (mis)using it will reveal whether two encrypted messages are the same or not. (In fact, using CBC mode like this will also reveal whether two message share a common prefix of at least 16 bytes, and approximately how long any such common prefix is.)

Fortunately, the fix is simple: as long as you choose a random IV for each message (using a cryptographically secure random number generator), CBC mode is provably semantically secure as long as the underlying block cipher (AES) is unbroken.

Alternatively, if you don't trust your random number generator to be secure (which may be a reasonable thing to doubt; it's hard to verify that a RNG really is secure, and there have been some notable cases where a supposedly secure RNG actually turned out to be completely insecure), then you can instead take a unique message identifier and encrypt it to generate the IV. Or, equivalently, you can use a fixed IV and prepend a unique plaintext block to each message.

Ps. Note that, in any case, CBC mode encryption alone will not protect your encrypted messages from modification, or from attacks involving forged or modified ciphertext (like the well known padding oracle attacks). To be safe from such attacks, you really should include a message authentication code (MAC) with your messages, and verify it before attempting decryption. Or, alternatively, switch to an authenticated encryption mode that combines encryption and message authentication into a single operation.