Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
In-Reply-To: <ZDi1qjVpcpr2BZfN@gondor.apana.org.au>
References: <ZDi1qjVpcpr2BZfN@gondor.apana.org.au> <48886D84-1A04-4B07-A666-BB56684E759F@oracle.com> <380323.1681314997@warthog.procyon.org.uk> <1078650.1681394138@warthog.procyon.org.uk>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     dhowells@redhat.com, Chuck Lever III <chuck.lever@oracle.com>,
        Scott Mayhew <smayhew@redhat.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        Jeff Layton <jlayton@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: Did the in-kernel Camellia or CMAC crypto implementation break?
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1235645.1681461986.1@warthog.procyon.org.uk>
From:   David Howells <dhowells@redhat.com>
Date:   Fri, 14 Apr 2023 09:47:37 +0100
Message-ID: <1235770.1681462057@warthog.procyon.org.uk>
Precedence: bulk

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Now that you have it working, perhaps you could convert some of
> your test vectors into crypto API test vectors?

Actually, I was wondering about that.  I see that all the testing data seems
to be statically loaded in testmgr.[ch], even if the algorithms to be tested
are resident in modules that aren't loaded yet (so it's kind of test "on
demand").  I guess it can't be split up amongst the algorithm modules as some
of the tests require stuff from multiple modules (eg. aes + cbs + cts).

If I'm going to do that, I presume I'd need to create an API akin to the
skcipher API or the hash API, say, to do autoload/create krb5 crypto.  Maybe
loading with something like:

	struct crypto_krb5 *alg;

	alg = crypto_alloc_krb5("aes256-cts-hmac-sha384-192", 0,
				CRYPTO_ALG_ASYNC);

and split the algorithms into separate modules?  Much of the code would still
end up in a common module, though.

Note that each algorithm can be asked to do four different things and has four
different types of test:

 - PRF calculation
 - Key derivation
 - Encryption/decryption
 - Checksum generation/verification

David