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

[Matt Mackall]

On Fri, Feb 27, 2004 at 10:16:36PM +0100, Christophe Saout wrote:
> Am Fr, den 27.02.2004 schrieb Matt Mackall um 21:55:
> 
> > I certainly understand the issues of deep vs shallow copy. What I'm
> > saying is we should try to avoid needing deep copies in the first
> > place. They invite lots of complexity and for something as
> > straightforward as a cipher or digest should not be necessary.
> 
> Right. But we should still keep the ->init, ->copy, ->exit mechanism
> complete then, just because it's there and not having them fore some
> cases makes things just incomplete. Or we set the methods to NULL and
> the copy function only works if both init and exit are null, so we don't
> need the copy method because it also would be NULL and we know the
> algorithm doesn't use external structures. This would work for "fixed
> up" cipher and digest algorithms.
> 
> There's just one small difficulty with having some of the structures in
> the context: Their size is variable. But known after the init function.
> So the cra_ctxsize isn't sufficient to describe the length of a tfm
> strucure. So we need another per-algorithm-category method that returns
> the additional size required. They might just return iv_size or iv_size
> + omac_pad_size for ciphers and hmac_pad_size for digests or something
> like this.

Hmmm, crypto_alloc_tfm does:

        tfm = kmalloc(sizeof(*tfm) + alg->cra_ctxsize, GFP_KERNEL);

So I'm not clear on how the necessary size can be anything else at
copy time?
 
> > > Hmm. It should be there, but could return -EOPNOTSUPP. Copying a
> > > compress tfm doesn't make much sense. We need a way to detect things
> > > that are bad in a generic way, everything else is hacky.
> > 
> > Some way of preventing copies of some TFMs is called for, agreed.
> 
> What about the idea above?
> 
> I could think we could start from my patch and simple throw 70% away. ;)
> (or yours, it isn't too far either)

Either way.

> I'd like too keep my names: (init), copy, exit vs. alloc, clone and
> free.

Not terribly concerned about the naming, so long as the header file
makes it clear that every copy needs a matching cleanup call and not a
free.

-- 
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/