Messages in this thread | | | Date | Sat, 9 Aug 2003 14:46:27 -0500 | From | Matt Mackall <> | Subject | Re: [RFC][PATCH] Make cryptoapi non-optional? |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |