VeraCrypt/TrueCrypt support in GNOME Disks

[Vratislav Podzimek]

On Tue, 2017-11-14 at 17:36 +0900, Kai Lüke wrote:
> Hello,
> 
> of course there is more than one way to do it, but this is how I quickly
> thought about this:
> 
> * use the cryptsetup support for locking/unlocking in libblockdev and
> make it work from the UDisks2.Encrypted interface
> * add the UDisks2.Encrypted interface in UDisks if the block device
> content could not be identified
Please note that a TC/VC device can easily be identified as something else
-- having the first few random bits accidentally being recognized as some
other format's signature.

> * GNOME Disks needs some changes in terms of how to present such a
> device in a different way from normal LUKS devices since for most people
> the block device is indeed empty and it would be confusing to confront
> everybody with failing decryption actions (maybe call the action
> "attempt to unlock hidden volume")
> * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in
> UDisks (currently lacking for LUKS as well) and a way to select a
> keyfile from GNOME Shell is needed. One could also decide to explicitly
> ignore them there and only offer unlocking via GNOME Disks.
Correct me if I'm wrong, but key files in TC/VC are a little bit different
concept than key files in LUKS where they are simply files containing the
passphrase (binary) data.

> 
> This should give support for existing containers/partitions. I would
> treat containers as normal filesystem images. When opened from nautilus
> they are mounted read-only by default with gnome-disk-image-mounter →
> need to expose writeable mount there.
> 
> If desired at some point: Formatting a partition/block device with
> veracrypt needs to be added to libblockdev (maybe cryptsetup can't do it
> but 3rd party binaries like zulucrypt-cli). This has to be made
> available from UDisks2.Block.Format()
> Then, to create a new container, one would open GNOME Disks, create an
> empty disk image and format it.
> Currently the format dialog offers no encryption option for NTFS/FAT →
> add veracrypt here. The dialog page with other filesystems  could also
> expose veracrypt if that is really needed.
> 
> Please give some feedback if this rough plan fits the needs. Not all can
> be planned in advance but discussing things now raises the chances to
> consider some corner cases before code lands.
> The best is to open issues for each needed part in every involved
> project, I will review the parts for GNOME Disks and also have time to
> work on something from January/Feburary if needed.
Sounds great to me otherwise. Thanks for working and willing to work on
this, everybody!

-- 
Vratislav Podzimek
Senior Software Engineer
Kernel Storage
Red Hat Czech, Brno