[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: counter mode

Helger,

>A submission of me, Phil Rogaway and David Wagner to the AES Symmetric Key
>Encryption Modes workshop is available from
>http://www.tml.hut.fi/~helger/papers/lrw00.
>
>There has been quite a lot of discussions and misunderstandings concerning
>this mode. We tried to outline why most of the perceived disadvantages are
>not valid. We also proposed the next somewhat foolproof usage scenario:
>sender keeps a N-bit nonce that he increases at every packet transmission.
>The actual counter is computed as
>
>       N-bit nonce || 128-N bit block counter
>
>N=64 makes the most sense security-wise; in standard IPSEC context one
>could use N=32, where nonce = sequence number.
>
>So let's hope counter mode will be accepted as standard. I know that many
>people (also here) would love to incorporate it in their products.

I have some trouble reconciling your suggestion above with the 
proposal in the workshop paper. That paper seems to suggest a 64 bit 
counter value, followed by 64 zero bits, to form a 128-bit counter. 
Above, you seem to suggest a 32-bit counter transmitted with each 
packet, taken from the sequence number field, and a 96-bit block 
counter. You don't indicate whether this latter counter is purely 
intra-packet, or whether it is stateful for all packets received on 
an SA.

The pipelining that is an attraction of counter mode can be effected 
so long as there is a part of the counter that generates enough key 
stream to
cover the largest single packet, measured in the block size of the 
cipher. That part of the counter is purely internal to the endpoints 
and need not be transmitted, and thus need not waste any space in an 
encrypted packet. For example, 16 bits of counter are more than 
sufficient to cover a max size IP datagram, using an 8 or 16 byte 
codebook. If this value is purely intra-packet, then there is no need 
to maintain state for it at sender or receiver, right? That's why I 
raise the question about the size of the block counter above, and ask 
whether it is stateful. I get the feeling (in part from your paper) 
that you might view this latter value as stateful, but that seems to 
add unnecessary complexity to each end.

The 32-bit per-packet counter one gets from the ESP sequence number 
is nominally big enough for IPsec use of this mode, since we don't 
allow the counter to cycle, and the creation of a new SA with a new 
key avoids compromise in depth concerns. But, if we want to, one 
could carry additional counter bits or even an explicit IV, just as 
we do for CBC mode today (so long as there is confidence that the IV 
will be unique on a per SA basis).

Using the lengths of these field values, and if one needs a 128-bit 
counter value for AES the format might look like this:

	IV or high order cntr bits || ESP seq # || intra-packet cntr || zeros

The IV or high order counter bits could be as few as 2 or as many as 
8 bytes (we already accommodate 8-byte IVs for CBC), leaving the zero 
field to be 2-8 bytes. The use of a purely intra-packet counter 
allows all the performance benefits one wants from counter mode, but 
without devoting any per-packet space to carry the bits.

Steve
Follow-Ups: References: