[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IV sizes for AES candidates
In message <3.0.2.32.20000808075611.0072ab24@email.nist.gov>, Sheila Frankel wr
ites:
>There is a draft, "The Candidate AES Cipher Algorithms and Their Use with
>IPsec," <draft-ietf-ipsec-ciph-aes-cbc-00.txt>, that describes the AES
>finalists and how to fit them into AH/ESP/IKE. It mandates an IV size equal
>to the block size (16 bytes). The draft expires in September, so hopefully
>the next version will have the actual AES algorithm(s).
The draft makes several points that deserve discussion on this list.
For one, it asks about different modes of operation instead of DES. I
suspect that the same pressures that are pushing NIST to hold a modes
of operation workshop in October (http://csrc.nist.gov/encryption/aes/modes/),
but I think that that question is (almost) orthogonal to the choice of
underlying block cipher. There are a fair number of subtle issues in
mode of operation design, and I don't think that the IETF is the right
issue to explore ost of them. (Practical or implementation aspects
are, of course, something we're good at.)
The modulus sizes suggested for different key lengths are quite high,
and I wonder if they're realistic. I mean, a 15430 bit modulus for
Diffie-Hellman is just not going to happen. I'm particularly concerned
by this sentence:
Implementations are encouraged to use the largest key sizes they can
when taking into account performance considerations for their partic-
ular hardware and software configuration.
It isn't clear to me that there is any real security gain from using a
256-bit symmetric key instead of a 128-bit key, and I don't know that
we should be encouraging it. After all, the expense is borne by two
systems, not just one.
--Steve Bellovin
Follow-Ups: