Messages in this thread | | | Subject | Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode | From | Christophe Saout <> | Date | Tue, 24 Feb 2004 20:43:59 +0100 |
| |
Am Di, den 24.02.2004 schrieb Matt Mackall um 20:11:
> As this stands, it's rather scary. > > - it will quietly break when cryptoapi gets fiddled with > - it subverts the module reference counting rules > - for a given cipher/digest, tfm_size might be large > > Subverting the API this way is bad. On the other hand,
Right. That's why I repeated several times that this is a hack and Cc'ed James. I was either misunderstood or ignored.
> I tend to think > the API does need a way to deal with problem cases like these, so I'd > support extending the API in some fashion to handle it. Related (but > not identical) issues have cropped up with a few other things that > want to avoid serializing around a single or per-cpu context.
If you call encrypt/decrypt without the iv parameter but use cbc mode you will run into the same problem. This is right.
BTW: I think there's a bug in the ipv6 code, it uses spin_lock to protect itself, this will cause a sleep-inside-spinlock warning. (found while grepping through the source for other cryptoapi users)
> Something like: > > /* calculate the size of a tfm so that users can manage their own > copies */ > > int crypto_alg_size(const char *name);
crypto_tfm_size?
> /* 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); > > /* 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);
Yes, I thought of something like this.
- 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/
| |