[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