Re: cryptoapi highmem bug

[Jean-Luc Cooke <jlcooke@certainkey.com>]

On Wed, Feb 25, 2004 at 09:39:32PM +0100, Christophe Saout wrote:
> >  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). ;)

:)  That's cool.

> >  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?

I see.  From a security point of view, no.  OMACs need to be updated after
the data is updated to keep integrity checks passing.  IVs need to be updated
before the data is updated or plaintext is leaked. (IV + data + OMAC can be
written to device at once).

I assume then that IVs and OMACs will not be stored in the same read-chunk as
the data then?  Bummer if this is the case.

> It would make dm-crypt *a lot more* complicated. We need caches
> for the info blocks, etc...

Yes I see how that would be nasty.  But I've never written for things this
low to the device so you are likly better off without me.

> >  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/

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6