Prev: Generating an offline key/token
Next: Compatibility between different providers
From: skillzero on 4 Feb 2010 02:21
Why do many AES-128 counter mode implementations use only 64-96 bits
of random data and 32-64 bits for the counter portion? Is there a
problem with using 128 bits of random data as the initial counter
value and treating the entire 128 bits as a counter? This would seem
to avoid the wrapping issues if the counter portion is less than 128
bits.

My other questions is if there's a problem with using AES counter mode
with the same key and nonce on both sides if the protocol forces each
side to do its operations one after the other (lock-step)? I
understand the problem of encrypting two pieces of data with the same
key stream, but in my case, I'm doing a single key exchange in order
so the key stream won't repeat (the following must be executed in
order):

Computer A: Counter = 1, Encrypt X and send to Computer B (along with
nonce).
Computer B: Counter = 1, Decrypt X.
Computer B: Counter = 2, Encrypt Y (with info derived from X) and send
to Computer A.
Computer A: Counter = 2, Decrypt Y.
End session.
From: Paul Rubin on 4 Feb 2010 02:22
"skillzero(a)gmail.com" <skillzero(a)gmail.com> writes:
> Why do many AES-128 counter mode implementations use only 64-96 bits
> of random data and 32-64 bits for the counter portion? Is there a
> problem with using 128 bits of random data as the initial counter
> value and treating the entire 128 bits as a counter?

Lets the counter fit in a machine word, making incrementing a little
simpler and faster, I guess.

> This would seem to avoid the wrapping issues if the counter portion is
> less than 128 bits.

You aren't going to overflow 64 bits.
 | 
Pages: 1
Prev: Generating an offline key/token
Next: Compatibility between different providers