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."
TrueCrypt has offered this type of integration in Linux for years.
- Just my $0.02, take with a grain of salt, your mileage may vary.
Am I the only one who thinks that this stuff is in the wrong level of the software stack? I mean, if you want a cool virtual file system, extend the virtual file system. Don't add a VFS on top of a VFS. Doing so only creates compatibility problems for programs that use the "standard" Linux APIs. Considering that users *do* use KDE, OpenOffice, a few commercial apps, and the command line (for sufficiently advanced users) how does it help to leave the user locked out of his data in all of these situations?
I'm not trying to disparage the work done here, I'm sure it's very good. My problem is a matter of improper architectures that don't take many common usage scenarios into account.
Javascript + Nintendo DSi = DSiCade
you're doing a heck of a job, brownie
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]?
david zeuthen's the 'anonymous reader' who posted this tripe. all aboard the self-agrandizement train! whoo hoo!
david zeuthen
pleasant whisper of falling snow
flowing through my dreams
It's a good improvement for Linux desktops, and once more such comes from the Gnome project. The only thing I don't like about some of these new improvements is that they are very Linux centric. Gnome isn't very friendly towards other platforms. They aren't hostile but often they focus quite strongly on all the Linux specific gadgets that are not available on all the operating systems (*BSD and others).
Since they cannot bribe everyone who looks at GNOMEs source to ignore a Magic Lantern-esque backdoor, as was done with the oh-so-respected PGP product line once apon a time... (Before the derail, yes, PGP makes goodies. Blah blah blah.)
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.
What? GNOME is actually ADDING something to their desktop?
I would have expected encryption to be discouraged as being "too complicated" for the target GNOME audience of "people in a persistant vegitative state".
Some day, GNOME is going to finish its devolution into Microsoft Bob. "But see, you can't DO anything useful with it, it's OBVIOUSLY easy to use!"
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)
For those of you missing the point (or not RTFA) and thinking GNOME is writing a GNOME-specific disk encryption.. What they're doing is making the desktop automatically handle mounting/unmounting encrypted volumes. Basically, to let you smoothly use your encrypted volumes made with LUKS/dm-crypt/cryptsetup without having to drop into a shell and handle mounting by hand. This has been way overdue. It's good to see it being worked on.
:)
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.
39
Your other comments may apply equally well to KDE.
I'll close with an old classic:
Maybe the new version will be called GNOME_PRO and the old will be GNOME_HOME edition?
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\'T\ LOOK\ HERE\ BECAUSE\ IT\ IS\ A\ SECRET! and place it in ~/Desktop/
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 looking forward to use this with NetBSD's CGD.
- Hubert
That's the best reply to such a post that I've ever read!
$ find /etc/ | grep gnome | wc -l
573
And what the hell does that prove?
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 far it hasn't been more than a 10-15% speed hit over-all (Compared to an unencrypted block device) and the server is able to withstand it for days on end without a hiccup.
... And so it comes to this.
You're hanging out with the wrong crowd, pal! ;-)
What would be cooler is a nice GUI to create encrypted volumes
What people really need is Steganography
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
http://blog.grcm.net/
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.
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.
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.
... And so it comes to this.
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 appears random is data!
If you use a crypto system that uses the same key to encrypt blocks, with the same results, this is bad. I can again GUESS the plaintext, by guessing the file system, and the common layout information (allocation tables). This can provide a lot of information.
What we want is to encrypt at the block level, and to spew random numbers ALL OVER the drive before using it, and to use a crypto implementation that gives reasonable results (block number as part of the key).
Please keep your data safe!
Just another "Cubible(sic) Joe" 2 17 3061
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
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.
/? 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?
Secondly, I'm not very familiar with LUKS/dm-crypt. Would it be possible using this setup to encrypt
Third, I'm partial to having containers because they can more easily be backed up and moved around as opposed to block devices, for example a DVD sized container. Could this be adapted to work the same when opening an encrypted file as opposed to accessing an encrypted device? Ask for pw then mount itself. I've seen solutions for this but nothing *easy*.
Fourth, regarding the keyring. I saw he disconnected the USB drive then reattached it and it remembered password. Is it possible to a) force removal from keyring (dismount good, hotkey better) b) have keyring be automatically removed on inactivity c) have keyring removed on locking screen. Naturally, most of these would not be nice to the apps with files currently open on the device, but that's secondary.
Live today, because you never know what tomorrow brings