On 27/06/2019 09:42, Ard Biesheuvel wrote: > 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. ok, for me (to keep only recommended variants and completely remove the rest). There should be no in-kernel users, and we have to deal with algorithms removal in userspace anyway. Milan
