From: Matt Mackall <mpm@selenic.com>
To: James Morris <jmorris@redhat.com>
Cc: Christophe Saout <christophe@saout.de>,
Jean-Luc Cooke <jlcooke@certainkey.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
James Morris <jmorris@intercode.com.au>
Subject: Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode
Date: Tue, 24 Feb 2004 14:24:43 -0600 [thread overview]
Message-ID: <20040224202443.GU3883@waste.org> (raw)
In-Reply-To: <Xine.LNX.4.44.0402241457330.25785-100000@thoron.boston.redhat.com>
On Tue, Feb 24, 2004 at 03:01:03PM -0500, James Morris wrote:
> On Tue, 24 Feb 2004, Matt Mackall wrote:
>
> > Something like:
> >
> > /* calculate the size of a tfm so that users can manage their own
> > copies */
> >
> > int crypto_alg_size(const char *name);
> >
> > /* copy a TFM to a user-managed buffer, possibly on stack, with proper
> > internal reference counting and any other necessary magic, size checks
> > against boneheaded buffer sizing */
> >
> > crypto_copy_tfm(char *dst, const struct crypto_tfm *src, int size);
>
> Does it need to be copied from an existing tfm? I think it would be
> cleaner to provide just a way to initialize a tfm.
Not sure about Christopher's case, but I think it actually might be
easier generally. First, copying rather than initializing ensures
we've already got the algorithm loaded and locked and don't have to
worry particularly whether we're in a difficult context.
Second, if there are cases (and this may be one, I forget the details
of HMAC) where there's significant per-use setup costs, having a
copying interface saves work. If you've got a copy interface, you
don't really need the second kind of user-managed initialize interface
I proposed earlier.
> > /* do all the necessary bookkeeping to release a user-managed TFM, use
> > char pointer to avoid alloc/free mismatch */
> >
> > crypto_copy_cleanup_tfm(char *usertfm);
> >
>
> This is doable.
Ok, I probably spin something like this in the next couple days.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
next prev parent reply other threads:[~2004-02-24 20:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-19 17:02 [PATCH/proposal] dm-crypt: add digest-based iv generation mode Christophe Saout
2004-02-19 19:18 ` Andrew Morton
2004-02-20 17:14 ` Jean-Luc Cooke
2004-02-20 18:53 ` Christophe Saout
2004-02-20 19:09 ` Jean-Luc Cooke
2004-02-20 19:23 ` Christophe Saout
2004-02-20 21:23 ` James Morris
2004-02-20 22:40 ` Christophe Saout
2004-02-21 0:07 ` James Morris
2004-02-21 2:17 ` Christophe Saout
2004-02-24 19:11 ` Matt Mackall
2004-02-24 19:43 ` Christophe Saout
2004-02-24 20:38 ` Matt Mackall
2004-02-25 21:43 ` Matt Mackall
2004-02-26 19:35 ` Christophe Saout
2004-02-26 20:02 ` Matt Mackall
2004-02-27 16:05 ` Christophe Saout
2004-02-27 18:37 ` Christophe Saout
2004-02-27 20:02 ` Matt Mackall
2004-02-27 20:13 ` Christophe Saout
2004-02-27 20:55 ` Matt Mackall
2004-02-27 21:16 ` Christophe Saout
2004-02-28 0:39 ` Matt Mackall
2004-02-28 13:02 ` Christophe Saout
2004-02-24 22:26 ` James Morris
2004-02-24 22:31 ` Christophe Saout
2004-02-24 22:45 ` James Morris
2004-02-24 20:01 ` James Morris
2004-02-24 20:24 ` Matt Mackall [this message]
2004-02-25 2:25 ` Christophe Saout
2004-02-25 3:05 ` Jean-Luc Cooke
2004-02-23 0:35 ` Fruhwirth Clemens
2004-02-23 13:44 ` Jean-Luc Cooke
2004-02-23 15:36 ` James Morris
[not found] <20040223214738.GD24799@certainkey.com>
[not found] ` <Xine.LNX.4.44.0402231710390.21142-100000@thoron.boston.redhat.com>
2004-02-24 20:22 ` Jean-Luc Cooke
2004-02-24 22:17 ` James Morris
2004-02-24 22:44 ` Jean-Luc Cooke
2004-02-25 13:52 ` James Morris
2004-02-25 15:11 ` Jean-Luc Cooke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040224202443.GU3883@waste.org \
--to=mpm@selenic.com \
--cc=akpm@osdl.org \
--cc=christophe@saout.de \
--cc=jlcooke@certainkey.com \
--cc=jmorris@intercode.com.au \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.