lkml.org 
[lkml]   [2003]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:47    [W:0.022 / U:32.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site