Received-SPF: pass (google.com: domain of linux-kernel+bounces-23882-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
    Chuck Lever III <chuck.lever@oracle.com>
cc: dhowells@redhat.com, Jeff Layton <jlayton@kernel.org>,
    linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org,
    linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Rebuilding at least part of my krb5 crypto lib on crypto-aead
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2131431.1704991328.1@warthog.procyon.org.uk>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Jan 2024 16:42:08 +0000
Message-ID: <2131432.1704991328@warthog.procyon.org.uk>

Hi Herbert, Chuck,

I've been thinking more on how I might go about rebuilding at least part o=
f my
krb5 crypto library on top of the AEAD template.

I don't think it makes sense to try and put the entirety of it in there.
There are functions that completely don't fit (such as key generation) and=
 the
catalogue of Kerberos type values and associated parameters.

Also, I'm not sure it makes sense to try and squeeze the Integrity-type
operations get_mic and verify_mic as AEAD.  get_mic might work as AEAD, bu=
t
all a wrapper would add is to emplace the checksum into ciphertext buffer.
The actual checksumming is handled by a SHASH algorithm perfectly well.
verify_mic doesn't really make sense as it has no output other than "yes/n=
o" -
and so is also handled fine by a SHASH algorithm.

Where it does make sense is at the core of the encrypt/decrypt ops where I
have four compound ops to choose from:

	- encrypt-then-hash
	- hash-then-decrypt
	- hash-then-encrypt
	- decrypt-then-hash

These can conceivably be hardware optimised to do both parts of the op
simultaneously.  I *think* I've seen a suggestion that x86_64 AVX has
sufficient registers available to do both AES and SHA simultaneously, say.

The question I then have is this: How do I parameterise the crypto algorit=
hm
inside AEAD?  Can I do something like:

	cipher =3D crypto_alloc_sync_aead("enc-then-hash(cts(cbc(camellia)),cmac(=
camellia))");

David