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: <2380561.1605195776@warthog.procyon.org.uk>
Date:   Thu, 12 Nov 2020 15:42:56 +0000
From:   David Howells <dhowells@...hat.com>
To:     Chuck Lever <chuck.lever@...cle.com>
Cc:     dhowells@...hat.com, CIFS <linux-cifs@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Bruce Fields <bfields@...ldses.org>,
        linux-crypto@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-afs@...ts.infradead.org
Subject: Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library

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

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