How to encrypt a 192 bit plaintext using AES-192?

Question

Can we use AES-192 bit algorithm for 192 bit plaintext? If yes, what are the changes we have to do?

Answer 1

Strange as it may sound, you should not directly use any block cipher directly as a means to provide confidentiality. A block cipher can only handle a statically sized plaintext, which in the case of AES is always 128 bits; it's not 192 bits, that's just the key size.

More importantly a block cipher will always output the same ciphertext if the key and input block remain the same. That means that if you input two 128 bit messages, for instance the ASCII representation of "affirmative, sir", then the ciphertext will be identical. If this message is the answer of two separate questions then an adversary can immediately detect that the answer of two questions is identical as well. This breaks the security of a cipher as it leaks information about the plaintext.

In the strongest semantic security that a cipher can obtain, IND_CPA, the ciphertext output should not leak any information even if the adversary may input as many input messages as he likes.

---

The simplest mode of operation is ECB mode; it just splits the plaintext into multiple blocks, and then encrypts each block in turn, possibly padding the last block so that the input to the block cipher always receives 128 bits. This solves the first part of the cipher only handling 128 bits, but it does nothing for the security mentioned in the previous sections.

Fortunately there are many modes of operation that do provide such security. AES-CBC is used a lot, but it requires padding - which in itself can be a security risk - as well as a unpredictable IV. This IV or initialization vector is used to change the ciphertext independently of the plaintext. AES-CTR (AES in counter mode) is also used a lot and doesn't require the padding and only a unique nonce (number-used-once) instead of the unpredictable IV.

Currently authenticating ciphers such as GCM are becoming more commonplace as they do not just protect the confidentiality but also the authenticity and integrity of the message. They are generally build using AES-CTR internally.

---

Note that the size of the plaintext is not automatically protected by AES using any of the modes of operation. This is one of many side channels that may leak information to the attacker. You cannot just encrypt "Yes" to 3 bytes ciphertext and expect that an adversary cannot distinguish it from the 2 bytes required for "No".

---

When you read about AES-192 is being used to protect your data then you should ask yourself how it is used to do this. To a seasoned cryptographer the use of AES, as the most common unbroken block cipher, only means that a small part of a system is possibly secure.

---

If you want to encrypt fully random data (such as an AES key) then you could right-pad your data using 64 bits set to zero. Then you could use ECB mode encryption (encrypt two blocks of 64 bits) and encrypt the two blocks of 128 bits. This process is called key wrapping. This is only secure for completely random data though and it is probably better to use more modern techniques such as AES in SIV mode.

Answer 2

192 bits is 24 bytes, so the software implemented will most likely pad the message to be 32 bytes, a multiple of 16 byes (this is the 128 bit block size of AES).

Answer 3

My answer has the purpose to prolong @Maarten Bodewes's answer by adding some interesting details that might go off the scope of the question but adds a few points that I consider important when understanding the context of what was written in his answer.

Usually, ciphers are still considered semantically secure even if the attacker can obtain some information about their length. Here I give the example of the OTP cipher, that is perfectly secure if the same key is never used twice even though it leak information about the length.

For my understanding when Maarten states at the end of the second paragraph:

This breaks the security of a cipher as it leaks information about the plaintext.

what he really meant was: This breaks the security against chosen plaintext attack.

That said, I think it's worth to point that, in fact, any deterministic cipher (using the same key) will not be secure against a chosen plaintext attack.

If the reader wants to go into more detail, to prove CPA (chosen plaintext attack) security one must define an Attack Game between an adversary that can query a challenger i times with two messages (m1 and m2) per query, with the objective to distinguish if all ciphertexts returned by the challenger were generated from the first or second message of each query. Note that for all queries the challenger will encrypt mb for b = {1,2}.

Now, if one used a semantically secure cipher to encrypt all his files under different, independently generated key for each file, then we can state this configuration is also CPA secure. This is also called multi-key semantic security.

Saying that no deterministic cipher can possibly satisfy the definition of CPA security there is a generic approach to get a CPA secure cipher out of a semantically secure cipher and an appropriate PRF - pseudorandom function. Alternatively one can transform a secure PRF (say AES, that is also a secure PRP - pseudorandom permutation) into a CPA secure cipher. This last approach uses, most of the times, the counter mode or the CBC mode, where the first one has several benefits over the second, such as parallelism (because of its architecture) and shorter ciphertext length (because of its return ciphertext format).

If one wants to dive into CPA security I recommend reading the 5th chapter from A Graduate Course in Applied Cryptography. In fact, most of what I've written here is based on this book.