Slashdot Mirror
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."
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]?
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.
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)?
Trust the Computer. The Computer is your friend.
I dont know what you're talking about and I'm thinking it's because you don't either.
How we know is more important than what we know.
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.
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 ). 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. I never noticed any performance penalties: this is a very efficient solution.
Install lvm2 (great for managing disk space), dmsetup, cryptsetup. Read this page 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.
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.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
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. It's supposed to be a unix kernel, not a plan9 kernel.
Malike Bamiyi wanted my assistance.
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...
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".
GStreamer - The only way to stream!
Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?
If you've actually got proof that there's a backdoor in PGP, then prove it. I think you're full of shit.
Hail Eris, full of mischief...
E pluribus sanguinem
In any case, the story is definitely worth a listen.
If you don't know where you are going, you will wind up somewhere else.
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).
/usr, etc) but that's something the distro maintainers will have to tackle since you will either need to be present when the system boots (to type in the key) or have it grab the key from an unencrypted location accessible to the system (Some people use remote servers, some us USB drives, whatever).
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 forgets the password while mounting the device/file/partition/LV. Once it's mounted, the key is retained in the kernel and life goes on. It can present problems in using it for system-level filesystems (/home,
This is perfect for removable drives (USB, FireWire, etc).
... And so it comes to this.
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.
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.).
Greg T.