Please add luks support

Thanks for your interest in GParted.  There is a bug enhancement request for this feature.

Bug 171144 - supporting resizing of encrypted partition

Do you know what steps or commands to use from a terminal to resize LUKS?  If so then if would help if you could post these commands.

Unfortunately I too am unaware of any existing commands to resize LUKS.  If anyone does learn of such commands then we would like to hear about these.

Thank you for the extra information.

These examples appear to use LVM.  Support for LVM has not yet been added to GParted either and there is an open bug request.
Bug 160787 - lvm support

Thanks again for the extra info.

GParted does detect crypt-luks partitions as stated in the features page.  That is all that it does at present though.

Time is what is needed most.  If you have time to research the problem and the code and develop a patch then that would help immensely.

I received this response about cryptsetup:

Comment #1 on issue 114 by gmazyl...@gmail.com: Request:  coordinate with GParted to enable resizing of encrypted partitions
http://code.google.com/p/cryptsetup/iss … ail?id=114

So they should ask. Resizing of active mapping is just one call of libcryptsetup, see action_resize() in cryptsetup.c

Resize underlying device, call crypt_resize() and you are done. The problem is that it is sometimes impossible to properly resize kernel partition if it is in use.

For activating device there is nothing to do - cryptsetup will read new partition size. No size stored on disk.

Does this mean that if the underlying space is allocated by GParted during a resize operation, then the cryptsetup resizing is trivial? If so then (If I understand correctly) would the encrypted partition then need to be opened so that the filesystem contained in it can be resized? If so, then how would GParted then go about prompting for the key phrase to unlock it? Would that necessarily entail mounting the filesystem, or would the filesystem remain unmounted but just decrypted so that the resize of the filesystem could then take place? These are things best coordinated directly rather than through an intermediary as I may or may not understand the situation completely enough to ask the right questions.

The information I previously posted is how cryptsetup resizes the encrypted partition. However, in order to do this, the underlying device's space allocation must be changed. This is not something that cryptsetup can accomplish. Can GParted resize the space allocated (and in the process, move the existing encrypted information to the new location if the starting point changes such as adding space on the front? If so then the commands detailed in post # 12 would seem to be sufficient to accomplish the task. The next thing would be to give GParted a means of unlocking the encryption so that the filesystem can then be expanded to fill the new space.

For example, expanding by adding new space on the end:

Before:  |---------------------------------------|
After:     |--------------------------------------------------------------------------|

expand partition's allocation, call crypt-resize(), unlock encryption, expand filesystem.

Move and add:

Before:                        |---------------------------------------|
After:    |--------------------------------------------------------------|

Expand partition's allocation, copy bit-by-bit the information to the front of the new space, call crypt-resize(), unlock encryption, expand filesystem.

I am posting a request for command line examples of how to do this on the cryptsetup page. It would be simpler if you would go there yourself and ask as the developer there who replied seemed more than willing to assist. A direct communication between GParted developers and cryptsetup developers would likely lead to better results than me trying to work my way through the mechanics of this action.

Unfortunately, my time is also quite limited. I am a seminary student, and the coursework which I must complete does not allow me the time to do this. So it is something that, no matter how desirable it would be to have this working, must wait until one of us has the time available to work on it.  Thank you for your taking the time to discuss this with me. Even if it is (so to speak) on the back burner, it is nice to know it is at least on the stove.

I have performed this task manually, and it's really simple. Basically, there is _almost_ no surprise - but please read the WARNING at the end.

Provided that the encrypted device is not in use, to enlarge it you need:
1) enlarge the underlying partition. Gparted can already do this
2) activate the encrypted device with "cryptsetup luksOpen <path-to-underlying-partition> <encrypted-device-name>". For example, it could be "cryptsetup luksOpen /dev/sda2 my_secure_device"
    Obviously, you may need to enter your secret password to perform this step!
3) the file-system inside /dev/mapper/<encrypted-device-name> is now accessible _unencrypted_, so it can be enlarged with _normal_ tools. Gparted can already do this.

The key point is the one cited by StephenH: "For activating device there is nothing to do - cryptsetup will read new partition size. No size stored on disk."
I can confirm this from personal experience, i.e. I tried and it works: there is no need to tell LUKS that the underlying partition changed size. You would need to call crypt_resize() or "cryptsetup resize ..." only if the encrypted device was already active, but in the scenario depicted above this cannot happen.

To shrink a filesystem, you must (quite) obviously perform the opposite operations in inverse order:

0) make sure the encrypted device is active (you can use step 2 above if not)
1) the file-system inside /dev/mapper/<encrypted-device-name> is now accessible _unencrypted_, so it can be shrank  with _normal_ tools. Gparted can already do this.
2) deactivate the encrypted device with "cryptsetup luksClose <encrypted-device-name>". For example, it could be "cryptsetup luksClose my_secure_device". Your secret password is not required here.
3) shrink  the underlying partition. Gparted can already do this.

WARNING: LUKS encrypted devices start with a LUKS header that takes some space - the exact amount can change, and running "cryptsetup luksDump <path-to-underlying-partition>" will report it, among other information, after the label "Payload offset:" (encrypted device does not need to be active to run this command). In some examples I tried, the "Payload offset" varied between 2056 and 4096, and it appears to be expressed in sectors (i.e. the unit is 512 bytes). I have no idea which unit is used if you have a disk whose sectors are not 512 bytes (it happens with newer disks, see "advanced disk format").

This "Payload offset" is not a problem when enlarging: file-system enlarging tools will check for available space in encrypted device - even without knowing it's encrypted.
Instead, while shrinking it means that the used space inside the underlying partition is _larger_ than the file-system length, and the underlying partition minimum size is file-system length _plus_ the "Payload offset" (be careful when adding them, they could be in different units).

Hello Curtis,

you kindly accepted my offer to integrate my program fstransform as a gparted plugin, so I am giving priority to that task for obviously personal reasons.

I will be honest and direct: my spare time is quite limited, so I do not know if/when I can have time to work also on this second task.

Thanks for your kind and quick reply,

Massimiliano

Hi,

I have written a patch to add initial luks support. Please find it here:
http://pastebin.com/2NzWJCp2

I'm not sure how to proceed with the development. Should I open a bug report
for this? (I didn't find a matching one)

I'm looking forward to your comments.
Especially, I was not sure about using libcryptsetup vs. calling cryptsetup binary.
I find the first options more elegant, but it seems that the second option is used more often
throughout the code.

Best wishes
Matthias

Edit: updated url