I think you have it backwards. Export the raw device, do the usual decryption (for reading) and encryption (for writing) remotely. You cannot use the device locally anyways, or you run into consistency issues. Hence there is no reason to have the raw device plain. Or is there any reason why you need the plain device on the machine that has the raw device? Arno On Wed, Jul 31, 2013 at 10:28:19PM +0300, Ciprian Dorin Craciun wrote: > Hello all! (I hope that with this post I'll have more luck than > with the last one...) :) > > As I've tried to express in the subject I'm interested in finding > a way to use the dm-crypt target in a "reversed" way, i.e instead of > decrypting I would like to use it to encrypt a block device, and then > with a second dm-crypt target (on top of the previous one) to decrypt > it again. > > > More specifically, I envisage the following use case: > > * let's assume we have a block device that is un-encrypted; > * let's assume that we want to export this block device over an > untrusted channel, via a mechanism that lacks any confidentiality; > (let's assume ATAoE, where I don't control the switching fabric, or > NBD, etc.;) > > * (I want to stress the fact that my main concern here is only > data confidentiality, not integrity, nor access control; better said, > in the unlikely case when someone is able to control the network > fabric to change or inject packets, I don't care if the attacker > mangles the reads or writes that reach one of the peers, I just don't > want the attacker to gain access to the original data just by > "looking" at the network;) > > * thus I would like to use the dm-crypt target to obtain an > encrypted image of the original block device; this target is the one > exported over the untrusted channel; > * on the remote end I would like to again use the dm-crypt target > (possibly with different arguments) to decrypt the imported image, and > thus obtaining the original one; > > > Thus does anyone know of any method to make dm-crypt behave in > such a manner? > > > Now as potential solutions, off the top of my head, I see the > following ones: > > > (A) The one that I assume would be the correct one, and the one > that would work with any chosen algorithm, implies reversing the usage > of algorithms for read and write operations on the exporting side; > i.e. when reading a block one would use the encryption mode, meanwhile > when writing one would use decryption mode. > > Thus on the exporting (server) side one would need to use the > "reversed" mode as above, meanwhile on the importing (client) side one > would use the "normal" (current) variant of the target. > > Unfortunately this solution implies patching the kernel, adding a > way to transmit this reversal through the table arguments, etc. > Practically this would take forever to get in upstream. > > > (B) The one that I'm less certain is cryptographically correct, > but which could work even "today" (I hope): one should identify a > dm-crypt mode (i.e. cipher + chaining + IV) that is completely > symmetric (i.e. whose encrypt algorithm is identical with the decrypt > one); examples of such modes would be AES with OFB (output feedback) > or CTR (counter) which don't use the decrypt algorithm of AES > (statement based on my knowledge of these modes and Wikipedia, thus > not on facts). Of these I think only CTR is implemented. > > > (C) This third case falls in the category of "what if?", thus > plain speculation without any fact: are there any dm-crypt modes > (again cipher + chaining + IV) that are involutions; i.e. applying > the same mode twice, one on-top of the other would undo all the > effects both for read and write operations? > > > I would love to receive some feedback for this problem. > > Thanks, > Ciprian. > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
