Is there a form of AES encryption where the cipher text matches the length of the clear text and does not show patterns?

Question

I have clear text, usually less than 10 bytes, which contains a few infrequently changing bytes.

Reading: http://lollyrock.com/articles/nodejs-encryption/ I tried aes-256-ctr:

• The cipher text is as short as the clear text, which is good.
• The cipher text contains patterns, at the positions of the infrequently changing bytes, which is bad.

I tried aes-256-cbc:

• The cipher text length is rounded up to the nearest 16 bytes, which is bad.
• The cipher text appears random, which is good.

Is there a form of AES encryption where the cipher text matches the length of the clear text and does not show patterns?

Answer 1

What you want is length-preserving encryption, which is a special case of Format-preserving encryption.

A standard mode for achieving this FFX mode, which uses a blockcipher, like AES, in a Feistel network. This mode is relatively complex and slow.

But I strongly recommend using normal authenticated encryption over format preserving encryption whenever possible. Format-preserving encryption always leaks if two plaintexts are identical, whereas semantically secure encryption avoids this leak. It also lacks integrity protection, unlike authenticated encryption.

Answer 2

If you look at the definition of counter mode, you will see that it actually turns the blockcipher into a stream cipher:

• The keystream is independent of the message.
• The ciphertext is just XOR of the keystream and the plaintext.

So if you just flip a single bit in the message, you just flip a single bit in the ciphertext if the keystream is the same - I guess that's what you call the patterns in the changing bytes?

However, this indicates wrong usage of counter mode: There is a nonce in CTR, basically it is the starting value of the counter (padded with 0 at the end). And it should never be the same for several messages. The concatenation of the nonce and the counter is the input to the block cipher, and 128 bits (AES) are more than enough that you never have to reuse either (e.g. 96 bit nonce and 32 bit counter, or both with 64 bit).

With a proper nonce, you should get an entirely different keystream for every message, and (under the assumption that a block cipher acts like a pseudo-random permutation, which is the theoretical model for a secure blockcipher) should not be able to distinguish different messages or in fact a ciphertext from a truly random number.

If you don't want to store the nonce (it is the equivalent of an IV in other modes), you could use a message-counter instead: A nonce does not have to be random, it just needs to be unique (never reused - even after restarting the whole process / program).