Re: dm-crypt, new IV and standards

[Adam J. Richter]

At 2004-02-19 22:20:37, Christophe Saout wrote:
>I've started to write a userspace program for reencryption. I don't know
>if this is very clever because I have to lock the part that is currently
>beeing reencrypted (deadlocks & co). Perhaps as another dm target like
>dm-mirror for pvmove? We'd have to keep a log or something because we
>don't *exactly* know what has been successfully written. This would mean
>a lot of seeks. It's complicated if it has to be safe against crashes
>and power outages.

	Device-mapper already has support for different regions of a
device being mapped differently (for example a single disk where
0-100GB is mapped to disk A, 100GB-200GB is mapped to disk B), and
I believe it has some support for changing this mapping while the
device is opened or mounted.  So, if you wanted to add support for
rekeying an encrypted block device while it is active, you could
probably do it in fewer lines of code with an approach based on
device-mapper than one based on a device.

	One scheme for reencryption with minimal extra seeks and
data transfers would be to configure a gap of, say, 128kB, at the
front (or back) of a block device.  During rekeying, this gap would
incrementally be moved forward (or backward).  The area before the
gap would be encrypted with key A, and the area after
the gap would be encrypted with key B.  Before you move the gap,
you arrange so that the old location of the gap has the same
contents as the new location of the gap, except that the old location
was encrypted with the old key, and the new location was encrypted with
the new key.  I can detail this more if my description is unclear,
but I suspect you get the picture.

Adam J. Richter     __     ______________   575 Oroville Road
adam@xxxxxxxxxxxxx     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
-
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/