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".) - Eric
