On Thu, Aug 1, 2013 at 3:35 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
> I think you have it backwards.
> Export the raw device, do the usual
> decryption (for reading) and encryption (for writing) remotely.
I have good knowledge of the principles on how dm-crypt works; I
use it myself on a lot of partitions (and on all of them in the non
LUKS variant and never lost any data due to miss-configuration).
However in this particular case this is exactly what I want to do:
use dm-crypt backwards (but twice, once on the server, and then once
again on the client). :D
> 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?
I think I didn't explain very well the situation: on the server
side the block device is not encrypted, and I can't (better said don't
need to) encrypt it.
My real use-case is something like this:
* I have some disks on a machine and most of the time use them
from there; but because the machine is pretty secure physically (i.e.
in an access controlled room) I don't need encryption on those disks;
* but for some reasons I intend to switch the usage of those disks
from that machine to another (for example it could be better CPU and
more RAM available on the remote machine); of course this export is
going to be exclusive (i.e. its either mounted or one or the other
machine);
* (I would prefer not to use NFS, CIFS, etc. for this particular
use-case mainly because I need the full native file-system semantic
and features, and for a performance reason; the network channel is
GigaBit, and on the remote side I could use dm-cache or similar on
SSD;)
* however the export is done over a network I don't fully control;
* none of the transport mechanisms that I can think of (i.e.
iSCSI, ATAoE, or Linux's NBD) support encryption themselves and
require me to secure the underlaying network layer (either through
VPN's or IPSec), a thing which I find overly convoluted, and error
prone for this use case;
As such the ideal solution that I came-up with is to somehow use
dm-crypt as the encryption layer. The advantages are pretty nice:
* they key management is trivial, and the keys can be re-generated
each time I do the "export"; (because the data is stored in plain,
and thus the encryption is only transient it doesn't matter which keys
are used except, except that I must use the same on the both sides;)
* there is no network overhead due to the security (i.e. no
additional data in each packet);
* and I would assume that the performance could be better compared
with any other scenario;
Thanks for the feedback,
Ciprian.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
