[p2p-hackers] AES CTR vs. CBC, other [was: Re: security and protocols]

[coderman]

On 11/28/06, Lauri Pesonen <lauri.pesonen at iki.fi> wrote:
> On 29/11/06, Alex Pankratov <ap at hamachi.cc> wrote:
> > Using CTR instead of any other chaining mode (excluding ECB) has exactly one
> > benefit - the counter field can be reused for replay protection. Otherwise
> > it would require a separate packet sequence number field. But if I remember
> > correctly from the discussion on a cryptography maillist, CTR chaining
> > introduces some undesired/unresearched crypto properties and therefore the
> > consensus was that 4 byte savings over traditional CBC mode were simply not
> > worth taking a risk of using CTR.
> ...
> Thus far I've always heard comments regarding CTR mode that point out
> how simple it is and therefore lends itself to rigorous mathematical
> analysis unlike most of the other chaining modes. I'd be very
> interested to hear comments to the contrary for once.

i believe the "CTR chaining" weakness mentioned above is in regards to
the use of an explicit IV in IPsec for counter mode (CTR or CM) just
like CBC mode, for per packet synchronization, even though it is not
absolutely required. [0].

as a more general note, there are indeed some nice advantages to counter mode:
 - simplicity
  - parallelizable / pipeline-able
 - random access
  - lack of random IV's (generating entropy is hard and slow unless
you have a physical source).

and some drawbacks / constraints:
  - leaks plaintext size without padding (other modes just leak size
in terms of blocks)
 - vulnerable to time memory trade off attacks [1]
  - failure to prevent keystream reuse is catastrophic [2]
 - a strong message authentication code (MAC) must always be used [2]

as a side note, it is common to include entropy in the initial counter
value (64 bits of entropy + 64 bit counter) to avoid the time memory
trade off weaknesses.

using a random IV (like CTR in IPsec specifies) adds some overhead,
but avoids the time memory trade off as well as ensuring no keystream
reuse.  hardware entropy sources are great for this purpose since
entropy gathering daemons are notoriously slow.

best regards,


0. "a lengthy analysis of counter mode and ESP"
  http://www.vpnc.org/ietf-ipsec/02.ipsec/msg02054.html

1. M.E. Hellman, A cryptanalytic time-memory trade-off
  IEEE Transactions on Information Theory, July, 1980, pp. 401-406.

2. "Stream cipher attack"
  http://en.wikipedia.org/wiki/Stream_cipher_attack