From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com
 [IPv6:2a00:1450:400c:c09::243])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sun, 27 Mar 2016 09:51:48 +0200 (CEST)
Received: by mail-wm0-x243.google.com with SMTP id 139so7705904wmn.2
 for <dm-crypt@saout.de>; Sun, 27 Mar 2016 00:51:48 -0700 (PDT)
References: <56F6A1A2.4050805@dodo.com.au> <20160326200610.GA6499@tansi.org>
 <56F72F01.7020504@dodo.com.au>
From: Milan Broz <gmazyland@gmail.com>
Message-ID: <56F79110.6040003@gmail.com>
Date: Sun, 27 Mar 2016 09:51:44 +0200
MIME-Version: 1.0
In-Reply-To: <56F72F01.7020504@dodo.com.au>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] concurrency
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: Hugh Bragg <hughbragg@dodo.com.au>, dm-crypt@saout.de

Hi,

On 03/27/2016 01:53 AM, Hugh Bragg wrote:
...
> I don't want to need a dedicated server to deliver a decrypted
> filesystem because I don't want the decrypted data to be exposed to the
> network. I understand I could use secure communications, but this is all
> way too much overhead compared to what I'm trying to achieve.

As Arno said, dm-crypt cannot be used this way - it is not designed
to provide shared block device among servers.

On top what already mentioned, probably some combination with mechanism
to share active/active block device could work (maybe DRBD) but such
solution is quite fragile.

But there is another problem with your solution - you said that you
do not want decrypted data on the wire.

While accessing encrypted device (dmcrypt/LUKS) this simple way
will put encrypted data over your network, this solution is
NOT secure.

Anyone can use reply attack and just replace old ciphertext content
(some old already-seen data) in packets.
(Imagine it is as a snapshot of the encrypted device in time.)

You have to use encrypted network connection on top of this (SSH, VPN, ...)
to provide secure transport layer here.

Just sharing encrypted disk device over network (even if it is just
through point-to-point using iSCSI, NBD whatever) is simply not secure!

Milan