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

[Christophe Saout]

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.

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

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

Since the crypto_lookup_alg_tfm_size -> crypto_init_tfm thing is racy we
shouldn't implement it (at least for now). A solution would be to keep
an algorithm reference between both functions but that's ugly and
unintuitive. And if you want to do something like I suggested before you
can also use the copy mechanism.

So, we have an agreement then? :)


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