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

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

[Ciprian Dorin Craciun]

    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.

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

[Arno Wagner]

I think you have it backwards. Export the raw device, do the usual 
decryption (for reading) and encryption (for writing) remotely.
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?

Arno

On Wed, Jul 31, 2013 at 10:28:19PM +0300, Ciprian Dorin Craciun wrote:
>     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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

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

[Ciprian Dorin Craciun]

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

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

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

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 :-)

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.

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?..

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?


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? Do you of all voodoo file
systems do to guarantee data integrity?

[-- Attachment #2: Type: text/html, Size: 2038 bytes --]

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

[Ciprian Dorin Craciun]

On Thu, Aug 1, 2013 at 9:02 AM, .. ink .. <mhogomchungu@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...

    Ciprian.

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

[Milan Broz]

On 1.8.2013 9:00, Ciprian Dorin Craciun wrote:
>      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;)

No, there is not.

I hope I understand your use case correctly, bu if so, this mode
(transport over network) _cannot_ be secure.

Imagine reply attack - anyone on the way can replace old ciphertext
and you have no chance to detect it.

An example of this (very simplified) attack:
Imagine user removal. The tool (userdel) first reads /etc/shadow and
then writes it (with user removed).

Listener can e.g. revert user removal without key knowledge, he only
need to detect correct packets for this transaction and replace content
to previous version (so files remains unchanged).
No key needed, just reply manipulation with ciphertext.

Proper network encryption will detect this.

If you mean this as some experiment, good (but I think it is not
possible without switching encrypt/decrypt in dmcrypt code or in encryption
cipher module, but will think about it more later :-)

But if you mean this seriously - do not do it. Use encrypted connection
(ipsec/vpn/ssh tunnel whatever). Only these tools are designed for newtork
connection protection.

BTW I use this as a classic example of misuse of FDE...
http://mbroz.fedorapeople.org/talks/DevConf2012/img8.jpg

Milan

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

[Ciprian Dorin Craciun]

On Thu, Aug 1, 2013 at 10:43 AM, Milan Broz <gmazyland@gmail.com> wrote:
> On 1.8.2013 9:00, Ciprian Dorin Craciun wrote:
>>
>>      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;)
>
>
> No, there is not.
>
> I hope I understand your use case correctly, bu if so, this mode
> (transport over network) _cannot_ be secure.

    Indeed such a solution I'm after won't be "completely" secure (as
a matter of fact nothing can be completely as that would imply
perfection).  And in my particular use case I don't need it.

    To get deeper into this subject, I guess that for an "acceptably"
secure one would expect at least the following:
    * initial authentication of the endpoints (could be solved by
things like challenge-response, etc.);
    * data integrity (only against data corruption) between the
endpoints (is already solved by TCP, etc.);
    * data confidentiality between the endpoints (could be solved by dm-crypt);
    * data authentication (which implies integrity) between the
endpoints (could be solved by SSL/TLS, which will also solve the
previous point of confidentiality);


    However I'm only interested in data confidentiality.


> Imagine reply attack - anyone on the way can replace old ciphertext
> and you have no chance to detect it.
>
> An example of this (very simplified) attack:
> Imagine user removal. The tool (userdel) first reads /etc/shadow and
> then writes it (with user removed).
>
> Listener can e.g. revert user removal without key knowledge, he only
> need to detect correct packets for this transaction and replace content
> to previous version (so files remains unchanged).
> No key needed, just reply manipulation with ciphertext.
>
> Proper network encryption will detect this.

    Indeed such an attack is possible.  Moreover an attacker can do
far worse things:
    * he could send write requests with arbitrary data that would
completely corrupt my block device;
    * he could clone the entire disk (albeit encrypted) in the hope to
decrypt it off-line later;
    * the type of sophisticated attack you've described above; etc.;


    However in my particular case such an attacker would be very
