Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library

[Chuck Lever]

> On Nov 12, 2020, at 10:42 AM, David Howells <dhowells@xxxxxxxxxx> wrote:
> 
> 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).

Really? My understanding of the Linux kernel SUNRPC implementation is
that it uses asynchronous, even for small data items. Maybe I'm using
the terminology incorrectly.

The problem that arises is on the server. The asynchronous API can
schedule, and if the server has other work to do, that can delay a
verify_mic long enough that the request drops out of the GSS sequence
number window (even a large window).

Whatever the mechanism, we need to have deterministic ordering, at
least on the server-side.


> 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.


--
Chuck Lever