CTR Mode/Initial Counter (NIST SP800-38A)
Jeffrey Walton
I have a question with regards to the initial counter of CTR Mode. The
reference given in [1] is not available at NIST. I've also seen what I
believe to be incorrect statements [2], so I wanted to verify.
If using NIST 800-38A (Section B.2 - Choosing Initial Counter Blocks),
an intial counter of 0 seems to be valid for the first method: "The
initial counter block for the initial plaintext message may be any
string of b bits."
The second method (uniqueness property across messages) seems to offer
a randomization implicitly. Effectively, the high order bits are a
nonce, while the low order bits are incremented using the Increment
Function.
Is this correct?
Jeff
[1] http://groups.google.com/group/sci.crypt/browse_thread/thread/cfad6dc07c08986e/b4b810f648e07ce5
[2]
http://groups.google.com/group/sci.crypt/browse_thread/thread/508f4f3d71493423/235d6180215db7de?lnk=gst&q=ctr+mode+initial+counter#235d6180215db7de
John E. Hadstate
"Jeffrey Walton" <nolo...@gmail.com> wrote in message
news:8e7d4c18-3856-41ed...@s19g2000prg.googlegroups.com...
> Hi All,
>
> I have a question with regards to the
> initial counter of CTR Mode.
I think the answers to both of your questions will become clear
to you if you realize that the same key-stream must never be
repeated. There are at least two ways you can control this:
(1) start every key-stream with a unique key, or (2) start
every key-stream with a unique "counter" value chosen so that
the ranges of values through which "counters" cycle never
overlap.
One disadvantage of (1) is that you incur key setup overhead.
This may or may not be significant in your application.
rossum
<nolo...@gmail.com> wrote:
>Hi All,
>
>I have a question with regards to the initial counter of CTR Mode. The
>reference given in [1] is not available at NIST. I've also seen what I
>believe to be incorrect statements [2], so I wanted to verify.
>
>If using NIST 800-38A (Section B.2 - Choosing Initial Counter Blocks),
>an intial counter of 0 seems to be valid for the first method: "The
>initial counter block for the initial plaintext message may be any
>string of b bits."
Yes, 0 is a valid initial counter block. You can only use it for one
message of course - further messages will not be able to reuse already
used values until you change the key.
>
>The second method (uniqueness property across messages)
Not just the second method, both example methods have this property:
"The initial counter blocks, T_1, for each message that is encrypted
under the given key must be chosen in a manner than ensures the
uniqueness of all the counter blocks across all the messages. Two
examples of approaches to choosing the initial counter blocks are
given in this section."
CTR mode is effectively a stream cypher, hence the absolute
requirement not to repeat initial counter blocks.
>seems to offer a randomization implicitly.
I am not sure what you are getting at by "offer a randomization
implicitly". A nonce may or may not include a random element. A date
and a message number within that date are sufficient to produce a
unique nonce for each message without any element of randomness.
>Effectively, the high order bits are a
>nonce, while the low order bits are incremented using the Increment
>Function.
>
>Is this correct?
Yes. You need to take care that incrementing the low order bits does
not overflow into the nonce in the high order bits.
rossum