Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > There are three main interfaces to it: > > > > (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic. > > > > These all do in-place crypto, using an sglist to define the buffer > > with the data in it. Is it necessary to make it able to take separate > > input and output buffers? > > Hi David, Wondering if these "I/O" APIs use synchronous or async > crypto under the covers. For small data items like MICs, synchronous > might be a better choice, especially if asynchronous crypto could > result in incoming requests getting re-ordered and falling out of > the GSS sequence number window. > > What say ye? For the moment I'm using synchronous APIs as that's what sunrpc is using (I borrowed the basic code from there). It would be interesting to consider using async, but there's a potential issue. For the simplified profile, encryption and integrity checksum generation can be done simultaneously, but decryption and verification can't. For the AES-2 profile, the reverse is true. For my purposes in rxrpc, async mode isn't actually that useful since I'm only doing the contents of a UDP packet at a time. Either I'm encrypting with the intention of immediate transmission or decrypting with the intention of immediately using the data, so I'm in a context where I can wait anyway. What might get me more of a boost would be to encrypt the app data directly into a UDP packet and decrypt the UDP packet directly into the app buffers. This is easier said than done, though, as there's typically security metadata inserted into the packet inside the encrypted region. David
