Thread (28 messages) 28 messages, 6 authors, 2021-12-06

Re: [RFC PATCH v2 10/11] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions

From: Eric Biggers <ebiggers@kernel.org>
Date: 2021-05-17 23:33:16
Also in: lkml

On Mon, May 17, 2021 at 10:20:44PM +0000, Bae, Chang Seok wrote:
On May 17, 2021, at 14:34, Eric Biggers [off-list ref] wrote:
quoted
On Fri, May 14, 2021 at 01:15:07PM -0700, Chang S. Bae wrote:
quoted
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".)

- Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help