Re: dm-crypt Digest, Vol 31, Issue 21

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
 
 
Thanks
 
Fan
 
 
 
From: "dm-crypt-request@xxxxxxxx" <dm-crypt-request@xxxxxxxx>
To: dm-crypt@xxxxxxxx
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@xxxxxxxx 

To subscribe or unsubscribe via the World Wide Web, visit
    http://www.saout.de/mailman/listinfo/dm-crypt
or, via email, send a message with subject or body 'help' to
    dm-crypt-request@xxxxxxxx

You can reach the person managing the list at
    dm-crypt-owner@xxxxxxxx

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@xxxxxxxxx>
To: Florian Weingarten <weingarten@xxxxxxxxxxxxxxxxxxxx>
Cc: dm-crypt@xxxxxxxx
Subject: Re: Cryptocontainer on remote storage
Message-ID:
    <CAHtv-xOV4155zWLF3vghSHbfzkW9iL1MtDNsfe89Ky10RB6ecA@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx
> 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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


End of dm-crypt Digest, Vol 31, Issue 21
****************************************


_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux