Simplified Disk Encryption Coming to GNOME

An anonymous reader writes "David Zeuthen of Red Hat has been working on adding encrypted volume support to HAL. The result is an infrastructure that is being developed to make working with encrypted volumes easier. David has published a screenshot documenting his work on his blog. The bottom line: attach a properly encrypted volume and the system will prompt you for a password and automatically mount it."

Disk encryption?

[vandon (233276)]

Won't everyone (ie Government entities) complain that Linux is now a haven for terrorists and pedophilles since only a criminal would want to encrypt their [disk|phone call|email|http connection]?

Re:Disk encryption?

[sqlrob (173498)]

It'd be hard, since every OS out there has encryption.

Re:Of course they will.

[Nimey (114278)]

If you've actually got proof that there's a backdoor in PGP, then prove it. I think you're full of shit.

For tech-savvy users there's already been solution

[CRCulver (715279)]

These developments will bring file security to many non-technical users, but for the nerds out there there have already been practical solutions for some time.

I've been keeping the hard disk of my Linux encrypted with twofish for over three years now (see the description of this encryption method in Bruce Schneier's magisterial Applied Cryptography [amazon.com] ). Swap is encrypted with a random key generated on each boot-up. At first I used the old cryptoloop method, but as soon as the kernel support was there I switched to the crypto device-mapper target [saout.de]. I never noticed any performance penalties: this is a very efficient solution.

Already in debian

[elronxenu (117773)]

Debian already has encryption, and it's very convenient.

Install lvm2 (great for managing disk space), dmsetup, cryptsetup. Read this page [riseup.net] and follow its instructions.

