Slashdot Log In
Simplified Disk Encryption Coming to GNOME
Posted by
ScuttleMonkey
on Wed Feb 22, 2006 05:46 PM
from the keep-it-secret-keep-it-safe dept.
from the keep-it-secret-keep-it-safe dept.
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."
This discussion has been archived.
No new comments can be posted.
Simplified Disk Encryption Coming to GNOME
|
Log In/Create an Account
| Top
| 83 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

TrueCrypt (Score:1, Informative)
(http://loudorangecat.com/)
Re:TrueCrypt (Score:4, Informative)
(http://www.mcgill.ca/)
Re:TrueCrypt (Score:5, Insightful)
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.
Disk encryption? (Score:3, Funny)
(http://www.silverwolf-den.com/)
For tech-savvy users there's already been solution (Score:5, Interesting)
(http://www.christopherculver.com/)
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 (Score:3, Informative)
(http://www.nick-andrew.net/)
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 (Score:5, Informative)
(http://vcolo.com/)
Too confusing for consumers ? (Score:3, Funny)
Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?
I think my information is safe enough without it (Score:1)
Re:I think my information is safe enough without i (Score:5, Interesting)
(Last Journal: Friday February 10 2006, @02:51PM)
In any case, the story is definitely worth a listen.
Portability? (Score:2)
(http://www.feyrer.de/ | Last Journal: Sunday February 16 2003, @07:49PM)
- Hubert
great news (Score:1)
HAL != Gnome (Score:2)
(http://www.keirstead.org/)
This is a not a GNOME-centric development.
Re:Wrong level of the Stack (Score:4, Informative)
(http://janneinosaka.blogspot.com/)
Re:Wrong level of the Stack (Score:3, Insightful)
(http://rtfm.insomnia.org/~qg/ | Last Journal: Wednesday November 16 2005, @07:11AM)
Re:Wrong level of the Stack (Score:3, Informative)
(http://www.barrapunto.org/)
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 (Score:2)
(http://blog.bfccomputing.com/ | Last Journal: Tuesday August 07, @06:50PM)
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.
Don't panic! (Score:2)
(Last Journal: Friday August 24, @08:58PM)
Re:Wrong level of the Stack (Score:3, Informative)
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.
Re:They're not writing a new file system.. (Score:2, Interesting)
(http://blog.fubar.dk/)
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...
Re:Wrong level of the Stack (Score:2)
(http://www.rit.edu/~sac7352/r.cgi?r=sd | Last Journal: Tuesday August 16 2005, @03:51PM)
Re:Wrong level of the Stack (Score:3, Informative)
(Last Journal: Saturday March 27 2004, @05:00PM)
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).
Poor article title (Score:2)