Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > Yeah - the problem with that is that for sunrpc, we might be dealing with 1MB > > plus bits of non-contiguous pages, requiring >8K of scatterlist elements > > (admittedly, we can chain them, but we may have to do one or more large > > allocations). > > > > > However, I would recommend against it: > > > > Sorry, recommend against what? > > > > Recommend against the current approach of manipulating the input like > this and feeding it into the skcipher piecemeal. Right. I understand the problem, but as I mentioned above, the scatterlist itself becomes a performance issue as it may exceed two pages in size. Double that as there may need to be separate input and output scatterlists. > Herbert recently made some changes for MSG_MORE support in the AF_ALG > code, which permits a skcipher encryption to be split into several > invocations of the skcipher layer without the need for this complexity > on the side of the caller. Maybe there is a way to reuse that here. > Herbert? 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. > > Can you also do SHA at the same time in the same loop? > > SHA-1 or HMAC-SHA1? The latter could probably be modeled as an AEAD. > The former doesn't really fit the current API so we'd have to invent > something for it. 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. David