unlikely.  As such I only need the marginal protection against data
snooping.  (As I said the exported image is already un-encrypted on
the host machine which is in an access controlled room.  Thus anyone
sufficiently motivated to mount such an attack, would find it easier
to just get in that room and clone the disk...)

    Moreover I try to weigh between "good security" and "good
performance", and in my concrete case I lean towards "good
performance" (i.e. saturating GigaBit connection with reduced
latency).


> If you mean this as some experiment, good (but I think it is not
> possible without switching encrypt/decrypt in dmcrypt code or in encryption
> cipher module, but will think about it more later :-)

    As said I guess (i.e. I speculate based on basic knowledge of how
dm-crypt, its modes, and encryption algorithms work) that even today
it could be done by stacking two dm-crypt's (one on each peer) in
aes-ctr mode.


> But if you mean this seriously - do not do it. Use encrypted connection
> (ipsec/vpn/ssh tunnel whatever). Only these tools are designed for newtork
> connection protection.

    Again I completely understand and agree with this.  However as
said, I want to trade security for a little bit of performance and
convenience.


> BTW I use this as a classic example of misuse of FDE...
> http://mbroz.fedorapeople.org/talks/DevConf2012/img8.jpg

    Nice slide.  It perfectly illustrates your point.  (And it's
exactly the rule I want to "break").  :)

    Ciprian.

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

[Milan Broz]

On 08/01/2013 11:49 AM, Ciprian Dorin Craciun wrote:
> On Thu, Aug 1, 2013 at 10:43 AM, Milan Broz <gmazyland@gmail.com> wrote:
>> On 1.8.2013 9:00, Ciprian Dorin Craciun wrote:
>>>
>>>      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;)
>>
>>
>> No, there is not.
>>
>> I hope I understand your use case correctly, bu if so, this mode
>> (transport over network) _cannot_ be secure.
> 
>     Indeed such a solution I'm after won't be "completely" secure (as
> a matter of fact nothing can be completely as that would imply
> perfection).  And in my particular use case I don't need it.

Well, you have been warned... and you can always shoot yourself in the foot ;-)

I think that quick hack to try it would be to write simple kernel
cipher module (or wrapper), where you only change cipher name
(so it will not mix up with normal implementation, name like reverse_aes or so)
and just switch encrypt/decrypt callbacks.

I am afraid you will need to avoid LUKS and IV where encryption
is used (ESSIV) (or at least you must analyze if encrypt/decrypt change
for the given cipher is safe for use there).

Then just use this reverse cipher for exported disk only.

IMHO configuring openVPN an just use iscsi over it is better, more secure
and you do not need to hack around it.
For saturating Gigabit network you need fast cpu anyway.

Milan

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

[Arno Wagner]

On Thu, Aug 01, 2013 at 12:41:34PM +0200, Milan Broz wrote:
> 
> On 08/01/2013 11:49 AM, Ciprian Dorin Craciun wrote:
> > On Thu, Aug 1, 2013 at 10:43 AM, Milan Broz <gmazyland@gmail.com> wrote:
> >> On 1.8.2013 9:00, Ciprian Dorin Craciun wrote:
> >>>
> >>>      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;)
> >>
> >>
> >> No, there is not.
> >>
> >> I hope I understand your use case correctly, bu if so, this mode
> >> (transport over network) _cannot_ be secure.
> > 
> >     Indeed such a solution I'm after won't be "completely" secure (as
> > a matter of fact nothing can be completely as that would imply
> > perfection).  And in my particular use case I don't need it.
> 
> Well, you have been warned... and you can always shoot yourself in the foot ;-)

And you will. Even exporting the encrypted block device is 
insecure (i.e. "doing it right"), as disk encryption
has a different attacker mdoel than communication encryption
and different limitations. If, at some time, you decide you 
actually want to be secure, move to any VPN-tunnel like 
solution.

Arno 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

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

[Erik Logtenberg]

Maybe I also don't understand your use case well enough, but it seems to
me that using dd over ssh would kinda do the trick, right?

