Re: crypto file system
Greetings,...
Am Mittwoch, 23. Februar 2005 19:19 schrieb Jonathan Schmitt:
> 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.
Yes. My favorite is ssh, because it's more flexible.
> 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.
AFAIK cfs can be accessed from userland.
> > > 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.
Stop. You are right. I misunderstood you.
I thought you want to exported the fs-image.
(But don't use journal-fs)
If you export the data only, there shouldn't be any problem.
> > 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,
Well every encrypted file is stored in cleartext while editing. Even if you
use an encrypted partion. (In this case the key is stored in RAM and can be
recovered locally)
If you fear saving it on HDs etc. thing of encrypting /tmp and swap with a
different (random) password for each session.
Another approach is loading the files into Ram while editing (RAM-Disc is an
easy approach)
> You end
> up with those darn ~ files (which are good in general, but bad here), You
> have to remember to clean up.
Not If you encrypt your working-directories randomly. Every time you boot, you
get a clean, new tmp and data recovery is impossible due to encryption.
> 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?
Well, I haven't used it.
CFS is (imho) can be substituted with ssh and NFS-over-TCP.
Be aware, that CFS is quite obsolete. (Their algorithms are out of date)
Keep smiling
yanosz
Reply to: