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

[Christophe Saout]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/