If you just want all your files over the network safely, use rsync over
ssh. You say that you want to retain the native features of the
filesystem itself, so as far as rsync doesn't have support for the
specific features you're talking about (snapshots for example), just use
dd to copy over the entire filesystem.

On the sending machine you use something like:
# dd if=/dev/device | ssh root@receiving_system dd of=/dev/device

Or if your sending machine doesn't have access to your receiving system,
do something like this on your receiving system instead:

# ssh root@sending_system dd if=/dev/device | dd of=/dev/device

With regards to security, you now have everything that ssh offers, and I
think most would agree that ssh is secure enough for all practical purposes.

Regards,

Erik.




On 08/01/2013 03:34 PM, Arno Wagner wrote:
> On Thu, Aug 01, 2013 at 12:41:34PM +0200, Milan Broz wrote:
>>
>> On 08/01/2013 11:49 AM, Ciprian Dorin Craciun wrote:
>>> On Thu, Aug 1, 2013 at 10:43 AM, Milan Broz <gmazyland@gmail.com> wrote:
>>>> On 1.8.2013 9:00, Ciprian Dorin Craciun wrote:
>>>>>
>>>>>      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;)
>>>>
>>>>
>>>> No, there is not.
>>>>
>>>> I hope I understand your use case correctly, bu if so, this mode
>>>> (transport over network) _cannot_ be secure.
>>>
>>>     Indeed such a solution I'm after won't be "completely" secure (as
>>> a matter of fact nothing can be completely as that would imply
>>> perfection).  And in my particular use case I don't need it.
>>
>> Well, you have been warned... and you can always shoot yourself in the foot ;-)
> 
> And you will. Even exporting the encrypted block device is 
> insecure (i.e. "doing it right"), as disk encryption
> has a different attacker mdoel than communication encryption
> and different limitations. If, at some time, you decide you 
> actually want to be secure, move to any VPN-tunnel like 
> solution.
> 
> Arno 
> 

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

[Ciprian Dorin Craciun]

On Thu, Aug 1, 2013 at 5:46 PM, Erik Logtenberg <erik@logtenberg.eu> wrote:
> Maybe I also don't understand your use case well enough, but it seems to
> me that using dd over ssh would kinda do the trick, right?
>
> On the sending machine you use something like:
> # dd if=/dev/device | ssh root@receiving_system dd of=/dev/device
>
> Or if your sending machine doesn't have access to your receiving system,
> do something like this on your receiving system instead:
>
> # ssh root@sending_system dd if=/dev/device | dd of=/dev/device

    Nop.  `dd` over `ssh` would work only if I intend to dump (or
clone) the disk, at the block-device level, from one side to another.

    Meanwhile I need on-line, remote, read-write access.


> If you just want all your files over the network safely, use rsync over
> ssh. You say that you want to retain the native features of the
> filesystem itself, so as far as rsync doesn't have support for the
> specific features you're talking about (snapshots for example), just use
> dd to copy over the entire filesystem.

    Again this would work if I need to clone the disk, but this time
at file-system level.

    Moreover on this topic, I found that the best way to "clone" the
contents of a file system (minus any meta-data like ACL, extended
attributes, etc.) is via `cpio` over `ssh`.  It beats `rsync` as it
doesn't have to check anything on the other side and it buffers
nicely.

    Ciprian.

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

[infrabit]

On Thu, 1 Aug 2013 19:17:00 +0300, Ciprian Dorin Craciun 
<ciprian.craciun@gmail.com> wrote:
>     I found that the best way to "clone" the
> contents of a file system (minus any meta-data like ACL, extended
> attributes, etc.) is via `cpio` over `ssh`.  It beats `rsync` [...]

...or tar+ssh and if you can afford to trade security (although from your posts 
I wouldn't) use a weak cipher f.e. arcfour (use case: private network where you 
only have ssh login to servers).

As all others posters suggested you will shoot yourself in the foot. It's not 
about if, but when.