contention: truecrypt better than ecryptfs
Paul Johnson
In Ubuntu 9.04, I have been testing various encrypted file systems.
The "built in" framework in Ubuntu is a ecryptfs thing that is
pretty easy to set up. The encrypted material appears as a
directory called ~/Private that is automatically available after you
log in with a password. In the community, the consensus seems to be
that encryption imposes a 5% slowdown, but in my usage, it is much
more extreme than that. When I put 2000 images in there and
randomly choose among them to put pictures on the backgrounds of
terminals (MLterm rules!), there is a noticable delay of 5 or 6
seconds when I ask for a terminal.
I googled lots and decided to test truecrypt, which is also open
source, but it has some complicated license that the distros don't
like.
It can either encrypt a whole partition or it can encrypt a "file"
that can be mounted, rather like creating an iso file with a dvd
writing program and then mounting with a loopback device. The
truecrypt storage object is a fixed size--you set it when you create
the thing.
Truecrypt is better. You can create the new storage with either a
passphrase or an encryption key. Movement of files into and outof
the truecrypt storage "thing" is much much faster than ecryptfs. AND
IT HAS AN AWESOME GUI, by far the best gui I've seen in a free/open
program since k3b. You can do everything in the command line, but
that graphical setup is thorough and clear.
A plus for truecrypt is that it is available for Windows and Mac, so
if people you work with are stuck with shitty operating systems
like that, you can mail them encrypted "file" things and they can
open, if you tell them passphrase or give a key.
I use the passphrase approach because the key approach requires you
to keep the key available, either on the hard disk or on a USB key.
For the same reason I prefer a combination pad lock to a keyed pad
lock, I use the passphrase.
Now, before I go looking for my own answer, can you tell me this:
When you use encryption on a "thing" and un mount it, and you then
copy that onto a backup medium or onto another computer with rsync,
does rsync have any ability to speedup the transfer by only moving
the changed parts of the file? If an encrypted "thing" is 10 or 15
gigs, would rsync be able to notice that only one file is different
in there? I don't see how it could work, but it is fun to ask!
pj
--
Paul E. Johnson email: paul...@ku.edu
Professor, Political Science http://pj.freefaculty.org
1541 Lilac Lane, Rm 504
University of Kansas Office: (785) 864-9086
Lawrence, Kansas 66044-3177 FAX: (785) 864-5700
Aaron Brown
> A plus for truecrypt is that it is available for Windows and Mac, so
> if people you work with are stuck with shitty operating systems
> like that, you can mail them encrypted "file" things and they can
> open, if you tell them passphrase or give a key.
The operating system cross-compatibility feature is intriguing.
On my work computer (a laptop), where I have lots of things that would
be very bad if they were readable if my laptop is ever stolen, I use
encfs. It has pros and cons, so I don't recommend it for every use, but
here's what I know and how I use it...
encfs will encrypt a directory of files (recursively) and replace each
file name and its contents with encrypted ascii-armored gibberish. The
downside for security is that you can still see how many files are in a
given directory, and their sizes and linux file system attributes (chmod
stuff), but otherwise everything is pretty opaque.
For me, the advantage to this security compromise is that backup
software doesn't see a big glob of encrypted data, it sees individual
files. So something like rsnapshot (which uses rsync), can detect which
files have been modified, even though they're encrypted, and just back
up those, instead of having to do the whole directory or, even worse,
the whole disk volume. It just blindly copies the new encrypted files
to my backup drive where I can easily decrypt them if I ever need to
restore anything.
What do I put in there?
1) My code. Code often includes sensitive things like passwords to
databases and such.
2) My other work-related files, since many projects begin with a data
import or something, and I might have raw data of a sensitive nature
lying around.
3) tomcat. Yes, I run tomcat out of an encrypted file system. Yes,
it's slower than it would be otherwise, but not irritatingly so. Java
is irritatingly slow anyway, in my opinion, it's not encfs's fault. :)
Anyway, all the sensitive stuff that was in my code is also here, so
this gets encrypted too.
4) My ssh private key. I have a no-password key-based auth set up to
several systems, but I stash my private key in an encrypted folder.
This saves me from the trouble of setting up some kind of agent program
to handle the passphrase for me.
5) My subversion auth info. On linux, subversion credentials are saved
on the hard drive in the clear (if you save them at all)[*], so I told
my svn client to put them in a directory within my encrypted area. Not
much point in encrypting my code if anyone can just check out fresh
copies of it from version control for free.
encfs doesn't have any nice gui help, but it's a very simple system to
work with, so there isn't much to it.
That's my two cents on the matter.
- Aaron
[*] One big advantage to running svn on MacOS or Windows - they're
tightly integrated enough to have a native password encryption system
that the whole operating system is built to use, so svn just uses to
that to secure the authN data. Linux has lots of hashing utilities that
get used in passwd and other places, but they're one-way and therefore
not helpful for this situation.
--
Aaron Brown :: aa...@thebrownproject.com :: www.thebrownproject.com