What input parameters can be made public in the AES-CTR mode?

Question

Preface: I am beginner of cryptography and not native English speaker. So I may make terrible mistake (about grammar and cryptography).

I understand that the parameters used for AES-CTR are "key", "nonce" and "counter" in addition to plaintext and ciphertext.

I also understand that it is not a good idea to disclose all of these (especially "key").

So, is it OK to disclose the nonce? Also, is it OK to disclose the set of nonce and counter?

As an example, we assume that the nonce is used for encryption of packet communication. If I put nonce and counter at the beginning of the packet, is that encryption secure?

Answer 1

In AES-CTR, the nonce is extended to 128-bit (unless it's already that size) by padding zeroes, and is the initial value of the counter. The counter evolves in a public manner (incremented by one at each encryption of 128 bits). Thus making public the nonce or the counter is essentially the same thing.

The standard and safe assumption is that the nonce (also known as Initialization Vector) is public, and transmitted in clear at start of ciphertext. The theoretical perspective is that the nonce is part of the ciphertext, which implies the nonce is public, since the ciphertext is assumed public.

The only long term secret is the key.

For the duration of one encryption/decryption session, secrets include the plaintext, and the result of the encryption by the AES block cipher, under the key, of the successive values of the counter (called the keystream when we truncate it to the size of the plaintext).

Answer 2

First let's include a picture of CTR mode:

_{^{Public domain by White Timberwolf & Gwenda}}

I understand that the parameters used for AES-CTR are "key", "nonce" and "counter" in addition to plaintext and ciphertext.

I'd say that the parameters are the key and nonce. The counter is an implementation detail of the counter mode. Compare this to CBC mode where we do have an Initial Vector (IV) but the "vectors" that are XOR'ed for the blocks that follow the initial block are not part of the parameters. Usually the counter is simply started as zero, so there is no need to communicate that value (see final section of this answer for more information).

I also understand that it is not a good idea to disclose all of these (especially "key").

If you'd leak the key then the adversary can likely decrypt the ciphertext. Generally it is easy to reconstruct the counter through known plaintext.

So, is it OK to disclose the nonce? Also, is it OK to disclose the set of nonce and counter?

Yes. Assuming that the key is kept secret those can be shared with an adversary. The idea is that no information about the block that is part of the key stream can be retrieved by the adversary. A block cipher is a random permutation of the input block, in this case of the counter. That means that the output of the block cipher will be randomized even if the input is known. The block of key stream is the data that is XOR-ed with the plaintext block using the $\oplus$ operation in the picture that explains CTR mode.

Beware that CTR mode will always decrypt. That means that if an adversary is able to alter the IV that the resulting plaintext is randomized. That means that the IV should be protected against change if integrity and authenticity of the message is required. This is why AEAD schemes such as AES-GCM - that internally uses AES-CTR - will authenticate not just the the associated data and ciphertext but also the given nonce to secure the plaintext.

As an example, we assume that the nonce is used for encryption of packet communication. If I put nonce and counter at the beginning of the packet, is that encryption secure?

Many API's will not assume that they know how the counter block is constructed; they just require all bytes of the counter to be included, and then increase this counter assuming it is an unsigned 128-bit big endian encoded number. Often this combination of nonce and counter is simply called the IV.

That means that you can just send a nonce and put that nonce in the most significant (leftmost) bytes of the "IV", making sure that the least significant (rightmost) bytes are set to zero.

Beware that these implementations will not protect against the counter overflowing in the nonce, so you will have to make sure that the maximum number of plaintext blocks that are encrypted isn't higher than the counter can accommodate for. For instance, with a 32 bit counter you can encrypt a maximum of $2^{32} = 4\text{Gi}$ plaintext blocks, i.e. 64 GiB of data.