Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Grzegorz Kulewski <kangur@polcom.net>]

Thanks for your fast response!

On Mon, 16 Feb 2004, Christophe Saout wrote:

> Am Mo, den 16.02.2004 schrieb Grzegorz Kulewski um 03:07:
> 
> > > Is there more documentation that this?  I'd imagine a lot of crypto-loop
> > > users wouldn't have a clue how to get started on dm-crypt, especially if
> > > they have not used device mapper before.
> > > 
> > > And how do they migrate existing encrypted filesytems?
> > 
> > And is the format considered "stable"?
> > (= if I will create fs on it, will I have problems with future kernels?)
> 
> Yes. The cryptoloop compatible format will stay this way. The format
> (basically the cipher used and the iv generation mode) can be specified.
> 
> I posted a small description some time ago:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105967481007242&w=2
> 
> The -cbc was renamed to -plain in order to make more iv generation
> methods possible which of course also use the CBC mode.

Did you heard / read about Herring?
I found .pdf somewhere (I think I still have it). It is better alternative 
to ECB or CBC algorithms used in cryptoloop (if I understand good). Could 
something like that be implemented in dm-crypt? Is it already?

Could somebody write dm-compress (compressing not encrypting)? Is it 
technically possible (can device mapper handle different data size at 
input, differet at output)? (I think there is compressing loop patch.)
Could dm first compress data (even with weak algorithm), then encrypt, to 
make statistical analysis harder?

And, to be sure, does dm-crypto add anything in the begining (ie. 
header) or in other places to the stored data? Or it is the same data 
(same size) but encrypted?  


Grzegorz Kulewski