[dm-crypt] dm-crypt Digest, Vol 31, Issue 21

FAN ZHANG fzhangcsc at yahoo.com
Sun Jan 22 16:27:41 CET 2012

dm-crypt is designated to encrypt content for block device. You should use crypt file system (i.e. eCryptfs) to resolve your problem.

1. File content as well as names can be encrypted by using eCryptfs.
2. Underneath file system could handle network connection /server power down issue with proper journaling mechanism.
From: "dm-crypt-request at saout.de" <dm-crypt-request at saout.de>
To: dm-crypt at saout.de 
Sent: Sunday, January 22, 2012 5:00 AM
Subject: dm-crypt Digest, Vol 31, Issue 21

Send dm-crypt mailing list submissions to
    dm-crypt at saout.de 

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
    dm-crypt-request at saout.de

You can reach the person managing the list at
    dm-crypt-owner at saout.de

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dm-crypt digest..."

Today's Topics:

  1. Re: Cryptocontainer on remote storage (Roscoe)


Message: 1
Date: Sun, 22 Jan 2012 18:58:18 +1100
From: Roscoe <eocsor at gmail.com>
To: Florian Weingarten <weingarten at itsec.rwth-aachen.de>
Cc: dm-crypt at saout.de
Subject: Re: [dm-crypt] Cryptocontainer on remote storage
    <CAHtv-xOV4155zWLF3vghSHbfzkW9iL1MtDNsfe89Ky10RB6ecA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Wouldn't this be a candidate for iscsi or similar ? A big container file
sitting on a network fs seems a bad solution to me.

I make no comment regarding choice of mode in this scenario.

-- Roscoe
On Jan 18, 2012 9:03 PM, "Florian Weingarten" <
weingarten at itsec.rwth-aachen.de> wrote:

> Hi everyone,
> I have been thinking about possible solutions to the problem of
> encrypted remote storage and I was wondering if dmcrypt would be good
> way to do it.
> My requirements are basically as follows: I want to store files (in the
> magnitude of gigabytes) on a remote server. However, I do not trust the
> server's admins, therefore, the files should be encrypted. Access should
> not be too slow. Obviously, no key material what so ever should ever
> reach the server. Furthermore, filesystem metadata (names, access times,
> etc.) should also be hidden, so encrypted single files is not enough.
> I was thinking about locally creating a large enough container file,
> encrypt it with cryptsetup/LUKS, upload it to the remote storage. Then,
> access it via some network filesystem (sshfs, smbfs, nfs, ...) and
> locally mount the container with losetup. What do you think about this
> solution?
> My main concern is: What happens when the network link dies while the
> container is mounted? How much damage is there in the worst case? I
> expect it to be pretty much the same as powering down while a local
> filesystem is mounted (a few damaged sectors at most, which will likely
> be recoverable because of filesystem journaling).
> The main drawback is, in my opinion, that I initially have to upload a
> very large file to the storage (and do it again whenever I want to resize).
> What network fs should I use? As far as I see it, I need good
> authentication, but encryption is not necessary (so sshfs would be an
> unnecessary overhead), right?
> I was also thinking about some copy-on-write ideas which create a local
> fs with all the "changes", which I can then sync back to the remote
> server later all at once, which would reduce the network activity and
> thus the risk of network errors.
> Anybody got practical experiences with ideas of this kind? Any
> performance benchmarks?
> Thanks!
> Flo
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20120122/8c5d2e4f/attachment-0001.html>


dm-crypt mailing list
dm-crypt at saout.de

End of dm-crypt Digest, Vol 31, Issue 21
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20120122/e5109773/attachment.html>

More information about the dm-crypt mailing list