[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: counter mode
Helder,
Helger Lipmaa wrote:
>
> 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.
good, I'm glad to see this proposal. I'll support it at the workshop.
I've been experimenting with counter mode for IPSEC, and planning to
produce an Internet Draft for counter mode AES, within the context of
the Stream Cipher ESP (which I presented at the Pittsburgh IETF, but
which didn't generate a lot of discussion - it's at
http://search.ietf.org/internet-drafts/draft-mcgrew-ipsec-scesp-01.txt).
I would be glad to hear your comments on this draft.
> 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
>
This makes sense.
> 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.
>
> Helger
There are some attacks that are possible against counter mode (at least
for some values of N and some key sizes) that are not possible against
CBC mode: key collision attacks and time-memory tradeoff attacks. It is
certainly possible to choose parameters to defend against these attacks,
and we would need to do that in a standard. I spent some time thinking
about such attacks, and the paper describing this work is online at
http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf.
David
References: