VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

.. ink ..:
> On Tue, Nov 14, 2017 at 10:02 PM, segfault <segfault at riseup.net> wrote:
> 
> 
>> We do not plan to support creating new TC/VC containers, and I didn't
>> even know that zulucrypt can do this (thanks for the hint!). I find the
>> idea tempting, maybe I will work on that at some point.
>>
> 
> zuluCrypt[0] uses zuluplay[1] to create and unlock TC/VC volumes and
> if you are to add support for creating
> TC/VC volumes then i think zuluplay will be a better dependency to have.

Thanks, I will look into this when/if I start working on support for
creating TC/VC volumes.

> While here,i think it is a bad idea to try to figure out if a volume
> is a TC/VC volume because there will be no point
> in using these over LUKS if a volume can reliably be guessed to be
> TC/VC. Best thing to do is to call blkid on the
> volume and assume it is encrypted if blkid fail to find a file system
> on it and the volume is not a swap partition.

I think there is no way to identify a swap partition as such (unless it
is currently enabled for swapping).

> Doing guess work here will just result in inconsistent behavior and a
> support nightmare.

I think the opposite is true. If we would use standard ways to identify
the filesystem type, we would have inconsistent behavior, because this
means checking for (small) magic numbers, often only two bytes. I
verified that modifying only two bytes in a TC volume made it appear as
a FAT volume in UDisks / GNOME Disks. So there is a non-negligible
chance that a TC/VC volume would be wrongly detected as
filesystem-formatted (i.e. greater than 1/2^16). In contrast, the
chi-squared test never identifies a filesystem header as random (I
forgot to note in my previous email that we calculate chi square only
over the first 512 bytes of the volume). There are still false
positives, but none that the blkid method wouldn't also have (i.e.
devices overwritten with random data, dmcrypt-plain volumes or loopAES
volumes).

Cheers!