Should I add randomness at the end before AES?

Question

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.

Answer 1

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.

Answer 2

"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.