How can I mitigate against chosen plaintext attacks for AES ECB?

Question

I am developing on a platform where my only encryption option uses AES ECB. The encryption is used to protect parameters that the user can set, and so it susceptible to a chosen plaintext attack. It's not a cookie, but similar; the user enters credentials, which with other data is sent to the server for authentication and authorisation.

What steps can I take to make the chosen plaintext attack impractical?

Specifically, my current proposed mitigation is to add random "fill" before and after my meaningful content. The encrypted blob will look roughly the same length, but the place where the ciphertext from the chosen plaintext appears will be different for each call. At this point the communications are low volume, so I am less worried about the efficiency, size or processing time of the data. Is this an effective mitigation?

Alternately I could consider randomising the order of the fields (the plaintext is JSON). That's a bit harder to implement. Would this make the attack impractical?

I have read and think I understand this great question and answer.

Answer 1

The simplest way of dealing with this I can think of is to more or less implement CBC mode yourself. All it requires is for you to be sure of the block size used:

• Build a random (and unique) IV of the same size as the AES block size (128 bits).
• Encrypt that block and store the result (let's call it A)
• Build a chain of 128-bits blocks containing your actual message (add padding as needed).
• For each block in that chain, XOR it with the content of the buffer A and encrypt it individually. Store the result in your output buffer and replace the content of the A buffer with it as well.

In order to decypher the data, you decrypt the first 128-bit block and store the result in a 128-bit buffer. You then take each 128-bit block thereafter, decrypt it, XOR the result with the content of buffer A, store the result both in your output buffer and in A and move to teh next block.

You then remove the pad and you're done.

Edit: One word of warning:

The best way would be to use a standard library instead of toying with code like this.

By doing what I suggested, you're running a rather severe risk of adding some vulnerability to your implementation: although I fully understand your need to work with specific limitations, you need to be aware of the fact that you are quite likely to end up with code that is vulnerable to some kind of attack (although it might be more resilient than the initial implementation).

Furthermore, if you rely on code that use ECB mode, it means that the author of that code had no understanding of modern cryptography and therefore probably contains other basic errors.