VeraCrypt/TrueCrypt support in GNOME Disks

Kai Lüke kailueke at riseup.net
Tue Nov 14 09:02:18 UTC 2017


Seems I misunderstood while reading, so you already have code.
If your way of identifying encrypted partitions works good enough (which
is funny because the partition is not really hidden then) you can ignore
my sentences on presenting those device contents.
>From the GNOME Disks point of view it would be good if things work
mostly the same, e.g. UDisks.Block.CryptoBackingDevice and
udisks_client_get_cleartext_block.


Am 14.11.2017 um 17:36 schrieb Kai Lüke:
> 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
> * 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.
>
> 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.
>
> Regards,
> Kai
>
> Am 14.11.2017 um 02:55 schrieb segfault:
>> Hey,
>>
>> thanks for the quick response!
>>
>> Bastien Nocera:
>>> [...]
>>> What UI differences would be needed to handle those different types of
>>> encryption? I'm guessing none for handling encrypted disks, because the
>>> UI should be pretty much the same as for the existing LVM based
>>> encryption support.
>> Do you mean the LUKS encryption? In that case you would be correct, the
>> UI *should* be pretty much the same. But with VeraCrypt/TrueCrypt
>> encrypted volumes we have the difficulty that the volumes can not be
>> detected as such with absolute certainty, because, by design, they just
>> look like random data, and, in contrast to LUKS, have no cleartext
>> header. So we need to figure out a good way to indicate to our users
>> that a volume *could* be a VeraCrypt/TrueCrypt volume (because it looks
>> like random data).
>> There is also a possibility of confusion with dm-crypt plain and LoopAES
>> volumes, because those also look like random data. So we thought about
>> adding a dialog which lets the user specify the encryption type when
>> they want to unlock a (possibly) encrypted volume. We started discussing
>> implications of this on [1], and are currently leaning towards ignoring
>> dm-crypt plain and LoopAES and omitting an additional dialog.
>>
>> [1] https://labs.riseup.net/code/issues/6337
>>
>>> How to deal with creating encrypted volumes, and even more so when
>>> talking about other types of encryption would need to be designed after
>>> you've figured out whether it makes any difference to the user, and how
>>> it would get integrated in UDisks.
>> We do not intend to add support for *creating* encrypted volumes, but
>> only unlocking/locking.
>>
>>> I'd start with adding a transparent way to mount encrypted disks and
>>> volumes in UDisks, and see whether anything else is needed on top of
>>> that for your users, including explaining why particular types of
>>> encryption are better than others and under which circumstances.
>> I agree that we should start with adding the support to UDisks (which I
>> already started doing).
>>
>>> I'm also not sure what "file containers" and "keyfiles" are, but it
>>> sounds like filesystem level encryption which would likely live in GIO
>>> and UIs on top of it, not in Disks or UDisks.
>> File containers are not filesystem level encryption, but encrypted
>> volumes which are stored in a file on the filesystem instead of a block
>> device. They could be handled by UDisks/Disks by first mapping a loop
>> device to the file container (for example using udisksctl loop-setup,
>> gnome-disk-image-mounter or the "Attach Disk Image..." option in Disks).
>>
>> If a VeraCrypt/TrueCrypt volume is configured to use keyfiles, all
>> configured keyfiles need to be added in addition to the password (if
>> any) in order to unlock the volume (similar to LUKS keyfiles, which are
>> supported by UDisks/Disks, except that those replace the passphrase).
>> This also has nothing to do with filesystem level encryption.
>>
>> Cheers!
>> _______________________________________________
>> devkit-devel mailing list
>> devkit-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/devkit-devel
>
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/devkit-devel




More information about the devkit-devel mailing list