# Reduce AES-CTR malleability impact by shuffling plain text

I need to cipher and decipher text with randomly access. For this I decided to use AES in CTR mode which is a good compromise between CBC and GCM.

But CTR mode is malleable. It is not a big problem because texts that I will cipher have not predefine patterns and I don’t need authentication, I just want to avoid the ability to read the plain text for an attacker.

However, I want to reduce the ability to an attacker to really use the malleability property of CTR.

Here my idea to do it:

public static void main() {
Key key = …;
IVParameterSpec iv = …;
int rSeed = …;
byte[] plainText = …;

AESBlock[] toCipher = cutIntoAESBlock(plainText);

for (AESBlock aesBlock : toCipher) {
byte[] shuffled = shuffle(aesBlock, rSeed);
byte[] encrypted = encryptAES_CTR(shuffled, key, iv);

…

byte[] decrypted = decryptAES_CTR(encrypted, key, iv);
byte[] unShuffled = unShuffle(decrypted, rSeed);
// Here the content of unShuffled must be equals to aesBlock content.
}
}


Suppose that methods shuffle(…) and unShuffle(…) are complementary and one reverse the other.

The shuffle step is here not to cipher a 128 bits AES block but just shuffle the order of bits of it in that way it reduces the impact of modifications done on the ciphered text by an attacker because if an attacker changes a part of the ciphered text, the modifications will be spread during the unShuffle phase and will change the content and the chance that the new content can be exploitable is reduced.

In that way, CTR mode is always malleable but ciphered text modifications impact are reduced.

It is just an idea and I write this post to know if this idea is really useful or if it is useless and just superficial step which does not reduce the impact of modifications that can be done by an attacker on the ciphered text.

I know that there is the GCM which provides authentication and therefore, is not malleable. But I don’t really need it and GCM cannot be accessed randomly especially if I want modify and re cipher just a part of the plain text.

Kerckhoffs's principle (or at least it's modern interpretation) says that we assume the attacker knows the general algorithm, but not the key. So if the attackers knows the shuffle algorithm, then they would know what bits to change in the shuffled data. The net result is that you gain any security.

So if you want to avoid malleability, then you will have to choose a different mode.

As far as being able to read/modify just part of the data, you can look at full disk encryption (it's also worth looking at this article on XTS) where the data is divided into blocks. Only full blocks are read and written. But note that on a disk each read/write will often be 4096 bytes (exact value depends on the disk and operating system). So reading from a file, modifying the data, and writing it back to the file will involve reading/writing that much data regardless of how much data you intend to change. The time necessary to encrypt/decrypt a block is typically much less than the time necessary to read/write the disk, so processing entire blocks won't slow down your system by very much.