[dm-crypt] Cryptocontainer on remote storage
eocsor at gmail.com
Sun Jan 22 08:58:18 CET 2012
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.
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
> 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?
> dm-crypt mailing list
> dm-crypt at saout.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt