netdev - Re: [RFC PATCH 03/24] crypto: Add 'krb5enc' hash and cipher AEAD algorithm

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: <20250120204721.GA53305@sol.localdomain>
Date: Mon, 20 Jan 2025 12:47:21 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Simon Horman <horms@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Chuck Lever <chuck.lever@...cle.com>,
	Trond Myklebust <trond.myklebust@...merspace.com>,
	"David S. Miller" <davem@...emloft.net>,
	Marc Dionne <marc.dionne@...istor.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Ard Biesheuvel <ardb@...nel.org>, linux-crypto@...r.kernel.org,
	linux-afs@...ts.infradead.org, linux-nfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 03/24] crypto: Add 'krb5enc' hash and cipher AEAD
 algorithm

On Mon, Jan 20, 2025 at 08:18:14PM +0000, David Howells wrote:
> Eric Biggers <ebiggers@...nel.org> wrote:
> 
> > In any case, why would you need anything to do asynchronous at all here?
> 
> Because authenc, which I copied, passes the asynchronocity mode onto the two
> algos it runs (one encrypt, one hash).  If authenc is run synchronously, then
> the algos are run synchronously and serially; but if authenc is run async,
> then the algos are run asynchronously - but they may still have to be run
> serially[*] and the second is dispatched from the completion handler of the
> first.  So two different paths through the code exist, and rxgk and testmgr
> only test the synchronous path.

No, it goes in the other direction.  The underlying algorithms decide whether
they are asynchronous or not, and that gets passed up.  It sounds like what you
want to do is test your template in the case where the underlying algorithms are
asynchronous.  There is a way to do that by wrapping the underlying algorithms
with cryptd.  For example the following works with gcm:

python3 <<EOF
import socket
s = socket.socket(socket.AF_ALG, 5, 0)
s.bind(("aead", "gcm_base(cryptd(ctr(aes-generic)),cryptd(ghash-generic))"))
EOF

This really should just be thought of as complying with the outdated design of
the crypto API, though.  In practice synchronous is the only case that really
matters.

> [*] Because in authenc-compatible encoding types, the output of the encryption
> is hashed.  Older krb5 encodings hash the plaintext and the hash generation
> and the encrypt can be run in parallel.  For decrypting, the reverse is true;
> authenc may be able to do the decrypt and the hash in parallel...  But
> parallellisation also requires that the input and output buffers are not the
> same.

The right way to optimize cases like that is to interleave the two computations.
Look at how the AES-GCM assembly code interleaves AES-CTR and GHASH for example.
Doing something with async threads is the completely wrong solution here and
would be much slower.  The amount of time needed to process a single message is
simply far too short for multithreading to be appropriate on a per message
basis.

- Eric