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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <22138FE2-9E79-4E24-99FC-74A35651B0C1@oracle.com>
Date:   Thu, 12 Nov 2020 10:49:03 -0500
From:   Chuck Lever <chuck.lever@...cle.com>
To:     David Howells <dhowells@...hat.com>
Cc:     CIFS <linux-cifs@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Bruce Fields <bfields@...ldses.org>,
        linux-crypto@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-afs@...ts.infradead.org
Subject: Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library



> On Nov 12, 2020, at 10:42 AM, David Howells <dhowells@...hat.com> wrote:
> 
> Chuck Lever <chuck.lever@...cle.com> 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