On Wed, 26 Jun 2019 at 23:11, Samuel Neves <samuel.c.p.neves@xxxxxxxxx> wrote: > > , On Wed, Jun 26, 2019 at 8:40 AM Milan Broz <gmazyland@xxxxxxxxx> wrote: > > > > On 26/06/2019 09:15, Ard Biesheuvel wrote: > > > > > Thanks for the insight. So I guess we have consensus that MORUS should > > > be removed. How about aegis128l and aegis256, which have been > > > disregarded in favor of aegis128 by CAESAR (note that I sent an > > > accelerated ARM/arm64 version of aegis128 based on the ARMv8 crypto > > > instructions, in case you missed it) > > > > Well, there are similar cases, see that Serpent supports many keysizes, even 0-length key (!), > > despite the AES finalists were proposed only for 128/192/256 bit keys. > > (It happened to us several times during tests that apparent mistype in Serpent key length > > was accepted by the kernel...) > > I'm not sure the Serpent case is comparable. In Serpent, the key can > be any size below 256 bits, but internally the key is simply padded to > 256 bits and the algorithm is fundamentally the same. There are no > speed differences between different keys sizes. > > On the other hand, AEGIS128, AEGIS256, and AEGIS128L are different > algorithms, with different state sizes and state update functions. The > existing cryptanalysis of AEGIS consists solely of [1] (which is the > paper that directly inspired the MORUS cryptanalysis), which does not > look at AEGIS128L at all. In effect, to my knowledge there are no > known cryptanalytic results on AEGIS128L, which I imagine to be one of > the main reasons why it did not end up in the CAESAR portfolio. But > AEGIS128L is by far the fastest option, and a user is probably going > to be naturally tempted to use it instead of the other variants. > Indeed. So that would actually argue for removing the optimized x86 implementation, but tbh, I'd rather remove aegis128l and aegis256 entirely, given that no recommendations exist for its use in any particular context, and given the CAESAR outcome, that is unlikely to change in the future.
