[dm-crypt] dm-crypt "inverted" usage (i.e. exporting an "encrypted" image of a block device)

Ciprian Dorin Craciun ciprian.craciun at gmail.com
Thu Aug 1 06:38:54 CEST 2013


On Thu, Aug 1, 2013 at 3:35 AM, Arno Wagner <arno at wagner.name> 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.


More information about the dm-crypt mailing list