Mine the Harvest

I have been using Dropbox for quite a while, and I’ve found it extremely helpful. Spideroak, a similar service, is also very interesting and something I am test driving now as well. Being able to share files so easily amongst numerous devices and via the web is handy in the extreme. You can even tie in things like Nevernote into this and sync your notebooks yourself between your devices.

With any of these solutions, security is of course a concern. Regardless of if the data is encrypted in transit, or if the provider encrypts it on their server, I wanted to also encrypt it locally. This is where a combination of Dropbox + encFS comes into play very nicely.

There are many options when it comes to file encryption, but encFS really shines in some areas. Encryption is per-file, and no dedicated space need be reserved before hand. Setup is very simple, and encFS is well supported on all major Linux distros.

Using this solution, encFS stores encrypted files in a Dropbox directory. This is then mounted via encfs to a local folder where the unencrypted files are made available. When I am done, I can simply unmount this directory, leaving only the encrypted files in my Dropbox folder on the local system, encrypted via encFS with AES or blowfish. The information is also thus encrypted in transit, and additionally encrypted by Dropbox/Spideroak on their side.

Setting this up is very simple and takes just a few minutes. More detailed howtos can be found in the reference section, but here is an encFS in 5 minutes quickstart guide:

Ensure you have fuse and encfs installed via your package manager and that the fuse module is loaded
lsmod | grep fuse

Create a directory in Dropbox which will hold the encrypted files, and a mount point outside of Dropbox where the unencrypted versions will be mounted. (For Spideroak simply create two directories in your home folder and add the encrypted directory in your list of folders to back up in Spideroak.)
mkdir ~/Dropbox/encrypted/ ~/unencrypted

Mount the filesystem:
encfs ~/Dropbox/encrypted/ ~/unencrypted/

Note: provide full paths or at least a ~ prefix to encfs.
The first time you do this encfs will set up the encryption. You may choose your options, set the passwords, etc. A “paranoid” auto-config option is available, and full details for options are in the man page.

Using encFS

Now, simply create and use your files in ~/unencrypted. Normal filesystem permissions apply and the use of these should be completely transparent. Anything stored in this mount point is automatically encrypted, and you will see matching (encrypted) entities in ~/Dropbox/encrypted

When you are done, unmount with:
fusermount -u ~/unencrypted

Cryptkeeper Applet

Cryptkeeper is a systray applet for KDE and Gnome which provides a simple GUI for the creation, importing, and mounting of encFS folders. It is quite easy to use. For Suse 11.4, I simply used the rpm available for Fedora 13. Cryptkeeper is maintained by Tom Morton and the source code is available on his site here

By default it uses Nautilus, though KDE users who prefer Dolphin or another file manager can simply change this in Cryptkeepers preferences.

Cryptkeeper also allows you to view information about an encrypted folder, or change the password. These option are available by right clicking on the folder name in the list of encrypted folders.

References:

http://en.wikipedia.org/wiki/EncFS

Setup Guides:

http://movingtofreedom.org/2007/02/21/howto-encfs-encrypted-file-system-in-ubuntu-and-fedora-gnu-linux/

http://www.net-tools.org/web/index.php?option=com_content&view=article&id=124:dropbox-automated-backup-with-encryption&catid=20:scripts&Itemid=40

The last link provides this suggestion on auto-mounting using the enfs extpass option and a compiled file containing your password. However, be aware this simply compiles your password into a binary which spits it out to std out when run. You are creating a program that will spit out your password, or if strings is run on it your password is visible. Man encfs suggests directing –extpass to ssh-askpass as another method, and there is also the option to use libpam-encfs.

PAM Configuration:

For a guide on setting up libpam-encfs see:

http://choffee.co.uk/ramble/2006/06/02/paranoia-at-home/

I’ve been waiting 27 years to see this:

joshua@jaguarpf-login2:~> date
Thu Mar 10 16:04:31 EST 2011
joshua@jaguarpf-login2:~>

