Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode

[Matt Mackall]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/