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
