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

Re: counter mode

On Tue, 3 Oct 2000, Stephen Kent wrote:

> 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.

Stephen,

> 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. 

Paper is correct, but may be my explanation here seemt to be
unclear (sorry for confusion - just look at the paper).

We suggest 64-bit incremented 'nonce' concatenated with 64-bit
intra-sequence block counter. The only reason why I generalized the first
64 to N was the RFC 2406 which specifies:

  2.2 Sequence Number 

  This unsigned 32-bit field contains a monotonically increasing counter
  value (sequence number). It is mandatory and is always
  present even if the receiver does not elect to enable the anti-replay
  service for a specific SA. Processing of the Sequence
  Number field is at the discretion of the receiver, i.e., the sender MUST
  always transmit this field, but the receiver need not act
  upon it (see the discussion of Sequence Number Verification in the
  "Inbound Packet Processing" section below). 

  The sender's counter and the receiver's counter are initialized to 0
  when an SA is established. (The first packet sent using a
  given SA will have a Sequence Number of 1; see Section 3.3.3 for more
  details on how the Sequence Number is generated.) If anti-replay is
  enabled (the default), the transmitted Sequence Number must
  never be allowed to cycle. Thus, the sender's counter and the receiver's
  counter MUST be reset (by establishing a new SA and thus a new
  key) prior to the transmission of the 2^32nd packet on an SA.

So, in the case of IPSec it is _perfectly_ ok to use the sequence number
as a nonce and then concatenate it with the packet counter.

However, the 32-bit sequence number does really not make any sence, as
does not the 64-bit packet counter. Both should be 64-bit long. The 32+96
would just not break the standard _and_ not require any additional state
elements to be maintained.

> 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.

What you proposed here is also a valid use, but requires (a somewhat more
careful) maintaining of separate status information. On the other hand, it
has the asset that one could send more than 2^32 sequences by using this
mechanism.

[Note that intra-packet counter also makes the mode also more foolproof,
 since a unique sequence number || unique block counter (both
 numbers are implicitly/explicitly maintained somehow in most of
 the IPSec implementations!) results in a unique counter number without
 any additional effort from the user]

> Steve

Thanks for comments,
Helger
http://www.tml.hut.fi/~helger
References: