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."

TrueCrypt

[robyannetta]

TrueCrypt [truecrypt.org] has offered this type of integration in Linux for years.

Re:TrueCrypt

[zhiwenchong]

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

[kwalker]

Yeah, but even there, I can't find a way to encrypt my firewire backpack drive. Why should it let me encrypt DMGs but not block devices/partitions?

Re:TrueCrypt

[tepples]

I can't find a way to encrypt my firewire backpack drive.

Can you put a read-write DMG on it? This way you can easily divide the partition between unclassified and confidential data.

Re:TrueCrypt

[kwalker]

I could, but that seems like a hack to me, and would only work until I needed to grow the encrypted section to 51% of the disk (Since I have to destroy and re-create the DMG file every time I expand it). I want the entire disk "classified" since it's all my private data.

Re:TrueCrypt

[pomo monster]

If you make it a sparse disk image, you can set the volume size as large as you want to start, but the .dmg (actually .sparseimage) file starts at zero bytes and only grows as you add stuff to it. Compact it every so often, if you're concerned about wasting space. Screenshot. [imageshack.us] Note custom volume size.

Re:TrueCrypt

[zhiwenchong]

Well, you can always create a sparse image file that's as big as your drive. No problems there.
That's what Filevault sort of does with your home directory.

It operates in a way in a decoupled sort of way, you see.

Re:TrueCrypt

[MBGMorden]

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:TrueCrypt

[Nimey]

You are correct. There should be a moderation option "Wrong/Stupid".

Re:TrueCrypt

[commanderfoxtrot]

TrueCrypt on Windows is great.

But why should I use it in Linux over the normal device-mapper tools?

Anyone know?

Re:TrueCrypt

[fcgreg]

Yes. The first reason that comes to mind is cross-platform encrypted volumes. For example, TrueCrypt is very nice for using encrypted volumes between Windows and Linux systems (e.g., USB Flash drives, portable HDD's, etc.).

Re:Wrong level of the Stack

[JanneM]

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]

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

[msuarezalvarez]

If they don't use the proper APIs, it simply doesn't work.

The GnomeVFS API may well be difficult to work with (*), but this statement of yours applies to absolutely every API out there.

(*) Actually, most programs rarely need much more than rather small subset of the API, which basically mimics the POSIX file API; hence, your use of the word `impossible' in this context is, at the very least, dubious.

Re:Wrong level of the Stack

[AKAImBatman]

The GnomeVFS API may well be difficult to work with (*), but this statement of yours applies to absolutely every API out there.

Ummm... no. In this case there is a lowest level virtual file system that can be modified to make ALL programs compatible. With GnomeVFS, RealPlayer fails, Acrobat fails, KOffice fails, OpenOffice fails, etc. because the GnomeVFS API is a structure that duplicates officially provided functionality. Ergo, it's not that good of a design.

Re:Wrong level of the Stack

[msuarezalvarez]

What is the "officially provided" and commonly agreed upon way to access a s ftp:// [ftp] URL? One that will interact with the ssh-agent, and look into my keychain for keys, of course. What about fonts:///? What is the standard way of opening a resource located by an http URL? cp(1) seems not to grok

cp http://www.google.com/ sftp://somedomain.org/file.html

It may be related, I guess, to the fact that open(3) for some reason does not like SMB mounts.

Re:Wrong level of the Stack

[AKAImBatman]

What is the "officially provided" and commonly agreed upon way to access a sftp:// [ftp] URL?

Duh. Just call a "mountsftp" mounter to access the FS. There's an SSHFS implementation here [sourceforge.net] that does pretty much the same thing.

Re:Wrong level of the Stack

[juhaz]

Pray tell, how exactly does this work in Solaris, BSD, OS X, Windows? What? It doesn't?

Gnome-vfs may be less than optimal in many respects but at least it's not Linux-only.

File Based IS the Wrong Level

[ratboy666]

File based crpto is the wrong place to apply, or the wrong level of the stack. In the below discussion, "I" means "black-hat crypto cracker".

Metadata leakage, including filenames. This generally tells me the files I need to attack. I don't need mymod.ko, but earnings.sxc would be interesting.

Generally, file-based approaches only encrypt the file data. BAD, because EVEN if the filenames themselves are encrypted, and allocation maps are encrypted, it is still possible to do entropy analysis on the drive. What

Re:Wrong level of the Stack

[QuantumG]

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]

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]

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]

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]

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]

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]

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]

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

[bfree]

fuse = filesystem in userspace = in Linux post 2.6.14 (afair)

Re:Wrong level of the Stack

[Mr. Vandemar]

It's not an SSH file system. It's an encrypted filesystem. There's a difference.

Re:Wrong level of the Stack

[bill_mcgonigle]

It's not an SSH file system. It's an encrypted filesystem. There's a difference.

Umm, yeah - the point is doing a filesystem at the most effective layer of abstraction - the VFS or as a userspace filesystem on linux. Doing a filesystem in GNOME (which isn't what this is) would just be silly, from a linux perspective.

Re:Wrong level of the Stack

[pnatural]

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

Feeding trolls for fun and profit

[cortana]

$ find /etc/ | grep gnome | wc -l
39

Your other comments may apply equally well to KDE.

I'll close with an old classic:

I don't want to start a holy war here, but what is the deal with you KDE fanatics? I've been sitting here at my freelance gig in front of KDE (3.4) for about 20 minutes now while it attempts to copy a 17 Meg file from a folder on the hard drive to a server via the fish kioslav. 20 minutes. At home, on my Amstrad PC2086 running DOS 3.3, which by all standards should be a lot slower than this Ma

Re:Feeding trolls for fun and profit

[amliebsch]

Mac addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use KDE over other faster, cheaper, more stable environments.

Why would Mac addicts flame you for choosing KDE?

Feeding troll feeders for fun and profit

[binford2k]

$ find /etc/ | grep gnome | wc -l
573

And what the hell does that prove?

Re:Feeding trolls for fun and profit

[Burz]

Sounds like system problems or a slow link.

Also, fish uses an SSL encryption layer. Your 286 machine does?

For the record, whatever gripes people might have about the UI, KDE is the faster and more stable environment. That much is well-known. The project doesn't deal with stability issues and other bugs by saying "Ehhh... people don't NEED that feature anyway. *CHOP*".

IMHO people don't need Gnome. :-)

Re:Wrong level of the Stack

[realnowhereman]

I don't really like the Gnome vs. KDE wars - both camps seem to be gaining from the existence of the other. However I was a little surprised the other day to find:

$ du -h /etc/gconf/
4.0K /etc/gconf/1
4.0K /etc/gconf/2
0 /etc/gconf/gconf.xml.mandatory
921K /etc/gconf/schemas
9.7M /etc/gconf/gconf.xml.defaults
11M /etc/gconf/

Which I traced to the fact that I installed gthumb.

Why on Earth does a set of defaults need nearly 10M?

All the languages are included.

[Ayanami Rei]

The gconf configuration contains a lot of strings that applications use for help text and dialog boxes where options are displayed. Usually they are packaged with _every_ translation included. So the files can be huge if they have 100 copies of every string. Plus it's XML so it's wordy.

Don't panic!

[temojen]

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]

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

[stuuf]

Nothing is being done at that level, RTFA or learn how HAL actually works. The encryption is handled in the kernel by device mapper, and a userspace tool (cryptsetup) activates it. This project is just a front-end to that, so you don't have to run cryptsetup from a terminal yourself. Once it's mounted any normal app can interact with it like any otherpart of the file system, just like HAL-mounted removable disks.

Re:Wrong level of the Stack

[kwalker]

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:Wrong level of the Stack

[Schraegstrichpunkt]

Does it support encrypted swap space?

Re:Wrong level of the Stack

[kwalker]

You can use cryptsetup-luks to encrypt your swap space, yes. It requires modification to your startup scripts (Specifically the section where it mounts your swap space), and generating a random key each boot (If you so choose), but it's quite doable.

Poor article title

[Steven Reddie]

The GNOME in the title of the article refers to the GUI component for interacting with the HAL file system encryption component. They're just making a GUI to interact with the system-level encryption.

Disk encryption?

[vandon]

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]

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

Re:Of course they will.

[Nimey]

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

Re:Of course they will.

[pclminion]

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

I was in the front row at Phil Zimmerman's presentation at Defcon several years ago. Somebody in the audience asked whether he had ever been asked to insert a backdoor into PGP, and whether he had done so. Zimmerman immediately became irate, apparently taking the question as a personal attack. He said that thousands of people depend on the security of PGP, including dissident groups and people fightin

Re:Disk encryption?

[Tweekster]

not everything comes back to terrorism... it has become humorous, the people making fun of the terrorism angle have long ago outspoke the people that were making the claim.

Re:Disk encryption?

[Anonymous Coward]

If only terrorists and pedophiles use encryption, would not that same logic conclude that governments are actually organizations comprised mainly of large numbers of pedophiles and terrorists?
Governments are one of the largest users of encryption after all.

Re:Disk encryption?

[stuuf]

Um, nothing has changed here as far as Linux's disk encryption support. This is just a front-end to (a small subset of) the command line encryption tools, which have been around in 2 or 3 incarnations for a long time. All this does is let you save a few keystrokes to access your encrypted disks. It doesn't make it easier for people who didn't previously know how to do this, as you still have to format the disk manually (however a GUI for this would be nice). As far as email or http encryption, that's differ

Screw encryption

[mu22le]

What people really need is Steganography [slashdot.org]

Re:Disk encryption?

[legirons]

The government uses encryption. They must have something illegal to hide.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:For tech-savvy users there's already been solut

[kwalker]

I'm currently using cryptsetup-LUKS / DM Mapper with AES-256 encryption and a 16-digit random key committed to memory. I'm just using it for a data partition currently, but if some of the rumors I'm hearing are true, I should be able to go system-wide on my distro of choice soon enough.

I do see a system penalty using the crypto setup (Server is single AMD-1800+ 1GB RAM) in that copying a large file will peg the CPU and drive the load average way up for about two seconds every four to five seconds, but thus

Re:For tech-savvy users there's already been solut

[commanderfoxtrot]

ext3 syncs by default every 5 seconds- if you're using ext3 this could be your problem.

You can change the settings for how often it flushes and also the criteria e.g. flush when buffers are 20% dirty.

This was in bdflush in Linux 2.4- I'm not sure where it is now in 2.6. Google will have it somewhere though :-)

Re:For tech-savvy users there's already been solut

[kwalker]

That's possible. When I was doing unencrypted testing, I was using ext3 and it was a steady stream. My encrypted block device is formatted with ReiserFS 3.6 but it may have similar settings.

Already in debian

[elronxenu]

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]

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.

Re:They're not writing a new file system..

[dzeuthen]

Also notice his screenshot still shows the USB key not being mounted 'sync'. Sigh. That so needs changed. One thing at a time I guess. :)

Actually the new thing is the 'flush' mount option that don't wear out flash drives and destroys performance like 'sync' does. Someone at SUSE wrote an experimental 'flush' patch for vfat and it seems possible to do for other file systems too. It will go upstream and some point...

Too confusing for consumers ?

[PentAthl337]

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:Too confusing for consumers ?

[JonJ]

Nonono. The Gnome-devs are getting with the times. There's gonna be eight versions, the first one severely crippled, and the last one semi-functional. If you need to get the extra-special-whiz-bang Gnome(Which atually works), you need to sign a contract with RMS promising to never use any alternative ever again.

I think my information is safe enough without it

[r_jensen11]

Nobody else at my home uses Linux, and if they tried to do anything other than click on the shortcuts to Firefox or VLC or the random game like America's Army or Unreal Tournament, they wouldn't have any a very good idea of what to do. The same goes for when I'm at school. I know of nobody that uses Linux or knows how to use Linux (save for one persone I met once while at an engineering orientation during the summer,) so I'm pretty sure that if I want anything hidden, I'll store it in a folder labled .DON

Re:I think my information is safe enough without i

[amliebsch]

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]

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.

Re:I think my information is safe enough without i

[mano_k]

You're hanging out with the wrong crowd, pal! ;-)

Portability?

[hubertf]

I'm looking forward to use this with NetBSD's CGD.

  - Hubert

great news

[Anonymous Coward]

What would be cooler is a nice GUI to create encrypted volumes

HAL != Gnome

[brunes69]

The summary and headline are misleading. HAL is a desktop independant technology and is also used heavily KDE in 3.4, and will likely be even more so in KDE 4.0.

This is a not a GNOME-centric development.

KDE tools?

[Kjella]

So, assuming we get all the necessary HAL bindings in place, how much work would it be to implement similar functionality under KDE? I must admit what I saw in that screencast was most impressive from a usability point of view.

Secondly, I'm not very familiar with LUKS/dm-crypt. Would it be possible using this setup to encrypt /? Obviously /boot must be in plaintext, but would it be possible to have the kernel ask for a password (obviously at command prompt) before loading the rest?

Third, I'm partial to havi

Re:KDE tools?

[Burz]

Well you could check out Xandros Linux (Debian/KDE based). They've had a disk encryption panel in Kcontrol for quite some time now.