Translated from Old High Geek (derived from early proto Unix) that output is similar in magnitude to the fabled Enochian Emerald Tablets of Hermes Trismegistus. But to explain how cool this was for me, a bit of a narrative is needed, but there won’t be much computer speek or techno mumbo jumbo in this post.

In 1983, when I was 12 years old, the movie War Games came out. Of course, I was already deeply in love with computers and had spent endless hours already using my 8 Mhz, 8-bit Atari 400 with 24K as well as my Vic 20 with 3K. Naturally, being a geek, I knew about Cray Supercomputers. (The word was pronounced with a slight pause and inflection when uttered, if indeed the ineffable need be put in human words.) The anecdotal relationship in War Game’s between professor Falken (John wood) and the real life Seymour Cray was  also common geek lore – cannon in fact. Cray was THE supercomputing company – the gold standard of computing.

My love for Cray systems continued unabated from that time, and I would always keep an eye on what the company, and there computers, were doing. Of course, the story of the visisituedes of the company and its founder are near legendary. But like a favorite sports team or rock band I was always a loyal fan – even though I had never once used a Cray system. Neither did I own any platinum, or anti-matter, but one need not have something to know its worth.

More years past until in October of 1996, while driving to work, I heard the news of the unexpected death of Seymour Cray. Wow, that sucked. The father of supercomputing was killed in a car crash, apparently by a drunk driver. I thought about it for days, with the surreal feeling you get when a hero figure is made so painfully mortal, and who’s life need not have been ended. It was just one of those days you will always remember.

Over the years computers kept changing. The age of the custom “big iron” vector supercomputers waned, replaced by commodity hardware running thousands of CPUs and powered by a little OS called Linux. Now, if there was one thing I liked equally as much as Cray’s, it would have to be Linux.

One thing lead to another, and I was recently offered a position at Oak Ridge, the home of Jaguar – a Cray XT5  system with over 220,000 cores running at 2.3 PF (2.3 quadrillion calculations a second).  Jaguar, my favorite computer in the World, running my favorite OS, on a Cray platform, was what lead me to the Lab and I’ve been quite happy with my position there.

So, while that output might seem like any other login, or some boring computer output, for me it had a bit more emerald tablet like glow to it.

Today is another one of those days I’ll remember.

Thanks Seymour.

Recently I was getting errors when trying to rip mp3 files on my Suse 11.3 box, though it seems this issue affects various distributions using KDE. The solution in my case turned out to be quite simple.

Original error when using K3B or audiocd://

Could not read some_song.mp3: encoding failed
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.

I downloaded and compiled the latest version of lame from Sourceforge – which is the same version as the one I had from Packman – 3.98.4. The version I compiled, specifying no additional options, allows ripping of mp3 files no problem.

Running ldd on the packman (Suse repo) binary, and the one I compiled, show that the pm one is indeed compiled with libsndfile:
Callandor:~ # ldd /usr/bin/lame*
/usr/bin/lame:
linux-vdso.so.1 => (0x00007fff563ff000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007fc9202d2000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc92007b000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc91fd1b000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc91fb17000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc920527000)
.
/usr/bin/lame-pm:
linux-vdso.so.1 => (0x00007fff9cfff000)
libmp3lame.so.0 => /usr/lib64/libmp3lame.so.0 (0x00007f84c6fc3000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f84c6d6e000)
libsndfile.so.1 => /usr/lib64/libsndfile.so.1 (0x00007f84c6b07000)
libm.so.6 => /lib64/libm.so.6 (0x00007f84c68b0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f84c6550000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f84c634c000)
libFLAC.so.8 => /usr/lib64/libFLAC.so.8 (0x00007f84c60fc000)
libvorbisenc.so.2 => /usr/lib64/libvorbisenc.so.2 (0x00007f84c5d21000)
/lib64/ld-linux-x86-64.so.2 (0x00007f84c723f000)
libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007f84c5b1a000)
libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007f84c58ed000)

Input from other users on the Suse foum shows that this issue is a bit hit and miss. For some, lame linked against libsndfile seems to work okay. For myself and others on various bug reports, not so much. Building lame is very easy though, and should you be experiencing this issue it might be something to try.