# Which data to share in CTR mode?

Suppose I've got two clients $A$ and $B$. Client $A$ encrypts data in CTR (Counter) mode to get a ciphertext. What information will client $B$ have to receive from $A$ to decrypt the ciphertext? Just the “key”, “IV” (nonce), and “counter start value”?

-
@CodesInChaos it's CTR(Counter) mode, i've corrected my question –  sim Dec 18 '13 at 2:49

As you specified in the question, the key, nonce, and initial counter value are what is required in addition to the ciphertext and algorithm used.

However, it is best practice to have the initial counter always be 0. Common standards place no specific restrictions on the size of the nonce unless it is used in an authenticated encryption mode, but it is generally 96-bits, leaving 32-bits for the counter. A 32-bit counter allows 64 GiB of data to be encrypted per nonce using a 128-bit block cipher. A 32-bit 0-start counter is also more simple for software implementations. If you expect to send more than 64 GiB in a single message, you will need to reevaluate the counter size.

If you plan on having both the clients encrypt data with the same key, care must be taken so that there is no nonce overlap. 2 ways of doing this are prenegotiating a client to only use even or odd nonces, or having one of the clients use only nonces with the high bit set to 1.

-
Thanks for your answer. I'm thinking generate nonce randomly before encryption and prepended as plaintext to ciphertext. Is it safe enough to transmit nonce with ciphertext in such way ? –  sim Dec 18 '13 at 6:19
Having the nonce be random is not a requirement, having it be unique per message is. If you are generating them randomly there is a probability of overlap; it is best to start with a random nonce and then increment by 1 for each message. The nonce is fine to send in plaintext, but should be included as part of any authenticated data. –  Richie Frame Dec 18 '13 at 10:23