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).