Re: crypto file system
Hello back,...
> > I'm looking for a cryptographic file system to securely store data on a
> > server, either via something like an encrypted nfs or via a local mount of
> > an exported nfs share.
> Do you want to encrypt files for transport only or do you want to store the
> file encrypted on your harddisk?
> (If they are stored encrypted, they are transported encryptet as well, so
> you don't need to encrypt twice ;)
Yes, I'm aware of this. There are several possible scenarios and we will
settle for the best we can get. The least is to get away from nfs itself
(unencrypted data transfers are a lesser problem than authorization by IP).
This can be done - I understand - for example by sshfs or by using an
stunnel.
We hope to get a little bit more out of encryption. In general cfs does
exactly what we want, store the data encrypted, if You mount the device, only
You can read it (no root, no other unit - in contrast to loopback for
example), but there's the issue with the lacking support for some boxes.
> Every kernelland approach I know causes difficulties with non-linux boxes.
> Every userland approach approach causes difficulties with transparent file
> access.
> However, there are some VFS-drivers allowing to use userland programs to be
> a file system driver (captive mode NTFS is the best known example I know),
> but I didn't use it.
There are no non-Linux boxes that have to be connected, merely some people who
won't give up their beloved non-Debian distro, which doesn't come with a cfs
packages and where cfs source can't be compiled with reasonable effort.
> > Nfs exported crypto loopback seems to be fine in general, but there is a
> > difficulty with our backup (file backup, all modified files are saved
> > every day for 90 days, so a 3GB crypto loop would result in some admins
> > coming for my head).
> Well, If you export an encrypted file system r/w on nfs, there is a good
> changes that is is either screwed-up or non-writeable for most of your
> users.
Thanks, that's what I feared.
> There are many utils for encrypting files,
> I use gpg for userland only accesses, and loop-aes for kernelland accesses.
> (loop-aes allows userland access as well).
Well, as I said, crypto-loop will cause severe difficulties with our current
backup strategy. I wouldn't want to go through this. GPG is what we currently
do mainly, that leaves several problems open. You have the plain text file
stored on Your computer and if You use emacs for editing, You end up with
those darn ~ files (which are good in general, but bad here), You have to
remember to clean up.
So neither crypto loop nor gpg would be sufficient to solve all problems.
> If you want to use a encrypted file system, you have to know exactly when
> which data have to be encrypted and it what ways it has to be accessed.
> Perhaps a ssh tunneld nfs may be enough.
The ideal solution would be: data encrypted on server, transferred in an
encrypted way and then decryptet user-readable only on the client. The next
best solution is something like sshfs or tunneled nfs (which would still
imply the use of gpg for the more sensitive files).
By the way, NCryptFS actually is still vaporware, right?
Best regards,
Jonathan
Reply to: