I'm working on a network where nodes communicate using AES-CCM encryption, within a context of tight bandwidth limitations, making every bit count. The setup uses a nonce that combines a 16-bit node address, a timestamp incremented every 100 seconds (with only the offset transmitted), and a 10-bit counter unique to each node and timestamp. The size of the authentication code is 64 bits.

However I also need to encrypt the 16-bit node address which is used as a fixed part for the nonce.

My approach involves a two-step encryption process: first, encrypting the message with AES-CCM, and then encrypting the node address (and potentially the counter). During decryption, the node address is decrypted first and partly used as the nonce for the AES-CCM step. Separate keys are used for both steps and all inputs to the second step are authenticated. I've considered two methods for this.

First idea was to use AES-ECB. The node address and the counter essentially provide a network wide unique counter to encrypt. Also, since the node address is only 2 bytes and the counter part is not filling the AES block size of 16 bytes I intend to double encrypt some parts of the initial AES-CCM ciphertext. Otherwise I would have to pad the ECB input which is not desirable.

Another idea was to use AES-CTR for encrypting the address, utilizing the MAC from AES-CCM step, the timestamp, and the 10-bit counter as the nonce. The 64-bit randomness of the MAC, however, introduces a risk of nonce collision. Calculating the security level for the address encryption with this method is something I'm uncertain about.

These are two different approaches on how to achieve the 16-bit address encryption.

  • Is ECB mode secure when encrypting already encrypted data?
  • Is ECB mode secure when plaintext is guaranteed to be different for every encryption?
  • How to evaluate the security of the CTR mode approach I described?
  • $\begingroup$ why not just SHA256 of everything and then you use first 128 bits as IV? and i would use CBC mode instead. $\endgroup$ Feb 21 at 11:07
  • $\begingroup$ I could use SHA256 to produce the IV for the address encryption in CTR mode, however I am not sure if that would add to the overall entropy of the nonce. Also the nonce size is usually 96 bits, never 128 bits in these ciphers. I don't know how CBC mode would help me in this situation. $\endgroup$ Feb 21 at 17:34
  • $\begingroup$ Problem of ECB is that it does not use IV, and it always produces same output for the same input. This is bad in a sense, that attacker can see that you constantly send same data. $\endgroup$ Feb 24 at 13:41
  • $\begingroup$ I updated my question to try to be more precise. The input to the ECB step is the network wide unique counter - which is used as the nonce in the CCM step. Also, due to the 16 byte block size of AES, I need to fill the rest of the block with padding. To save space I intend to pad with the ciphertext that was produced in the CCM step. This should essentially introduce more randomness to the ECB step input. $\endgroup$ Feb 26 at 6:22
  • $\begingroup$ To be honest I think you are just mucking about. Why would you prefer double encryptin over padding, for instance? Why not talk about the block cipher rather than ECB mode? Why are you talking to a nonce that is "unique to each node and timestamp"? Don't you mean that a counter, node and timestamp make up the nonce? At this point it is probably best to create a more formal description of your protocol including key names names & sizes of the data elts etc. If you can't then don't. $\endgroup$
    – Maarten Bodewes
    Feb 26 at 12:51

1 Answer 1


ECB mode is a bit of a misnomer if just a single input value is used. At that point it is just a single block cipher encrypt.

CCM only assumes that a unique nonce is used, it doesn't require an unpredictable or random IV.

A block cipher encrypt is deterministic, assuming that the block cipher will keep using the same key. That means that nonces that are not unique will not get any benefit by using a block cipher.

It is not entirely clear if you want to send the "nonce" with the ciphertext. If that is the case then there is no reason to encrypt the input data for it twice.

First of all, you could just consider a random nonce instead. Second, if you encrypt the data and the receiver is able to decrypt then there is no need to include it again.

If you are afraid that the encryption with the block cipher could break CCM then just encrypt it with a different key. You could derive one or two keys from the shared key using one or more calls to a key derivation function (KDF).

If you have a unique ciphertext and you're not afraid of a two pass algorithm with regard to processing required then SIV mode would probably the best mode to use. In that case if any bit of two messages are different then the ciphertext will use a different nonce.

If there is still a chance of collision then you can add additional information using a random salt sent with the messages to make this chance smaller.

  • $\begingroup$ I think have not been very clear on my question. First step is to use AES-CCM for the actual message encryption and use a counter (consisting of timestamp and actual counter) and the node address the nonce. However the node address also needs to be encrypted, so my idea was to encrypt the whole nonce - essentially a network wide unique counter - and for the same input include the amount of ciphertext data from the earlier step to fill the 16 byte ECB block. I intend to use different keys for each step. The CTR approach was alternative for the ECB one. I will update the question. $\endgroup$ Feb 26 at 6:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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