Tails

#1 Updated by intrigeri 2014-08-04 09:49:19

• Parent task deleted (Feature #5703)

#2 Updated by intrigeri 2014-09-22 11:38:58

• Type of work changed from Upstream to Wait

#3 Updated by intrigeri 2016-02-13 00:58:45

• has duplicate Bug #11069: GUI for CRYPTSETUP. added

#4 Updated by Dr_Whax 2016-08-20 13:45:49

• blocks Feature #11684: Add support for VeraCrypt volumes in GNOME Disks added

#5 Updated by intrigeri 2016-08-23 00:18:51

• Assignee set to segfault
• Target version set to 2017
• Type of work changed from Wait to Code

#6 Updated by Anonymous 2017-06-27 15:13:53

• Deliverable for set to 299

#7 Updated by segfault 2017-08-24 13:02:21

• Subject changed from Add support for TrueCrypt volumes in udisks to Add support for TrueCrypt/VeraCrypt volumes in udisks
• Description updated
• Target version changed from 2017 to SponsorW_2017

udisks now uses libblockdev as a backend, and libblockdev already supports opening truecrypt/veracrypt volumes. So we only have to make udisks use the libblockdev functions for handling truecrypt/veracrypt volumes.

#8 Updated by segfault 2017-08-28 13:52:49

• Subject changed from Add support for TrueCrypt/VeraCrypt volumes in udisks to Add support for VeraCrypt volumes in udisks

#9 Updated by segfault 2017-08-28 14:34:18

• blocks Feature #14464: Add VeraCrypt support to GNOME Files added

#10 Updated by segfault 2017-08-28 14:40:21

• blocked by deleted (Feature #11684: Add support for VeraCrypt volumes in GNOME Disks)

#11 Updated by segfault 2017-08-28 14:40:33

• blocked by deleted (Feature #14464: Add VeraCrypt support to GNOME Files)

#12 Updated by segfault 2017-08-28 14:42:11

• Parent task set to Feature #14468

#13 Updated by segfault 2017-08-28 14:45:06

• Target version deleted (SponsorW_2017)

#14 Updated by segfault 2017-08-28 14:54:21

• Target version set to Tails_3.5

#15 Updated by segfault 2017-08-28 14:54:51

• blocks Feature #11684: Add support for VeraCrypt volumes in GNOME Disks added

#16 Updated by segfault 2017-08-28 14:54:58

• blocks Feature #14464: Add VeraCrypt support to GNOME Files added

#17 Updated by intrigeri 2017-09-29 17:20:51

• Description updated

#19 Updated by segfault 2017-10-10 16:11:25

• Assignee changed from segfault to anonym
• QA Check set to Ready for QA

I added a function block_seems_encrypted() which calculates the chi square value to determine whether the device seems to contain random data. Using this, I can display the unlock button in GNOME Disks only for random looking devices, which includes devices encrypted with TrueCrypt or VeraCrypt, but also other encryption types like dm-crypt in plain mode and loop-AES (see my email Re: TrueCrypt/VeraCrypt volumes undetectable on tails-dev@).

Another problem I faced while working on GNOME Disks is that it showed the encryption type of TrueCrypt volumes as crypto_unknown even after decrypting the volume, although after successful decryption it is clear that the encryption type is TrueCrypt. I solved this by adding a hint_encryption_type property to the Encrypted interface, which I set on a successful decryption (in udisks).

Could you review this anonym?

#21 Updated by anonym 2017-10-21 14:05:16

• Status changed from Confirmed to In Progress
• Assignee changed from anonym to segfault
• QA Check changed from Ready for QA to Dev Needed

segfault wrote:
> I added a function block_seems_encrypted() which calculates the chi square value to determine whether the device seems to contain random data. Using this, I can display the unlock button in GNOME Disks only for random looking devices, which includes devices encrypted with TrueCrypt or VeraCrypt, but also other encryption types like dm-crypt in plain mode and loop-AES (see my email Re: TrueCrypt/VeraCrypt volumes undetectable on tails-dev@).

Cool!

> Another problem I faced while working on GNOME Disks is that it showed the encryption type of TrueCrypt volumes as crypto_unknown even after decrypting the volume, although after successful decryption it is clear that the encryption type is TrueCrypt. I solved this by adding a hint_encryption_type property to the Encrypted interface, which I set on a successful decryption (in udisks).

My understanding is that this is fixed; let me know if I have misunderstood!

> Could you review this anonym?

All looks good until 1d4d37f5268a980774fbe358f20b2cc87e28b96d (“Set hint_encryption_type on successful decryption”), good job!

However, please don’t rebase the branch while I’m still looking at it as it makes it hard for me to track the exact changes without taking extra steps.

> I continued working on this. To let the user choose which type an encrypted device is, I added radio buttons to the GNOME Disks unlock dialog, and use the chosen type in the udisks unlock function (currently only TrueCrypt and VeraCrypt, but I could easily add dm-crypt plain and Loop-AES too, if we decide that we want that).
>
> Afterwards, I noticed that if cryptsetup’s unlock is called with the VeraCrypt option, it also tries the TrueCrypt modes in addition to the VeraCrypt modes [1]. This means that if we would always use the VeraCrypt option to unlock possible TC/VC volumes, we can unlock both TrueCrypt and VeraCrypt option. So we don’t actually have to ask the user whether a device is TrueCrypt or VeraCrypt encrypted. A disadvantage of this is that trying to unlock VeraCrypt volumes takes a lot longer than trying to unlock TrueCrypt volumes, especially if the password is wrong, so that all modes are tested [2]. This means that when a TrueCrypt user enters their password incorrectly, they would have to wait a lot longer [3].
>
> [1] I asked on the dm-crypt mailing list to confirm that this is intentional.
> [2] This is because VeraCrypt uses more iterations for the key derivation function, in order to make brute forcing harder. So this is a feature.
> [3] On my system, cryptsetup unlock with the VeraCrypt option and an incorrect password takes 15 seconds, versus 0.2 seconds for TrueCrypt volumes.

Thanks for getting to the bottom of this!

> Now I see three options, and I think we should balance the pros and cons:
>
> 1. Always use the VeraCrypt option to unlock devices which could be TC/VC volumes.
>
> * Pro: No additional options exposed to the user.
> * Con:
>
> * dm-crypt plain and Loop-AES encrypted devices unsupported
> * dm-crypt plain and Loop-AES encrypted devices are treated as TC/VC candidates (more false positives)
> * TrueCrypt users have to wait longer if they enter their password incorrectly
>
> 2. Let user choose from VeraCrypt, TrueCrypt, dm-crypt plain, and Loop-AES
>
> * Pro: None of the cons of 1.
> * Con: options exposed to the user
>
> 3. Let user choose from VeraCrypt, TrueCrypt
>
> * Pro: TrueCrypt users don’t have to wait longer if they enter their password incorrectly
> * Con: All other cons of 1. and 2.
>
> 3 seems like the worst choice. I’m not sure about 1 or 2, but I lean towards 2. What do you think? Did I miss anything?

I’m not sure either. I sort of like 1:

• we (Tails) don’t care about dm-crypt plain and Loop-AES support, and I expect few people do, and those that do are probably experts that don’t depend on this functionality in GNOME Disks (personal anecdotes: I’ve only seen people use those for FDE of their system, not for removable media where having this kind of integration is convenient).
• I would expect dm-crypt plain and Loop-AES volumes to be really uncommon (again, only used by “experts”) so I’m not worried about them causing much confusion via false positives.
• Since TrueCrypt is a legacy mode that people should migrate away from, the long waiting time in case of passphrase typos isn’t so bad.

But 2 is not so bad, but I think TrueCrypt and VeraCrypt can be merged, per the argument of my last point above. By the same argument, 3 becomes the same as 1.

I think you should ask sajolida’s opinion (and weigh it higher than mine :))!

#22 Updated by segfault 2017-10-23 09:45:44

• Assignee changed from segfault to sajolida
• QA Check changed from Dev Needed to Info Needed

anonym wrote:
> segfault wrote:
> > Another problem I faced while working on GNOME Disks is that it showed the encryption type of TrueCrypt volumes as crypto_unknown even after decrypting the volume, although after successful decryption it is clear that the encryption type is TrueCrypt. I solved this by adding a hint_encryption_type property to the Encrypted interface, which I set on a successful decryption (in udisks).
>
> My understanding is that this is fixed; let me know if I have misunderstood!

Well yeah, I found a solution. I’m not sure if it is the best one, because the D-Bus properties are reset after restarting the udisks2 service (i.e. after reboot). To persistently store the encryption type, it would have to be stored in (yet another) device config file. But this config file would also prove that a device is a TC/VC volume and that it has been accessed from the system, something that TrueCrypt and VeraCrypt try to avoid by default (i.e. if a volume is not set as a favorite).
So I think my solution is good enough for a start, and we’ll see what upstream thinks about this.

> All looks good until 1d4d37f5268a980774fbe358f20b2cc87e28b96d (“Set hint_encryption_type on successful decryption”), good job!

Cool, thanks for the review!

> However, please don’t rebase the branch while I’m still looking at it as it makes it hard for me to track the exact changes without taking extra steps.

Ok, sorry about that.

> > Now I see three options, and I think we should balance the pros and cons:
> >
> > 1. Always use the VeraCrypt option to unlock devices which could be TC/VC volumes.
> >
> > * Pro: No additional options exposed to the user.
> > * Con:
> >
> > * dm-crypt plain and Loop-AES encrypted devices unsupported
> > * dm-crypt plain and Loop-AES encrypted devices are treated as TC/VC candidates (more false positives)
> > * TrueCrypt users have to wait longer if they enter their password incorrectly
> >
> > 2. Let user choose from VeraCrypt, TrueCrypt, dm-crypt plain, and Loop-AES
> >
> > * Pro: None of the cons of 1.
> > * Con: options exposed to the user
> >
> > 3. Let user choose from VeraCrypt, TrueCrypt
> >
> > * Pro: TrueCrypt users don’t have to wait longer if they enter their password incorrectly
> > * Con: All other cons of 1. and 2.
> >
> > 3 seems like the worst choice. I’m not sure about 1 or 2, but I lean towards 2. What do you think? Did I miss anything?
>
> I’m not sure either. I sort of like 1:
>
> * we (Tails) don’t care about dm-crypt plain and Loop-AES support, and I expect few people do, and those that do are probably experts that don’t depend on this functionality in GNOME Disks (personal anecdotes: I’ve only seen people use those for FDE of their system, not for removable media where having this kind of integration is convenient).
> * I would expect dm-crypt plain and Loop-AES volumes to be really uncommon (again, only used by “experts”) so I’m not worried about them causing much confusion via false positives.
> * Since TrueCrypt is a legacy mode that people should migrate away from, the long waiting time in case of passphrase typos isn’t so bad.
>
> But 2 is not so bad, but I think TrueCrypt and VeraCrypt can be merged, per the argument of my last point above. By the same argument, 3 becomes the same as 1.

I think you’re right and probably no one cares about dm-crypt plain and Loop-AES. So I’m totally fine with 1, but I’m also curious what upstream will say about this.

> I think you should ask sajolida’s opinion (and weigh it higher than mine :))!

Right. I’m assigning this to sajolida then.

#23 Updated by segfault 2017-10-23 10:00:13

• File Screenshot GNOME Disks.jpg added

Another thing I would like to get feedback on is my choice of the “crypto_unknown” labels. I chose “Possibly Encrypted” as the long description and “Encrypted?” as the short description in udisksclient.c. You can see how this is displayed in GNOME Disks in the attached screenshot. I’m not really happy with this, maybe you come up with something better.

If we would go with option 1, we could also drop the “crypto_unknown” type and treat every block device which passes the Chi-Square test as a TC/VC volume and set the description to “TCRYPT” or “TrueCrypt/VeraCrypt”. Then we also wouldn’t need the hint_encryption_type property, and wouldn’t have to care about it not being persistent. On the other hand, it could of course lead to false positives, which would be confusing to the user. What do you think?

#27 Updated by segfault 2017-12-12 10:16:04

• Assignee changed from sajolida to segfault
• QA Check deleted (Info Needed)

During the UX sprint we decided to implement option 1 from above, for the same reasons we already discussed above.

#28 Updated by anonym 2018-01-23 19:52:47

• Target version changed from Tails_3.5 to Tails_3.6

#29 Updated by segfault 2018-01-25 12:06:23

• Target version changed from Tails_3.6 to Tails_3.9

Will be resolved by Feature #15215 and Feature #15049

#30 Updated by intrigeri 2018-06-03 12:56:27

• Status changed from In Progress to Resolved

(We likely won’t do iteration 3 as part of this project and everything else was done in udisks.)