Messages in this thread | | | Date | Wed, 25 Feb 2004 21:39:32 +0100 | From | Christophe Saout <> | Subject | Re: cryptoapi highmem bug |
| |
On Wed, Feb 25, 2004 at 03:12:16PM -0500, Jean-Luc Cooke wrote:
> Here is the scatterlist+"Le Patch de Christophe": > http://jlcooke.ca/lkml/cryptowalk_christophe_25feb2004.patch
Andrew hat another idea that would be even shorter. I don't know if it's much cleaner though. Trying to implement it.
> Reguarding dm-crypt: > I didn't get a response back when suggesting we store IV and MAC info for > each block.
Yes, sorry, it's on my todo list (but I kept pushing it back because explaining the problems in detail would have taken a lot of time). ;)
> Can we do this?
It's very non-trivial. Think about journalling filesystems, write ordering and atomicity. If the system crashes between two write operations we must be able to still correctly read the data. And write to these "crypto info blocks" should be done in a ways that doesn't kill performance. Do you have a proposal?
It would make dm-crypt *a lot more* complicated. We need caches for the info blocks, etc...
> Can I do this? Where's the source, in > 2.3.6-main?
Which source? dm-crypt? In 2.6.3-bk and 2.6.3-mm*. Andrew's latest tree also has my first "more secure IV proposal" patch in it and I posted a (broken, racy) hmac IV patch in the other thread. - 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/
| |