AES blocks with a counter

Question

I would like to send small separate packets of data.

I am thinking of using AES-128 or AES-256, and to add a counter as part of the plain text message.

Some clarifications: Each message will be one block length. The transmitter and the received are "counter synched". i.e. the transmitter sends the packet at constant time intervals (once a second), and the receiver expects the known counter on each packet.

1. Is it a reasonable solution?
2. Are there any possible security risks?
3. Since the plain text will not repeat itself, should I still use an IV? or can I omit it?
4. Should I use a MAC, or is the counter is a sufficient authentication?

Answer 1

1. Is it a reasonable solution?

That's hard to say; for a transport protocol - which is what you are designing - you have hardly described anything at all. Yes, a counter can be used to make messages unique as to avoid replay attacks and introduce randomness when combined with the AES key.

2. Are there any possible security risks?

Plenty, but with the minimal description - without even a mode of operation or message description, use case, threat model etc. - it is hard to tell which ones would be applicable.

3. Since the plain text will not repeat itself, should I still use an IV? or can I omit it?

That depends on the mode. If your messages are only one block then you could use ECB mode, which does not require an IV . Otherwise it depends on the mode of operation.

For instance, encrypting a counter in the plaintext message with e.g. AES-CTR will not result in randomizing your ciphertext; in that case you need to use an IV. For AES-CTR, every bit of ciphertext doesn't depend on any of the other bits, so you cannot rely on the message randomizing the ciphertext itself. This is also the case for most authenticated modes of operation (e.g. GCM) as they internally rely on AES-CTR mode for confidentiality.

However, if you put the counter / randomness in the first block of plaintext for AES-CBC then you would be fine, and you could use an all-zero IV.

4. Should I use a MAC, or is the counter is a sufficient authentication?

No, a counter is not authentication. You need either a MAC or an authenticated mode of operation (assuming you require message authentication, which is commonly the case).

---

After the edit: sure you can use ECB mode (which is just the application of the block cipher for a single block) to encrypt a plaintext block that includes a counter.

It depends on the size of the counter if you could see the result as authenticated. If the counter is 64 bit then you get 64 bits of security, which could be enough given that you require a new counter each time. If the counter is smaller then I'd certainly make sure that you only allow one (or a few) ciphertext messages.

Furthermore, you should never ever repeat the counter for the same key. Not on restarts, for instance.

---

Looking at your level of questioning, you're not yet ready to create your own transport protocol. You could have a look at e.g. TLS. There is also a version for packet encryption called DTLS. Or any one of the lightweight transport protocols used for embedded applications.

Answer 2

Was thinking of using AES128 or AES256, and add a counter as part of the plaintext message.

Using 256-bit key instead of 128-key will increase the key size storage and security. It, however, will be 40% slower.

1. Is it a reasonable solution?

The short answer no; There is no authentication. And, once a message is repeated you will have the same counter that implies the same plaintext again will be transmitted. This is why a random IV is important.

There are well-studied modes of operations. Prefer AES-GCM.

2. Are there any possible security risks?

Active network attacks are possible, as deletion and insertion. For example; first, you sent a message that contains $n$ blocks. Next, when an active attacker sees that you sent another message with $k<n$ blocks, the attacker can add the last $n -k$ of the previous message to the new one.

Therefore you needs an authentication.

3. Since the plain text will not repeat itself, should I still use an IV? or can I omit it?

If you are talking about using the CBC or CTR GCM mode those use random IV's you should stick to the standard.

If you want to use a mode of operation that doesn't use $IV$ as in ECB; you can use ECB as long as there are no repeated messages, see part 1.

4. Should I use a MAC, or is the counter is a sufficient authentication?

A counter is not an authentication. There is a well-studied standard AES-GCM for AEAD (Authenticated Encryption with Additional Data) that solves all of your problems.

• You don't need to add a counter to your plaintext to make them unique.
• AES-GCB by design has Authentication.

---

update after question update

Since you are controlling all of the transmitted data all of the time with the counter, you can use ECB mode. As I noted in the comment, it will take $2^32$ seconds = 136.102208 years to restart or overflow the counter. Not in a life time.