On Thu, Aug 1, 2013 at 10:43 AM, Milan Broz <gmazyland@xxxxxxxxx> 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.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
