Is it possible to implement AES with a block size of 64-bit I / O?

Question

I am working on an application with a very specific encryption requirement:
We must encrypt / decrypt individual 64-bit values ​​to protect some parts of our internal architecture from reverse engineering through our public web endpoints.

The problem is that the existing 64-bit encryption methods (for example, 3DES) are not strong enough to meet our requirements (as far as I know).
They also perform slower than AES, which is another pain.

My question is: can we implement AES with a 64-bit block for input and output?
Should we create a modified AES algorithm? (If we do this, this is not a common throw).

Answer 1

AES is only defined for 128-bit block sizes. If there was a way to reduce the block size, it would not be AES. Block cipher is not the only thing that determines what you can encrypt. The mode of operation determines how the block cipher is applied.

If you have clear text of a limited size, you can use AES in streaming mode, for example , CTR mode (which encrypts the counter and XORs the resulting block with clear text). Encrypted texts in this mode have the exact length as plaintext. The only problem is that, for security, nonce (IV) must be unique for each encrypted text under the same key. If your system can track nonces (they can be simple 96-bit global counters or even 128-bit global counters, if the plaintext does not exceed 128 bits), then you can fulfill your requirements.

CTR Encryption:

Answer 2

Not. AES is defined by four basic operations on a 4x4 matrix: SubBytes, ShiftRows, MixColumns and AddKey.

"8 bytes AES" will be fundamentally different encryption. Especially the ShiftRows and MixColumns operations are based on the concept of a square matrix. Therefore, the block size of any "AES-like" block cipher should be the square N (4, 9, 16, ...).

Answer 3

If you have 64-bit input, you can add another 64 bits of removable padding to get 128 bits. Encrypt 128 bits, usually with AES. When decrypting, simply remove the add-on after decryption. There are several different possible fill patterns. You will find some, such as PKCS # 7, built into many AES libraries.

When using fixed-length 64-bit input, you can use random padding if you always knew which 64 bits were data and which 64 bits were padding. Mixing the two will be detrimental.

ETA: with 64-bit values, you can combine two of them to make one 128-bit value. After decryption, divide them into 64-bit.