Is it possible to reduce the output of AES after encryption into 64 bit with the possibility of a reversible before decryption Without any error

  • $\begingroup$ I would investigate Karnaugh Maps, and the Quine-McCluskey algorithm if you're interested in reducing Boolean expressions. en.wikipedia.org/wiki/Karnaugh_map en.wikipedia.org/wiki/Quine%E2%80%93McCluskey_algorithm $\endgroup$
    – Q-Club
    Feb 2 '17 at 1:59
  • 4
    $\begingroup$ If you want to encrypt something non-block sized (vs get a 64 bit PRP) then consider using a mode such as CTR. $\endgroup$ Feb 2 '17 at 1:59
  • 3
    $\begingroup$ FFX mode. But it's slow and complicated. $\endgroup$ Feb 2 '17 at 3:05
  • 2
    $\begingroup$ What does "the possibility of a reversible before decryption Without any error" mean? Your question starts out reasonably, but seems to trail off into ungrammatical nonsense. $\endgroup$ Feb 2 '17 at 11:12

There is no way to reduce the output of a single AES encryption operation to 64 bits with the possibility of decryption without error.

There are however ways to use AES to build a 64-bit cryptogram that can be decrypted without error. The simplest is: encipher the constant zero with AES, keep the first 64 bits, XOR with the plaintext to get the cryptogram. Problem is, that's insecure if the AES key is used more than once.

There are ways to allow several uses with the same key:

  • If an initial IV setup is tolerable (e.g. the IV overhead negligible compared to many later 64-bit cryptograms delivered in order), CTR mode is fine, as noted by Thomas M. DuBuisson.
  • Construct a 64-bit symmetric Feistel cipher using AES encryption for the round function (AES-encipher the concatenation of the round number and 32-bit input); with 10 rounds for good measure, and perhaps using addition modulo $2^{32}$ rather than XOR for combination of the output of the round function (so that the cipher is not always an even permutation, which would be noticeable after $2^{64}-2$ plaintext/ciphertext pairs), that's a secure 64-bit block cipher. Beware however that with this method (or any 64-bit block cipher) alone, identical 64-bit plaintexts will be recognizable as identical 64-bit ciphertexts.
  • FFX mode is another possibility, as noted by CodesInChaos.

The AES itself is an standard with a block size of 128 bits and 3 different key sizes (128, 192 and 256). The Rijndael, the winner of the AES contest, was proposed with this block size but with 5 different key sizes (add 160 and 224 to the previous 3).

This suggest a bigger flexibility in the Rijndael. In fact, playing with the parameters and the maths behind the Rijndael one can produce almost any arbitrary block and key size combination. Don't forget that this is not AES, but Rijndael.

Apart from this generalization, there are other algorithms designed designed to be 64 bit block like mCyrpton, present, katan/ktantan or Prince to mention some that I know. The cryptoanalysis made by the community is proportional to its impact. The the Rijndael has been more tested (on its original setup).

Apart from the CTR block cipher mode mention on a comment of a previous answer, you have other possibilities to think using an already tested implementation of the AES: Format preserving encryption.

Any solution you apply depends on where you apply, what are your needs. But focus, don't implement your crypto unless you are doing a research or it is going to be publicly review before and during production phase.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.