Re: AES leaks, cgd ciphers, and vector units in the kernel

[Greg Troxel <gdt%lexort.com@localhost>]

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

>> Date: Thu, 18 Jun 2020 07:19:43 +0200
>> From: Martin Husemann <martin%duskware.de@localhost>
>> 
>> 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!)