You can create a block device of any size you want using lvm (so long as there is sufficient disk space of course) and then map that to another block device using the device mapper and the crypt filter. The original block device looks like random bytes and if you get the passphrase wrong the mapped block device still looks like random bytes (i.e. there's no way to confirm a correct passphrase except that the result looks sensible).

Once you have set a passphrase, make a filesystem on the mapped block device. Go ahead and use it any way you like.

Re:Already in debian

[Omega Hacker (6676)]

Obviously you didn't read the whopping 3 paragraphs and look at the screenshot that makes it quite clear that what they're doing is making it actually easy to use an encrypted filesystem from a desktop GUI. The instructions you post don't integrate into the desktop, nor are they by any means easy, sorry.

Too confusing for consumers ?

[PentAthl337 (953006)]

an infrastructure that is being developed to make working with encrypted volumes easier

Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?

Re:TrueCrypt

[zhiwenchong (155773)]

Mac OS X's DMG disk image format has had similar functionality (AES-128) for a long time too, but admittedly it is not cross-platform and open-source like TrueCrypt is.

Re:TrueCrypt

[MBGMorden (803437)]

It's one of my favorite programs, but TrueCrypt was Windows only until it was ported to Linux 4 months ago. Not exactly what I'd call "years".

The Linux version is also a command-line program (or at least everything I've read on it have indicated as such). Integrating the same features into a nice interface would be a welcomed addition to the Gnome desktop.

Re:Wrong level of the Stack

[JanneM (7445)]

HAL is not part of a desktop (not really sure why Gnome is mentioned here, other that that the initial user tools for this is Gnome based). It's a Hardware Abstraction Layer around the kernel to support stuff like hotplugging, file monitoring and so on in a nice, hardware-independent manner. It sounds like just about the right level to me. Isn't HAL used in most recent distros by now, no matter what desktop (if any)?

Re:Wrong level of the Stack

[AKAImBatman (238306)]

Excellent! The way the summary/article was worded, it somewhat sounded like it was being added to the GnomeVFS. I'm glad I was wrong. The GnomeVFS was not a bad idea, but getting programs to properly work with it (even many GNOME programs) is impossible. If they don't use the proper APIs, it simply doesn't work.

I'd forgotten about HAL. It looks like its progress is coming along nicely. This is a step that Linux should have taken a LONG time ago. Oh well, better late than never. :-)

Re:Wrong level of the Stack

[QuantumG (50515)]

I dont know what you're talking about and I'm thinking it's because you don't either.

Re:Wrong level of the Stack

[BillKaos (657870)]

Would have you read the article instead trying to do a FP, you would see that this is the same as automonting an USB disk.

From TFA: While LUKS is a standard on-disk format, there is also a reference implementation. LUKS for dm-crypt is implemented in an enhanced version of cryptsetup.

I guess dm-crypt is the right layer for that, done in the kernel by the device mapper. This only will ask you for you key before mounting it.

Re:Wrong level of the Stack

[bill_mcgonigle (4333)]

KDE does something similar, shoehorning in an ssh filesystem that only works in K-apps. There's a userspace sshfs which I'm going to try since I don't use K much, but this is all unnecessary duplication of effort.

But I can't see that GNOME is the essential ingredient here, if it's done in HAL, Gnome just needs a nice GUI to handle a password request.

Re:Wrong level of the Stack

[Omega Hacker (6676)]

KDE does something similar, shoehorning in an ssh filesystem that only works in K-apps. There's a userspace sshfs which I'm going to try since I don't use K much, but this is all unnecessary duplication of effort.

Yes, this disparity between the kernel VFS and the Gnome or KDE or XYZ VFS is very annoying. I was called over to figure out how to save scanned files from a Linux box across to a Windows share. They could browse over to the Windows share just fine in Konq, but when it came time to use a Gnom

Re:Wrong level of the Stack

[cortana (588495)]

Because there is no existing VFS as far as desktop apps are concerned--you have to be root to mount things.

Re:Wrong level of the Stack

[Omega Hacker (6676)]

Then fix it. Creating multiple wholly-incompatible VFS layers that make it utterly impossible for applications to actually work together is really lame. Whining about lack of features in the more appropriate lower layer is a cop-out IMO. Modern SELinux-derived security methods (not to mention the time-tested standby sudo) should easily be up to the task.

Re:Wrong level of the Stack

[cortana (588495)]

The Gnome people and the KDE people have fixed it. They decided that it would be simpler to implement these (often very complex) filesystems in user space, rather than dealing with the complexities and limitations of working in the kernel, not to mention the difficult of persuading the kernel hackers to accept the enormouse amounts of code directly into the kernel. :)

Re:Wrong level of the Stack

[Omega Hacker (6676)]

Doesn't look fixed to me when a Gnome app can't save a file somewhere that the users (who don't give a d*mn what Gnome or KDE are) can see just fine in their KDE file browser. In my book that's called a "bug".

Re:Wrong level of the Stack

[pnatural (59329)]

If you're refering to the fish kio slave, there's absolutely nothing "shoehorned" about it; fact is, kio slaves support more protocols than you can shake a stick at [kde.org].

as for the duplication of effort, consider that porting each and every one of those io slave types to each and every supported kde/gnome platform is a huge undertaking. better to let them bake at the DE level and do an invert later on (e.g., kiofs).

further, when you talk about the GNOME folks duplicating effort, well, from the outside, that who

Don't panic!

[temojen (678985)]

It's just an automounter and passphrase dialog that uses the DM-Crypt (plus LUKS, which is DM-Crypt, but keeps the DM-Crypt configuration in the device's first block rather than /etc)

Re:Wrong level of the Stack

[labratuk (204918)]

Don't worry, the article title is just a bit misleading. All this really is is hooks being built into HAL (dynamic hardware framework) so that users can mount crypted filesystems with a pretty frontend.

What you're saying is like saying "My OS shouldn't ask me with a GUI bubble what to do with a memory stick. That's part of the filesystem layer. Much lower layer than the GUI."

This isn't using gnomevfs.

And when it comes to building 'secondary' VFSs, there's a good argument for keeping things out of the kernel

Re:Wrong level of the Stack

[kwalker (1383)]

I'm going to try to correct you as gently as I can (So unlike Slashdot, I know). But it's done this way to make it compatible. The crypto is at the level it is so it is FS agnostic (I'm using it now on top of LVM and underneath ReiserFS).

In other words, it's at the block level, not the FS level. It creates no problems for anything using the "standard" Linux APIs because unless they're working on the block level, they won't even know it's there.

The user is not locked out of the data unless the user forget

Re:I think my information is safe enough without i

[amliebsch (724858)]

I heard a fascinating report [npr.org] on NPR this morning about how even though so many options for email and file encryption are coming available, very few people actually use them. Even the big privacy advocates who encourage people to use encryption, it turns out, don't use encryption very much. I think a large part of it is because people don't actually think their data is worth encrypting. The other part of it is that the infrastructure is not ubiquotous enough or simple enough to make it worthwhile for everyday use.

In any case, the story is definitely worth a listen.

Re:I think my information is safe enough without i

[Hortensia Patel (101296)]

Interesting. In addition to the factors you mention, maybe people are more afraid of losing access to their data than of someone else gaining access to it. Forgetting passwords is the obvious risk, but I'd imagine that it's also significantly trickier to recover data from an encrypted filesystem if and when something breaks.