[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new second mandatory IPsec cipher - updated choice list
Helger Lipmaa wrote:
> (... Rijndael is also one of the leading AES
> candidates, while the successor of CAST-128, CAST-256, is most probably
> not going to make it to the second round of candidates).
Judging by comments I'm seeing on assorted lists, you're likely right.
> Why?
I see no particularly good reasons. CAST-256 is one of my favorite
candidates, largely because the design is conservative and based on
much good research. On the other hand, I'm impressed with many of
the others, especially Serpent.
> * Rijndael is based on the design of Shark, and Square. Square has been
> known for 2.5 years and _no weaknesses_ in it have been found.
CAST-256 is based on CAST-128, which has been out longer, widely used
commercially (Entrust, PGP,...), and has had lots of research and analysis
papers published about it. No known weaknesses.
> * The theory behind Rijndael (or Square) seems to guarantee
> that completely new type of attacks should be invented to break them.
Yes, but many of the AES candidates offer some (at least apparently)
good theoretical ideas.
> * Rijndael is (most probably) much more secure than unbroken Square
> due to the added rounds.
Yes, but Serpent presents a security analysis showing it is secure
against all known attacks, then doubles the number of rounds, and
CAST-256 increases rounds over unbroken CAST-128 and ....
> Moreover, Rijndael is the fastest AES candidate `in average' (cf
> http://home.cyber.ee/helger/aes/) and free of patents.
Serious advantages, but several other AES candidates have been
declared freely implementable by their proposers.
> Thus, I'd advocate strongly for including Rijndael at least to RFC 2451.
I'd say its too soon for any of the AES candiadtes as a MUST.
On the other hand, I'd argue that as soon as NIST cuts the field to
about five for round two (which is due to happen this summer), all
five should become MAY implement items listed in the RFC, numbers
should be assigned for all, and the working group should state
its intent to make the winner a MUST. This would encourage
implementers to be ready for the winner when it comes, by getting
experience with the AES 128-bit block size. It might also contribute
to AES via real world implementation and use experience.
> But, I would personally oppose to any additional MUST algorithms atm (IDEA
> would be the only exception if there were no patents).
I'd like CAST-128 as a MUST or at least SHOULD now, AES later.
References: