Taylor R Campbell <riastr...@netbsd.org> writes: >> Date: Thu, 18 Jun 2020 07:19:43 +0200 >> From: Martin Husemann <mar...@duskware.de> >> >> One minor nit: with the performance impact that high, and there being >> setups where runtime side channel attacks are totally not an issue, >> maybe we should leave the old code in place for now, #ifdef'd as >> default-off options to provide time for a full reconstruction (or untill >> the machine gets update to "the last decade" cpu)? > > Having leaky AES code around is asking for trouble -- and would > require additional complexity to implement and maintain (e.g., is it > always unhooked from the build, or do we hook it in just enough to run > tests?), which would add further burden on an audit to verify that > it's _not_ being used in a real application. > > The goals here are to make that burden completely go away by making > the answer unconditionally no, there's essentially no danger that AES > in the kernel is leaky; and to provide alternatives with performance > ranging from `not worse' to `much better' to avoid the conflict that > AES invites between performance and security. > > If you have a specific system where there's a real negative > performance impact that matters to you, I would be happy to talk over > the details and see how we can address it better.
I see your point, and I think this is probably ok, but I share Martin's concern. For me, the main use of cgd is to encrypt backup drives. I am therfore not really concerned about side channel attacks when they are attached and keyed on the system being backed up. (I realize other people use cgd for other reasons.) I don't really see the new cipher as a reasonable option for removable disks that need to be accessed by older systems. I can see it for encrypted local disk. But given AES hardware speedup, I suspect most people can just stay with AES. Is there an easy way to publish code that does hardware AES, to allow people to measure on their hardware? If a call for that on -users turns up essentially zero actual people that would be bothered, I think that would be interesting. I'm unclear on openssl and hardware support; "openssl speed" might be a good home for this, and I don't know if openssl needs the same treatment as cgd. (Fine to keep separable things separate; not a complaint!)
