On Mon, Jun 24, 2019 at 09:38:12AM +0200, Ard Biesheuvel wrote: > Now that aegis128 has been announced as one of the winners of the CAESAR > competition, it's time to provide some better support for it on arm64 (and > 32-bit ARM *) > > This time, instead of cloning the generic driver twice and rewriting half > of it in arm64 and ARM assembly, add hooks for an accelerated SIMD path to > the generic driver, and populate it with a C version using NEON intrinsics > that can be built for both ARM and arm64. This results in a speedup of ~11x, > resulting in a performance of 2.2 cycles per byte on Cortex-A53. > > Patches #1 .. #3 are some fixes/improvements for the generic code. Patch #4 > adds the plumbing for using a SIMD accelerated implementation. Patch #5 > adds the ARM and arm64 code, and patch #6 adds a speed test. > > Note that aegis128l and aegis256 were not selected, and nor where any of the > morus contestants, and so we should probably consider dropping those drivers > again. > I'll also note that a few months ago there were attacks published on all versions of full MORUS, with only 2^76 data and time complexity (https://eprint.iacr.org/2019/172.pdf). So MORUS is cryptographically broken, and isn't really something that people should be using. Ondrej, are people actually using MORUS in the kernel? I understand that you added it for your Master's Thesis with the intent that it would be used with dm-integrity and dm-crypt, but it's not clear that people are actually doing that. In any case we could consider dropping the assembly implementations, though. - Eric
