Bug 113629 - Complete LUKS support (especially mounting)
Summary: Complete LUKS support (especially mounting)
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: media (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Kevin Ottens
URL:
Keywords:
: 94357 121020 123293 148374 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-09-30 17:10 UTC by Gilles Schintgen
Modified: 2009-03-10 15:49 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
LUKS suppport via kio media slave (194.88 KB, application/x-tgz)
2007-11-25 12:43 UTC, Jan Klötzke
Details
LUKS support via kio media slave (updated 23/01/08) (936.01 KB, application/x-tgz)
2008-01-23 23:05 UTC, Jan Klötzke
Details
LUKS support via kio media slave (updated 28/01/08) (936.63 KB, application/x-tgz)
2008-01-28 23:29 UTC, Jan Klötzke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gilles Schintgen 2005-09-30 17:10:48 UTC
Version:            (using KDE KDE 3.4.90)
Installed from:    Gentoo Packages
OS:                Linux

(LUKS and some other things are briefly explained at the end. To make it short: KDE needs support for encrypted media. I don't know if I filed this wish for the correct product.)

It would be great if KDE had complete HAL/LUKS integration. By this I mean that HAL notifies KDE over d-bus that a LUKS medium has been attached, upon which KDE asks the user for the passphrase and proceeds to mounting the volume. In other words, plugging in and accessing a LUKS-encrypted medium should be as straightforward as a for a normal non-encrypted medium.

Some people, notably Michael Petullo, are working on LUKS support for HAL and Gnome. An outline of these efforts can be found at [1]. I'd like to stress that at first it would be more than sufficient to simply have support for passphrase input. (See also [2] for further LUKS-related ideas.)

Now, for those who have never heard of LUKS...
LUKS (Linux Unified Key Setup) [3] is a specification of how to store encryption keys in the first sector of a partition. These keys can be accessed using a passphrase. Subsequently a dm-crypt [4] mapping is created. This virtual block device can then be mounted like any other block device.

I'd also like to add that I'm using a dm-encrypted home partition for nearly a year now, without any problems. luks is just a standardized way to set things up. I've now used luks for a few weeks on my external USB Hard Disk. It works perfectly, too. The only drawback to both is missing support in current desktop environments.

[1] http://www.flyn.org/easycrypto/easycrypto.html
[2] http://www.flyn.org/projects/luks-tools/
[3] http://luks.endorphin.org/about
[4] http://www.saout.de/misc/dm-crypt/
Comment 1 Kevin Ottens 2005-09-30 17:26:13 UTC
*** Bug 94357 has been marked as a duplicate of this bug. ***
Comment 2 matt 2005-09-30 21:08:40 UTC
One additional consideration should be local encrypted filesystems which are *not* removable.  Perhaps a partition, more likely a loopback filesystem image (in the form of a file on the HD).

That was part of the point of 94357.

Thanks!
Comment 3 Daniel Franke 2005-10-01 19:22:32 UTC
I second comment 2 - that's what my report #109531 (marked as dupe) was about.
Comment 4 Gilles Schintgen 2005-10-01 19:37:49 UTC
On Friday 30 September 2005 21:08, matt@eisgr.com wrote:
> One additional consideration should be local encrypted filesystems which
> are *not* removable.  Perhaps a partition, more likely a loopback
> filesystem image (in the form of a file on the HD).


As the original reporter of this bug I'd also like to stress that this isn't 
meant to exclude support for local disks. In fact, I just realized that my 
report was too much centered on the HAL aspect. The important thing is LUKS 
support: it can also be used for local partitions and loopback images. 
Cryptoloop is deprecated in favour of dm-crypt (which offers a superset of 
cryptoloop's functionality). And luks is just a nicer interface to the lower 
level dm-crypt interface. I'd guess that in the relatively near future luks 
will replace the old encryption methods. But of course, KDE's support should 
not be limited to removable devices.
Comment 5 Kevin Ottens 2005-10-01 19:39:09 UTC
Exactly, that was my point and why I closed the old one as duplicate.
Comment 6 rgpublic 2005-11-06 10:39:41 UTC
*** This bug has been confirmed by popular vote. ***
Comment 7 Thiago Macieira 2006-03-11 11:20:29 UTC
*** Bug 123293 has been marked as a duplicate of this bug. ***
Comment 8 Kevin Ottens 2006-06-09 23:39:55 UTC
*** Bug 121020 has been marked as a duplicate of this bug. ***
Comment 9 Roland Wolters 2006-06-10 00:23:51 UTC
To add information which were in "my" duplicate of this bug:
Gnome has a pretty nice implementation of Luks support for at least removable media:
http://blog.fubar.dk/?p=64
http://www.redhat.com/magazine/012oct05/features/hal/

The second link is a nice documentation of the needed hal code.

Besides: The perfect result would be Luks support which can be activated at the KDE login manager: I would like to have a luks encrypted home directory, and it would be nice to login and encrypt my partition just with one single passwort, that means: almost invisible for me.
Comment 10 David Förster 2006-08-30 13:21:32 UTC
Imho, mounting your home directory on login is not KDE's business. There's a PAM module that can do this (for any kind of login, not just KDE).

http://pam-mount.sourceforge.net/
Comment 11 Momsen Reincke 2006-12-24 15:01:14 UTC
Anyway, pam_mount does not solve the problem of removable devices...
Comment 12 Alexandre Nunes 2007-01-14 00:12:22 UTC
This feature is a must have, specially for removable media.
Comment 13 Andreas Cord-Landwehr 2007-03-26 17:59:41 UTC
This feature would be really great. Why does Gnome have such a system but not KDE? The d-bus and HAL layers already receive messages if an LUKS encrypted USB stick is inserted. But apparently no application for key-input is implemented, yet. A work-around is to start the gnome-volume-manager out of your KDE session. That's not nice, but at least it works and you can use a graphical interface to login into the USB stick.
Comment 14 David Förster 2007-03-29 15:51:56 UTC
From http://en.opensuse.org/Factory/News:
- usage of LUKS by default for crypto partitions in YaST. Both GNOME and KDE handle removable LUKS media now.

So it should simply be a matter of reviewing the patches and merge, shouldn't it?
Comment 15 Jakub Schmidtke 2007-07-28 02:22:02 UTC
What is the status of that feature request?

If anyone is interested, I was able to get code from SuSE working
in Archlinux :) Here are sources with description how to do that:

http://strony.aster.pl/tanis/kde_luks

Comment 16 Matthew Flaschen 2007-08-10 12:49:06 UTC
I successfully compiled and used Jakub's code with KDE 3.5.7 on Fedora 7.
Comment 17 Roland Wolters 2007-08-10 13:31:08 UTC
Nice, any chance that we will see this one upstream?
Comment 18 Tommi Tervo 2007-11-01 13:39:41 UTC
*** Bug 148374 has been marked as a duplicate of this bug. ***
Comment 19 David Anderson 2007-11-01 14:51:44 UTC
I've used the code from #15 successfully on Fedora 7 also - had to install the dbus-devel, dbus-qt-devel and hal-devel packages first.

Is there anyone reading this with the know-how to review the code and get it into KDE?
Comment 20 Alexandre Nunes 2007-11-15 14:18:05 UTC
Two years of bug report, I think someone should mark kde media support as unmaintained :-)
Comment 21 Andrew Hailes 2007-11-15 17:19:14 UTC
Agreed :-( It's a pity it's not included, especially as it appears that it's already possible for it to work.
Comment 22 Ritesh Raj Sarraf 2007-11-16 17:09:22 UTC
If all such patches get included immediately to upstream code, what will the difference be in between a mostly "pristine" upstream based distro (Debian) and an almost forked distro (SUSE/Red Hat) ? :-)

But I might be wrong. Nothing apart from their policy stops the distros to pull the patches and include it in their distributions.
Comment 23 David Anderson 2007-11-16 17:46:59 UTC
Reply to #22: I also opened a bug in Fedora to have this patch added to Fedora, but the Fedora maintainer seems to be AWOL on this issue too. :-( 

Reply to #20: I think Kevin has done a huge amount of work on KDE hardware support in the last two years for which we should all thank him and that you are mistaken. It's a shame we can't find someone who's a contributor who's motivated to add this patch though! This bug is #60 on the list of most requested features, but in the vast majority of cases those requested features don't have working, tested patches unlike this one.

Has anyone tried the patch against KDE 3.5.8 now that that's out? Does it work?
Comment 24 Ritesh Raj Sarraf 2007-11-16 18:17:48 UTC
Yes, I'm running it with 3.5.8 on Debian
Comment 25 Jakub Schmidtke 2007-11-16 18:41:27 UTC
Unfortunately, I would say that this patch is of poor quality - more like 'proof of concept', not a real thing that can be added as it is. I think, that the right approach would be to add more sophisticated solution to media manager - so it would be aware of the status of each volume - is it encrypted/decrypted, and could also change that status. But it probably is too much work for KDE 3.5, and probably should be done in 4. I just started working on a small external app/panel applet, that would offer the same behavior without the need to patch KDE.
Comment 26 Jan Klötzke 2007-11-25 12:43:23 UTC
Created attachment 22191 [details]
LUKS suppport via kio media slave

This is a patch I developed a month or two ago to add LUKS support to the kio
media slave. The archive contains a diff (to be applied against kdebase) and a
set of new icons. It enables state tracking (encrypted,unmounted /
decrypted,unmounted / decrypted,mounted), adds a icon to each of the states and
enables state manipulation ("encrypt" -> luksClose) via UI.

The major drawback is that it adds three mime-types (and corresponding icons)
to each media type, but this is caused by the architecture of the media slave.
It was submitted to kde-devel but it seems this approach is a bit too complex
and there is no 3.5.9 planned yet, so I didn't finish it yet...

It works for me for USB pen drives and encrypted hdd partitions. Other media
types are not supported. I post it here just in case anyone is interested...
Comment 27 Jan Klötzke 2008-01-23 23:05:17 UTC
Created attachment 23231 [details]
LUKS support via kio media slave (updated 23/01/08)

Updated the old patch (especially icons) to support now all types of removable
media and fixed some minor bugs. Tested with encrypted USB HDD's, pen drives
and MMC cards.
Comment 28 ZcMander 2008-01-24 19:03:32 UTC
Still not working for me, shows password-field and dbus doesnt return any error, and dolphin shows as mounted, but when i click that place, it jumps back to Home (or current place)
Comment 29 Jan Klötzke 2008-01-28 23:29:08 UTC
Created attachment 23339 [details]
LUKS support via kio media slave (updated 28/01/08)

Some more bugfixes (wrong icon in kicker media applet, some dbus race
conditions).

@ZcMander: Any error messages? Is the drive shown as decrypted (open lock)?  I
don't use dolphin but it should work like in konqueror. For me it works without
problems on Kubuntu 7.10.
Comment 30 Jonathan Patrick Davies 2008-01-30 21:31:45 UTC
Hello, I would just like to say that the first patch is included in the Kubuntu kdebase package:

    https://lists.ubuntu.com/archives/hardy-changes/2007-November/002319.html

I am now working on including the lastest patch.

Thanks
Jonathan

https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/128863
Comment 31 Andy-U 2008-02-06 23:19:02 UTC
I'm trying to get the patch from additional comment #29 from Jan Klötzke 2008-01-28 23:29 running but I'm getting 

dialog.h:37:27: Fehler: decryptdialog.h: No such file or directory

when compiling in kdebase-3.5.8/kioslave/media/mounthelper

Where do I get decryptdialog.h from?
Comment 32 Jan Klötzke 2008-02-08 20:11:12 UTC
You have to run "make -f Makefile.cvs" first to run automake and friends. Then the build should work.
Comment 33 Gabriel Ambuehl 2008-02-12 21:43:03 UTC
> ------- Hello, I would just like to say that the first patch is included in
> the Kubuntu kdebase package:


I can confirm that it works in Hardy, I get asked for a password, then whether 
I want to mount the device, maybe the second step could be automated?
Comment 34 Jakub Schmidtke 2008-02-17 03:34:59 UTC
If anyone is interested in a solution that doesn't involve patching KDE, I have created small utility which does all that (and some more) - for me it does everything I need. Have a look at http://strony.aster.pl/tanis/kde_luks/ (screenshots included ;) )

Comment 35 Joel Sevilleja 2008-03-06 16:01:39 UTC
Jan Klötzke, can you modify your patch to support KDE 3.5.9? Thanks
Comment 36 Adam Williamson 2008-08-21 06:22:27 UTC
Just to note that obviously the switch to KDE 4 changes things here. AFAIK it has no built-in LUKS support, and obviously this patch will not apply, so someone would need to write a new patch for KDE 4.
Comment 37 Ritesh Raj Sarraf 2008-08-21 06:33:27 UTC
(In reply to comment #36)
> Just to note that obviously the switch to KDE 4 changes things here. AFAIK it
> has no built-in LUKS support, and obviously this patch will not apply, so
> someone would need to write a new patch for KDE 4.
> 

No. KDE 4, by default, has support for Encrypted LUKS devices. KDE 4 can detect LUKS Encrypted partitions and list them in Dolphin.

There is one problem though. In KDE 4, for non-partitioned LUKS Encrypted Devices, KDE4 or hald is not able to detect the filesystem label on top of the encrypted device and thus doesn't automount it.
Comment 38 Adam Williamson 2008-08-21 06:46:22 UTC
Ah, OK, that's good. I saw an Ubuntu bug report which suggested this was not the case.
Comment 39 Pedro Algarvio, aka, s0undt3ch 2008-11-11 14:14:29 UTC
(In reply to comment #37)
> (In reply to comment #36)
> > Just to note that obviously the switch to KDE 4 changes things here. AFAIK it
> > has no built-in LUKS support, and obviously this patch will not apply, so
> > someone would need to write a new patch for KDE 4.
> > 
> 
> No. KDE 4, by default, has support for Encrypted LUKS devices. KDE 4 can detect
> LUKS Encrypted partitions and list them in Dolphin.
> 
> There is one problem though. In KDE 4, for non-partitioned LUKS Encrypted
> Devices, KDE4 or hald is not able to detect the filesystem label on top of the
> encrypted device and thus doesn't automount it.
> 

Why doesn't KDE4 then detect that it's a luks filesystem(like it did), prompt user for unlock and then the label would be available/readable and mountable?
Comment 40 Ritesh Raj Sarraf 2008-11-11 18:51:59 UTC
(In reply to comment #39)
> Why doesn't KDE4 then detect that it's a luks filesystem(like it did), prompt
> user for unlock and then the label would be available/readable and mountable?
> 

This is not a bug specific to KDE. KDE just depends on the underneath infrastructure (hal/dbus) for information.

In fact, the problem seems to be with HAL. My initial suspicion was that udev might not be generating the device entry/label correctly, but that doesn't seem to be the reason.


Here,

In Problematic case:
Nov 11 23:10:38 learner udevd-event[5814]: udev_node_update_symlinks: update symlink 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' of '/block/dm-2'
Nov 11 23:10:38 learner udevd-event[5814]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-uuid\x2fbc1026e2-1393-49e7-a6f6-72c01e93b47e'
Nov 11 23:10:38 learner udevd-event[5814]: update_link: found 1 devices with name 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e'
Nov 11 23:10:38 learner udevd-event[5814]: update_link: found '/block/dm-2' for 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e'
Nov 11 23:10:38 learner udevd-event[5814]: update_link: compare (our own) priority of '/block/dm-2' -100 >= 0
Nov 11 23:10:38 learner udevd-event[5814]: update_link: 'disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' with target 'dm-2' has the highest priority -100, create it
Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: found existing symlink '/dev/disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e'
Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: preserve already existing symlink '/dev/disk/by-uuid/bc1026e2-1393-49e7-a6f6-72c01e93b47e' to '../../dm-2'
Nov 11 23:10:38 learner udevd-event[5814]: udev_node_update_symlinks: update symlink 'disk/by-label/USB_SEAGATE' of '/block/dm-2'
Nov 11 23:10:38 learner udevd-event[5814]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-label\x2fUSB_SEAGATE'
Nov 11 23:10:38 learner udevd-event[5814]: update_link: found 1 devices with name 'disk/by-label/USB_SEAGATE'
Nov 11 23:10:38 learner udevd-event[5814]: update_link: found '/block/dm-2' for 'disk/by-label/USB_SEAGATE'
Nov 11 23:10:38 learner udevd-event[5814]: update_link: compare (our own) priority of '/block/dm-2' -100 >= 0
Nov 11 23:10:38 learner udevd-event[5814]: update_link: 'disk/by-label/USB_SEAGATE' with target 'dm-2' has the highest priority -100, create it
Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: found existing symlink '/dev/disk/by-label/USB_SEAGATE'
Nov 11 23:10:38 learner udevd-event[5814]: node_symlink: preserve already existing symlink '/dev/disk/by-label/USB_SEAGATE' to '../../dm-2'
Nov 11 23:10:38 learner udevd-event[5814]: pass_env_to_socket: passed 751 bytes to socket '/org/freedesktop/hal/udev_event',
Nov 11 23:10:38 learner udevd-event[5814]: pass_env_to_socket: passed -1 bytes to socket '@/org/kernel/udev/monitor',
Nov 11 23:10:38 learner udevd-event[5814]: udev_event_run: seq 1435 finished with 0
Nov 11 23:10:38 learner udevd[1240]: udev_done: seq 1435, pid [5814] exit with 0, 0 seconds old

udev did its job. it exited cleanly.

Now the non-problematic case:
Nov 11 23:15:54 learner udevd-event[6064]: udev_node_update_symlinks: update symlink 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' of '/block/dm-3'
Nov 11 23:15:54 learner udevd-event[6064]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-uuid\x2fb1d29a26-9d95-4aa4-8d9d-9498a874312e'
Nov 11 23:15:54 learner udevd-event[6064]: update_link: found 1 devices with name 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e'
Nov 11 23:15:54 learner udevd-event[6064]: update_link: found '/block/dm-3' for 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e'
Nov 11 23:15:54 learner udevd-event[6064]: update_link: compare (our own) priority of '/block/dm-3' -100 >= 0
Nov 11 23:15:54 learner udevd-event[6064]: update_link: 'disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' with target 'dm-3' has the highest priority -100, create it
Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: found existing symlink '/dev/disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e'
Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: preserve already existing symlink '/dev/disk/by-uuid/b1d29a26-9d95-4aa4-8d9d-9498a874312e' to '../../dm-3'
Nov 11 23:15:54 learner udevd-event[6064]: udev_node_update_symlinks: update symlink 'disk/by-label/USBDISK' of '/block/dm-3'
Nov 11 23:15:54 learner udevd-event[6064]: udev_db_get_devices_by_name: found index directory '/dev/.udev/names/disk\x2fby-label\x2fUSBDISK'
Nov 11 23:15:54 learner udevd-event[6064]: update_link: found 1 devices with name 'disk/by-label/USBDISK'
Nov 11 23:15:54 learner udevd-event[6064]: update_link: found '/block/dm-3' for 'disk/by-label/USBDISK'
Nov 11 23:15:54 learner udevd-event[6064]: update_link: compare (our own) priority of '/block/dm-3' -100 >= 0
Nov 11 23:15:54 learner udevd-event[6064]: update_link: 'disk/by-label/USBDISK' with target 'dm-3' has the highest priority -100, create it
Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: found existing symlink '/dev/disk/by-label/USBDISK'
Nov 11 23:15:54 learner udevd-event[6064]: node_symlink: preserve already existing symlink '/dev/disk/by-label/USBDISK' to '../../dm-3'
Nov 11 23:15:54 learner udevd-event[6064]: pass_env_to_socket: passed 735 bytes to socket '/org/freedesktop/hal/udev_event',
Nov 11 23:15:54 learner udevd-event[6064]: pass_env_to_socket: passed -1 bytes to socket '@/org/kernel/udev/monitor',
Nov 11 23:15:54 learner udevd-event[6064]: udev_event_run: seq 1459 finished with 0
Nov 11 23:15:54 learner udevd[1240]: udev_done: seq 1459, pid [6064] exit with 0, 0 seconds old
Nov 11 23:15:54 learner NetworkManager: <debug> [1226425554.923853] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/volume_uuid_b1d29a26_9d95_4aa4_8d9d_9498a874312e').

Here too udev did its job. But here also the device got added to hal.

KDE4 must be relying on hal for device discovery/state.


So this seems to be a bug with HAL not adding partition-less crypt devices into its database.


PS: Does anyone know what NetworkManager has to do with in the logs ?
Comment 41 Paulo Fidalgo 2009-01-06 11:50:03 UTC
In a google search, for "hal luks disk encryption", I've seen some related articles, altough, since I'm not familiar enough with hal, I can not assure if it has support or not.
I'm just adding myself to CC, and vote, since now I use encrypted usb drives, I would like to see support for them in my desktop.

Best regards!
Comment 42 unggnu 2009-02-08 10:45:44 UTC
KDE4 can mount LUKS devices but it is not complete yet.
At first the StorageVolume manager doesn't show the encrypted devices which makes no sense if KDE4 can mount them imho.
The second one is that Dolphin doesn't show any information about the encrypted devices. Gnome e.g. shows the size which is great since I have an USB hard disk with two encrypted devices (root and home).
The third and most important drawback is that passwords can't be saved in Kwallet like Gnome does. If I attach a usb hard disk with a LUKS partition which password was saved under Gnome it is auto mounted like any other USB devices which makes working with LUKS very easy.
Comment 43 Ritesh Raj Sarraf 2009-02-08 16:23:53 UTC
(In reply to comment #42)
> KDE4 can mount LUKS devices but it is not complete yet.
> At first the StorageVolume manager doesn't show the encrypted devices which
> makes no sense if KDE4 can mount them imho.

I'm not sure what you mean by StorageVolume Manager here. When an encrypted device is plgged in, it does get listed in Dolphin. And there you can open the encrypted volume and then you get the real decrypted device. But yes, there is no device notification for an ecrypted volume plugged in.

> The second one is that Dolphin doesn't show any information about the encrypted
> devices. Gnome e.g. shows the size which is great since I have an USB hard disk
> with two encrypted devices (root and home).

I'm not sure if info from an encrypted device can be extracted before it is decrypted. In dolphin, once the device is opened, the virtual decrypted device does have its size info listed.

> The third and most important drawback is that passwords can't be saved in
> Kwallet like Gnome does. If I attach a usb hard disk with a LUKS partition
> which password was saved under Gnome it is auto mounted like any other USB
> devices which makes working with LUKS very easy.
> 
Yes, I think this applies. 
Comment 44 unggnu 2009-02-08 18:10:20 UTC
>I'm not sure what you mean by StorageVolume Manager here.
The KDE4 plugin which pops up from systray and shows the plugged in devices.

>I'm not sure if info from an encrypted device can be extracted before it is >decrypted.
The size of the partition should be no problem. More isn't needed.
If you don't know any information about the devices you often have to mount both of them when you only need one.

Btw. Nautilus shows always the size of an unmounted partition if it has no name. I guess this feature isn't implemented in Dolphin too. The only change between unnamed and LUKS partitions is the encrypted addition.
Similar to this image: http://people.ubuntu.com/~jamesw/private-nautilus.png

But of course the most important is the last one, the password saving.
Comment 45 Kevin Ottens 2009-02-27 19:32:40 UTC
OK, this one should have been closed long ago, it's spreading in too many directions. I'm closing it as the main issue: reading LUKS devices got fixed long ago in the KDE4 serie.

Now if you have specific features missing for encrypted volumes in KDE4 please report them as *separate* entries and mark them as bugs or wish as appropriate.
Comment 46 unggnu 2009-03-10 15:49:55 UTC
I have created a new wishlist report for the password saving: https://bugs.kde.org/show_bug.cgi?id=186783