lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.073 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site