Re: [RFC PATCH v2 10/11] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions
From: Eric Biggers
Date: Mon May 17 2021 - 19:33:10 EST
On Mon, May 17, 2021 at 10:20:44PM +0000, Bae, Chang Seok wrote:
> On May 17, 2021, at 14:34, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > On Fri, May 14, 2021 at 01:15:07PM -0700, Chang S. Bae wrote:
> >> Included are methods for ECB, CBC, CTR, and XTS modes. They are not
> >> compatible with other implementations as referencing an encrypted form
> >> only.
> > Your code uses the standard algorithm names like cbc(aes), which implies that it
> > is compatible with the standard cbc(aes). So which is it -- compatible or not
> > compatible -- and if it isn't compatible, what is the expected use case?
> Yes, it provides AES-CBC functionality. Well, it was intended to avoid mixed
> use of functions -- setkey(), decrypt(), and encrypt() -- from others.
> Perhaps, rewrite this as:
> Each method should not be used along with other implementations'. E.g., KL’s
> setkey() output can’t be used to the input to the encrypt() method of AES-NI or
> generic implementation.
Sure. But that is just the implementation, so not really as interesting as what
the user sees. I think you need to do a better job explaining what this looks
like from a user's perspective. It sounds like the answer is "it looks the
same" -- right? What is the benefit, exactly? (Please be more specific than
"it protects the AES keys".)