Return to Answer

If you want to use the nonce ( yes it is nonce in the CTR mode) more than one file, then you need to send the start of the counter, too, and store it locally, you and the other side!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality by the crib dragging technique. The mitigation is to use a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

Remember, the CTR mode has many disadvantages with AES, as the lack of integrity and authentication that AES-GCM handles. And the AES-GCM is hard to use instead use ChaCha20-poly1305 where AES is not obligatory.

How is the current used IV (nonce+ctr) synchronized among both communicating entities?

Using the nonce more than one file ( a derived question )

If you want to use the nonce ( yes it is nonce in the CTR mode) in more than one file, then make sure that the counter is not repeated. This can be achieved by encrypting the next file's counter to the previous file's last counter plus 1. I.e., the previous file used the counter from $i$ to $j$ than the next file's counter must be started from $j+1$, and make sure that $j<2^{64}$, and no round to $$0 if it exceeds $2^{64}$.

By using the counter's remaining values, you need to send the start of the counter, too, and store it locally, you and the other side!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality since an observer will notice this and they will use the crib dragging technique. This doesn't mean that the AES will be lost, remember the CTR mode is CPA secure. The mitigation is using a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

Remember, the CTR mode has many disadvantages with AES, as the lack of integrity and authentication that AES-GCM handles. And the AES-GCM is hard to use instead use ChaCha20-poly1305 where AES is not obligatory.

Updated for answers to comments;

Nonce in context of CTR means that I can use it together with one AES key as lons as a counter value is not used more than once, right? I.e. the combination of (key, nonce, counter) must not be used multiple times. Am I correct?

Yes, see it in this way.

In the CTR mode, the nonce and counter is encrypted with the AES

$$ c_i = AES(k, nonce\|counter_i).$$ Therefore under the same key any repeat of the $nonce\|counter_i$ can result in the crib-dragging attack.

What do you mean with "...more than one file."? I don't get this point. I guess the nonce doesnt have to be used (so only counter), if you are only encrypting one file using a given AES key. However, for each different file we shall use a new nonce (and start the counter from 0 again), if we do not want to establish a new AES key So in terms of the counter and –

I think I've over-read your question about sending the counter. Since the counter always starts from 0 there is no need for sending. It is only necessary if you are using it mode than one file.

The correct usage is using a new nonce for each file. If you don't establish a new key, generate a new nonce, and send it with appended. Make sure that you don't generate the nonce again.

In CTR mode the counter starts from $0$, therefore one doesn't need to send the initial value in the CTR mode.

If you want to use the nonce ( yes it is nonce in the CTR mode) more than one file, then you need to send the start of the counter, too, and store it locally, you and the other side!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

$$nonce\|counterValue\|encryptedMessage$$

Sending the start of the counter has no insecurity problem, otherwise, we should already have with the CTR since we all know it starts from 0.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality by the crib dragging technique. The mitigation is to use a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

An interesting case of the danger is if both parties send a new message at the same time with the same counter, nonce, and key value. That is catastrophic!

Remember, the CTR mode has many disadvantages with AES, as the lack of integrity and authentication that AES-GCM handles. And the AES-GCM is hard to use instead use ChaCha20-poly1305 where AES is not obligatory.

In CTR mode the counter starts from $0$, therefore one doesn't need to send the initial value in the CTR mode.

$$\text{64 bits nonce}||\underbrace{\text{00000...00000}}_{64 \, zeros}$$

If you want to use the nonce ( yes it is nonce in the CTR mode) more than one file, then you need to send the start of the counter, too, and store it locally, you and the other side!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

$$\text{nonce}\|\text{counter Value}\|\text{encrypted Message}$$

Sending the start of the counter doesn't cause any insecurity problem, otherwise, we should already have with the CTR since we all know it starts from 0.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality by the crib dragging technique. The mitigation is to use a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

An interesting case of the danger is if both parties send a new message at the same time with the same counter, nonce, and key value. That is catastrophic! Therefore, if the messaging is in two directions with the same key, nonce, and counter continuation, it is not advisable to continue the counter where it is left. At least, generate a new nonce.

Remember, the CTR mode has many disadvantages with AES, as the lack of integrity and authentication that AES-GCM handles. And the AES-GCM is hard to use instead use ChaCha20-poly1305 where AES is not obligatory.

In CTR mode the counter starts from $0$, therefore one doesn't need to send the initial value in the CTR mode.

If you want to use the nonce ( yes it is nonce in the CTR mode) more than one file, then you need to send the start of the counter, too, and store it!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

$$nonce\|counterValue\|encryptedMessage$$

Sending the start of the counter has no insecurity problem, otherwise, we should already have with the CTR since we all know it starts from 0.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality by the crib dragging technique. The mitigation is to use a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

Remember, the CTR mode has many disadvantages with AES, as the lack of integrity and authentication that AES-GCM handles. And the AES-GCM is hard to use instead use ChaCha20-poly1205 where AES is not obligatory.

In CTR mode the counter starts from $0$, therefore one doesn't need to send the initial value in the CTR mode.

If you want to use the nonce ( yes it is nonce in the CTR mode) more than one file, then you need to send the start of the counter, too, and store it locally, you and the other side!. One can prepend this, too. Prepending is useful since it is at the beginning of the stream/file.

$$nonce\|counterValue\|encryptedMessage$$

Sending the start of the counter has no insecurity problem, otherwise, we should already have with the CTR since we all know it starts from 0.

There is, however, a danger to use in this form. During a system failure, you may lose the last value, and instead, you may use the previous values of the counter. This can result in a catastrophic failure of confidentiality by the crib dragging technique. The mitigation is to use a new nonce, the best is exchanging a new key with ECDH and use a new nonce.

An interesting case of the danger is if both parties send a new message at the same time with the same counter, nonce, and key value. That is catastrophic!

Remember, the CTR mode has many disadvantages with AES, as the lack of integrity and authentication that AES-GCM handles. And the AES-GCM is hard to use instead use ChaCha20-poly1305 where AES is not obligatory.