On Thu, Aug 1, 2013 at 9:02 AM, .. ink .. <mhogomchungu@xxxxxxxxx> 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...
Ciprian.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
