Re: Did the in-kernel Camellia or CMAC crypto implementation break?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 14, 2023 at 09:47:37AM +0100, David Howells wrote:
>
> 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).

Yes I've been meaning to split this up so they're colocated with
the generic implementation.

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

Unless this code has at least two users it's probably not worth
it (but there are exceptions, e.g. we did a one-user algorithm
for dm-crypt).

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux