7

I'm working on an application with a very specific encryption requirement:
We are required to encrypt/decrypt individual 64-bit values, to protect certain parts of our internal architecture from reverse engineering through our public web endpoints.

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

My question is, can we feasibly implement AES with a 64-bit block for input and output?
Would we have to create a modified AES algorithm? (Not a total deal-breaker if we do.)

Giffyguy
  • 20,378
  • 34
  • 97
  • 168
  • 1
    You could probably use 3DES, as long as you use a 192 bit key (168 bit effective) key. That would give you about 112 bits of security. Note that it is often necessary to use a mode that requires an IV or nonce, which may add additional data. Alternatively you could look for articles mentioning *format preserving encryption*. – Maarten Bodewes May 27 '15 at 14:55
  • You could consider another algorithm with 64-bit block size (but 128-bit key), such as MISTY1 (NESSIE selected; CRYPTREC candidate) or Khazad (NESSIE finalist). Or you could use AES in "format-preserving encryption" mode (AES-FFX). – Craig McQueen Sep 12 '16 at 07:18

3 Answers3

5

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

If you have a limited size plaintexts, you can use AES in a streaming mode such as CTR mode (which encrypts a counter and XORs the resulting block with the plaintext). Ciphertexts in this mode have the exact length as the plaintext. The only problem is that for it to be secure, the nonce (IV) must be unique for every ciphertext under the same key. If your system can keep track of the nonces (they can be simple 96-bit global counters or even 128-bit global counters if the plaintexts are never longer than 128-bit), then you should be able to fulfill your requirement.

CTR encryption:

enter image description here

Freek Wiekmeijer
  • 4,556
  • 30
  • 37
Artjom B.
  • 61,146
  • 24
  • 125
  • 222
3

No. AES is specified with four basic operations on a 4x4 matrix: SubBytes, ShiftRows, MixColumns and AddKey.

An "8 byte AES" would be a fundamentally different cipher. Especially the ShiftRows and MixColumns operations are based on the concept of a square matrix. Hence the block size of any "AES-like" block cipher would need to be a square of N (4, 9, 16, ...).

Freek Wiekmeijer
  • 4,556
  • 30
  • 37
  • OK, I see what you are saying about AES requiring a "square" number of bytes. But then how did they accomplish AES192 and AES256? Neither of those are square numbers of bytes. – Giffyguy May 27 '15 at 15:51
  • @Giffyguy AES192 and AES256 have a different keysize but the same block size as AES128. – Artjom B. May 27 '15 at 16:51
  • 128, 192, 256 is the key size, not the block size. The key is expanded to make it fit. NIST has a very comprehensible specification document which explains the internals of the cipher. – Freek Wiekmeijer May 27 '15 at 16:52
  • 1
    @FreekWiekmeijer Yeah, that document gave me a headache. :) I just finished watching this lecture, which was really helpful. https://www.youtube.com/watch?v=NHuibtoL_qk – Giffyguy May 27 '15 at 19:09
0

If you have 64 bit input, then you can add another 64 bits of removable padding to give 128 bits. Encrypt the 128 bits normally with AES. On decryption, just remove the padding following decryption. There are a number of different possible padding schemes. You will find some, such as PKCS#7 build into many AES libraries.

With a fixed length 64 bit input, you could use random padding, provided you always knew which 64 bits were data and which 64 bits were padding. Mixing up the two would have deleterious consequences.

ETA: With 64-bit values, you could concatenate two of them to make a single 128-bit value. Split them back to 64-bit after decryption.

rossum
  • 15,344
  • 1
  • 24
  • 38
  • The problem is, I need the encryption method to have both 64-bit input AND 64-bit output. – Giffyguy May 28 '15 at 16:16
  • Use padding then. Add padding to the input, encrypt/decrypt and remove the padding, returning the original 64 bits. – rossum May 28 '15 at 18:11
  • 1
    I see what you are getting at, but the problem is I need the encrypted value to also be a 64-bit value. Using padding produces a 128-bit encrypted value, which you can't truncate without destroying the original data. – Giffyguy May 28 '15 at 20:14