Re: [RFC][PATCH] Make cryptoapi non-optional?

Matt Mackall
2003-08-09T19:47:10Z

On Sat, Aug 09, 2003 at 10:39:10AM -0700, David S. Miller wrote:
> On Sat, 9 Aug 2003 09:05:42 -0500
> Matt Mackall <mpm@selenic.com> wrote:
>
> > All of which is a big waste of time if the answer to "is making
> > cryptoapi mandatory ok?" is no. So before embarking on the hard part,
> > I thought I'd ask the hard question.
>
> I'm personally OK with it, and in fact I talked about this with James
> (converting random.c over to the crypto API and the implications)
> early on while we were first working on the crypto kernel bits.
>
> But I fear some embedded folks might bark. Especially if the
> resulting code size is significantly larger.

An alternate approach is:

- pull the minimum parts of SHA (and perhaps MD5) out of their
respective cryptoapi modules into the core
- call that code directly from random, bypassing cryptoapi (and
avoiding all the dynamic allocation and potential sleeping stuff)

Combined with a patch that does non-unrolled SHA, this should be about
the same as the present code.

> We could make it a config option CONFIG_RANDOM_CRYPTOAPI.

As the primary benefit here is elimination of duplicate code, I think
that's a non-starter.

> All of this analysis nearly requires a working implementation so
> someone can do a code-size and performance comparison between
> the two cases. I know this is what you're trying to avoid, having
> to code up what might be just thrown away :(

Ok, can I export some more cryptoapi primitives?

__crypto_lookup_alg(const char *name);
__crypto_alg_tfm_size(const char *name);
__crypto_setup_tfm(struct crypto_alg *alg, char *buf, int size, int flags);
__crypto_exit_ops(...)
__crypto_alg_put(...);

This would let me do alg lookup in my init and avoid the dynamic
allocation sleeping and performance hits.

Also, I posted to cryptoapi-devel that I need a way to disable the
unconditional padding on the hash functions.

--
Matt Mackall : http://www.selenic.com : of or relating to the moon