On Mon, 7 Dec 2020 at 15:15, David Howells <dhowells@xxxxxxxxxx> wrote: > > Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > I wonder if it would help if the input buffer and output buffer didn't > > > have to correspond exactly in usage - ie. the output buffer could be used > > > at a slower rate than the input to allow for buffering inside the crypto > > > algorithm. > > > > > > > I don't follow - how could one be used at a slower rate? > > I mean that the crypto algorithm might need to buffer the last part of the > input until it has a block's worth before it can write to the output. > This is what is typically handled transparently by the driver. When you populate a scatterlist, it doesn't matter how misaligned the individual elements are, the scatterlist walker will always present the data in chunks that the crypto algorithm can manage. This is why using a single scatterlist for the entire input is preferable in general. > > > The hashes corresponding to the kerberos enctypes I'm supporting are: > > > > > > HMAC-SHA1 for aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96. > > > > > > HMAC-SHA256 for aes128-cts-hmac-sha256-128 > > > > > > HMAC-SHA384 for aes256-cts-hmac-sha384-192 > > > > > > CMAC-CAMELLIA for camellia128-cts-cmac and camellia256-cts-cmac > > > > > > I'm not sure you can support all of those with the instructions available. > > > > It depends on whether the caller can make use of the authenc() > > pattern, which is a type of AEAD we support. > > Interesting. I didn't realise AEAD was an API. > > > There are numerous implementations of authenc(hmac(shaXXX),cbc(aes)), > > including h/w accelerated ones, but none that implement ciphertext > > stealing. So that means that, even if you manage to use the AEAD layer to > > perform both at the same time, the generic authenc() template will perform > > the cts(cbc(aes)) and hmac(shaXXX) by calling into skciphers and ahashes, > > respectively, which won't give you any benefit until accelerated > > implementations turn up that perform the whole operation in one pass over > > the input. And even then, I don't think the performance benefit will be > > worth it. > > Also, the rfc8009 variants that use AES with SHA256/384 hash the ciphertext, > not the plaintext. > > For the moment, it's probably not worth worrying about, then. If I can manage > to abstract the sunrpc bits out into a krb5 library, we can improve the > library later. >
