Slashdot Log In
Simplified Disk Encryption Coming to GNOME
Posted by
ScuttleMonkey
on Wed Feb 22, 2006 06: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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Disk encryption? (Score:3, Funny)
Re:Disk encryption? (Score:2)
Re:Of course they will. (Score:3)
For tech-savvy users there's already been solution (Score:5, Interesting)
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)
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)
Parent
Too confusing for consumers ? (Score:3, Funny)
Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?
Re:TrueCrypt (Score:4, Informative)
Parent
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.
Parent
Re:Wrong level of the Stack (Score:4, Informative)
Parent
Re:Wrong level of the Stack (Score:2)
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 (Score:3, Insightful)
Re:Wrong level of the Stack (Score:3, Informative)
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)
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 (Score:2)
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 (Score:2)
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:2)
Re:Wrong level of the Stack (Score:3, Insightful)
Re:Wrong level of the Stack (Score:2)
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! (Score:2)
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
Re:Wrong level of the Stack (Score:3, Informative)
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 (Score:5, Interesting)
In any case, the story is definitely worth a listen.
Parent
Re:I think my information is safe enough without i (Score:3, Insightful)