Re: [PATCH 2/2][RFC] Add dm-crypt target

[Christophe Saout <christophe@saout.de>]

Am Di, den 23.12.2003 schrieb Mike Fedyk um 00:50:

> > dm-crypt should not be constrained by cryptoloop, and vice versa.
> 
> It seems dm-crypt was meant to overcome the problems with loop against block
> devices.  If it uses another format, it would loose that ability to be a
> replacement, and unless there are shortcomings in the format, why should
> there be a change?

The target option line is quite flexible. It could be used to list the
required crypto features. If only an encryption cipher is selected, it
would be backward compatible with the cryptoloop on-disk format (like it
is now). But when additional options are given IV hashing could be
turned on, another option could turn on block shuffling or something.

I'm currently having a private conversation with the cryptoloop
maintainer. The possibilities in cryptoloop are mainly restricted by the
losetup interface, he would love to have more possibilities. There are a
lot of things that could and should be implemented.

> Also, while cryptoloop on block devices may be bass ackwards to get
> encryption (use a driver meant to turn files into block devices on another
> block device since there is now crypto tied into it...), if there's another
> format, won't that data become inaccessable unless it's in a block device,
> or do you get the dm-crypt -> loop -> file in the case a dm-crypt image gets
> copied to a file?

dm-crypt -> loop -> file should work. Just like LVM on top of a file,
I've already done that before.

--
Christophe Saout <christophe@saout.de>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html