[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 09:00:04 CEST 2013

On Thu, Aug 1, 2013 at 9:02 AM, .. ink .. <mhogomchungu at gmail.com> wrote:
> I dont quite get what you are trying to do and the doing things "backwards"
> suggests lack of understanding of how things work,atleast lack of
> understanding according to my understanding of how things work :-)

    Could be...  :)

> Lets start with how things work.
> 1. You start with a device "/dev/sdc1".
> 2. You create an mapper path to it,let say at "/dev/mapper/sdc1".
> The way it works is that,you send plain text data to "/dev/mapper/sdc1" and
> the data land ciphertexted at "/dev/sdc1".You want your plain text back from
> "/dev/sdc1" and you read it from "/dev/mapper/sdc1" and you get your plain
> text data back.

    Yup.  This is the "normal" usage.

> I guess by "backwards",you mean starting with a plain text data at
> "/dev/sdc1" and then create ciphertext version of the data by reading
> "/dev/mapper/sdc1" and then sending the cipher text data over the network
> and then transforming the cipher text back to plain text by writing to
> another mapper path attached to another device on the other computer?..

    Exactly.  This is my "backward" usage (almost).

    I'll do a diagram below so that there isn't any doubt about what
I'm looking for:

    (A) /dev/sdb1 holds plain text data;
    (B) /dev/mapper/sdb1-ciphered, wraps /dev/sdb1 and provides an
encrypted version;
    ---- network layer ----
    (C) /dev/nbd1 is the 1:1 image of /dev/mapper/sdb1-ciphered
    (D) /dev/mapper/nbd1-plain, unwraps the above and provides the
exact same data as /dev/sdb1 above;

    Thus in my usecase I need twice dm-crypt:
    * once in (B) to behave "backwards";
    * once in (D) to behave exactly as it behaves today;

    One read would be like this:
    read-on-d (sect) = decrypt-on-d (key, sect, encrypt-on-b (key,
sect, read-on-a (sect)))

    As said, I guess this can be obtained in two ways:
    * either if there is a "backward" mode for dm-crypt;  (which I'm
not aware of;)
    * or by using a dm-crypt mode (I guessed aes-ctr-XXX) which
applied twice should null itself.

> The "backward" way should be easily testable.
> 1. create a 512 Byte plain text file( file A ) and put known content in it.
> 2. open a PLAIN mapper against the file with a certain password.
> 3. read 512 Bytes from the mapper attached to "file A" and hold on to it.
> 4. create another 512 Byte file( file B ).
> 5. open a PLAIN mapper against "file B" using the same password used above.
> 6. write to the mapper attached to "file B".
> 7. compare the contents of file B against those on file A,will they match or
> will they not?

    I don't think this test is correct.  Because you use a read on one
side and a write on the other.  I guess that it will work only if the
dm-crypt mode is something like aes-ctr-XXX, where both the encryption
and decryption method is identical (i.e. exactly the same algorithm,
because AES in CTR mode behaves just like a stream chipher).

    Meanwhile the correct test should involve two "stacked" reads as
explained.  (I intend to do this test soon if time permits.)

> At the end of the day,you are just sending encrypted data over the
> network.Dealing with raw devices seems like a disaster waiting to happen. How
> can you tell the data you just received over the network arrived as it was
> sent and there is not data corruption?

    The over-the-network data integrity should be guaranteed by the
block-device exporting solution used, i.e.:
    * iSCSI and NBD use TCP, thus data integrity should be already covered;
    * ATAoE covers this explicitly;

> Do you of all voodoo file systems do
> to guarantee data integrity?

    They should, but they don't, except ZFS and Btrfs...


More information about the dm-crypt mailing list