Messages in this thread | | | Subject | Re: [PATCH] loop: fixing cryptoloop troubles. | From | Christophe Saout <> | Date | Mon, 11 Aug 2003 18:16:10 +0200 |
| |
Am Mo, 2003-08-11 um 15.11 schrieb Fruhwirth Clemens:
> > The main problem with CBC is that you can't really do it. It only works > > when you have a constant stream of data because you always need the > > result from the previous encryption which you don't have when doing > > something in the middle of the block device. > > That's partially correct. As most block cipher operate on blocks of 16 bytes > size it perfectly makes sence to use CBC on a 512 byte block.
Ah, you're right, I didn't look at it enough to see that the loop in cipher.c only handles bsize bytes at once.
> > The cryptoloop code is doing things correctly. In ecb mode, every bio > > could get converted at once, or every bvec. > > ECB mode is broken in 2.6.0-test[12].
I was speaking theoretically ;)
> It's a quite conservative patch. ECB processing can be optimized.
Yes, you're not restricted to split the request into 512 byte chunks. But I don't think it's too much of a performance loss. Or should it better be handled differently? Because I'm not doing it either in my code.
> Definitly. loop.c is anyway ugly :). It would be nice to rip out the > block-backend stuff of loop.c and recommend to use device mapper instead. > loop.c will benefit from that for sure since it doesn't have to handle two > different case in such a schizophrenic manner.
That's right. I could also write a losetup-like user space utility that sets up a linear mapped device with the full size of the block device and optionally uses encryption.
What do you think of this passphrase thing? I could optionally link a against openssl or such a library to offer password hashing.
> I'll give it a try, promised :)
That'd be nice. :)
-- Christophe Saout <christophe@saout.de> Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
- 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/
| |