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?
  • $\begingroup$ small is = ? please provide the value. AES-CTR mode of operation $\endgroup$ – kelalaka Oct 12 '18 at 21:30
  • $\begingroup$ The counter ever starts again, the next day? What is the bit size for the counter? What is one block length? is it Block cipher block as 128-bit? $\endgroup$ – kelalaka Oct 13 '18 at 17:50
  • $\begingroup$ The counter is 32 bit., each packet is sent once a second, and the counter is incremented then. Will count continuously, and never reset. The block is either AES128 or AES256. Didn't decide yet. but probably 128. I don't need much data to be sent. $\endgroup$ – isak Oct 13 '18 at 18:14
  • $\begingroup$ $2^{32}$ seconds is 136.102208 years. AES is 128-bit block size cipher. 128, 192, and 256 are keys sizes. $\endgroup$ – kelalaka Oct 13 '18 at 18:29

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.

  • $\begingroup$ Thank you for your detailed answers. I added some more info to the question. Is it enough information? $\endgroup$ – isak Oct 13 '18 at 17:35
  • 1
    $\begingroup$ The question as it now stands is enough for this answer - which is rather generic. More detailed answers are possible if more info becomes available. But please make sure that you don't update your question too much so that the current answers become outdated or worse, incorrect; ask a new, more specific question instead. $\endgroup$ – Maarten Bodewes Oct 13 '18 at 17:37
  • $\begingroup$ Thanks, I thought that new editing will show as outline or something on the original question. What more info could be useful for a more complete answer? $\endgroup$ – isak Oct 13 '18 at 18:16
  • $\begingroup$ It does, but only if people click on "edited ... ago". $\endgroup$ – Maarten Bodewes Oct 13 '18 at 18:17

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.

  1. 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.

  1. 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.

  1. 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.

  • 1
    $\begingroup$ "If you are talking about the CBC or CTR mode, yes you can use ECB". I don't get this sentence. "No need to add a counter to make them unique." Uh, I'd make very sure that the IV is unique for GCM - your answer doesn't highlight this. Just a counter in the message instead of an IV is very dangerous for GCM, even more so than just for AES-CTR. $\endgroup$ – Maarten Bodewes Oct 12 '18 at 23:49
  • $\begingroup$ He tries to make the messages unique by adding an internal counter. In this case ECB is secure right? Yes GCM by standard has random IV's and I don't say change that. I did not to say use GCM and AES-CTR without IV. Let me re-check. Thanks. $\endgroup$ – kelalaka Oct 13 '18 at 10:43
  • $\begingroup$ Thank you for your detailed answers. I added some more info to the question. Is it enough information? Using GCM will add more bytes to the packet. If possible I would like to keep the packet as small as possible. $\endgroup$ – isak Oct 13 '18 at 17:38
  • $\begingroup$ @isak I agree with Maarten's last comment. $\endgroup$ – kelalaka Oct 13 '18 at 17:42

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.