Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > What is the reason for shoehorning any of this into the crypto API? I was under the impression that that was what Herbert wanted. > I agree with Eric here: it seems both the user (Kerberos) and the > crypto API are worse off here, due to mutual API incompatibilities > that seem rather fundamental. My original take on this was to take the sunrpc code and turn it into a library, placing that library in the crypto/ directory: https://lore.kernel.org/linux-crypto/160518586534.2277919.14475638653680231924.stgit@xxxxxxxxxxxxxxxxxxxxxx/ The crypto/ dir seems the right home for it (and not net/ or lib/), but the way it's implemented here, it's a user of the crypto API, but does not itself implement it. That said, it would be convenient if if *could* be part of the crypto API in some way. As I outlined in one of my responses to Herbert, there are a number of advantages to doing that. > Are you anticipating other, accelerated implementations of the > combined algorithms? I think one can be done with x86 AES and SHA instructions provided there are sufficient registers. > Isn't it enough to rely on the existing Camellia and AES code? The problem is that you have to do *two* crypto operations - and that it may not be possible to parallellise them. With AES+SHA1 and Camellia, they can be parallellised as both sides work on the plaintext; but with the AES+SHA2, the encryption is done and then the *encrypted* output is checksummed. Note that "parallellising" might mean launching an async hash request and an async skcipher request and then waiting for both to finish. This can't, however, be done unless the output buffer is separate from the input buffer. > Mentioning 'something like the Intel QAT' doesn't suggest you have something > specific in mind. I have an Intel QAT card, and under some circumstances I could offload the crypto to it... But the only operations the driver currently makes available are: authenc(hmac(sha1),cbc(aes)) authenc(hmac(sha256),cbc(aes)) authenc(hmac(sha512),cbc(aes)) The first one can't be used for kerberos's aes128-cts-hmac-sha1-96 as it hashes the ciphertext, not the plain text. I don't have anything that uses the third. The second is a possibility. I think that could probably do aes128-cts-hmac-sha256-128. Now, it's possible that the QAT device range can do more than the driver offers. I'm presuming that the driver offers what IPsec wants to support. Also, waving these ideas in front of Intel devs might expand the range of what future QATs can do ;-) Mostly, though, by "something like" I was just offering the possibility that other architectures or crypto cards may also offer usable services - but I haven't investigated. > Also, this patch is rather big and therefore hard to review. Yeah. Mostly I wanted to wave it in front of Herbert before expending the effort to slice it up. Sadly, it doesn't seem that what I came up with is what he wanted. David
