intrigeri: > sajolida wrote (20 Mar 2015 12:34:35 GMT) : >> I think that our long-term objective is to have people move out of >> using TrueCrypt technologies in general (be it the software, the >> volumes, or the containers). > > Now you make me curious: why do you think we should get rid of the > TrueCrypt on-disk format?
I was saying this because I thought it was our vision when getting rid of TrueCrypt, but I have no strong argument against TrueCrypt on-disk format as such myself. My understanding was basically that we had no good reasons for supporting it as we had LUKS already. > The way I see it, we're stuck between a rock and a hard place: > > Ideally we'd like to be able to fully replace TrueCrypt volumes (I'm > assuming that I'm missing information that makes you think we should) > with something else, but nothing equivalent exists yet. Sadly, I'm not > aware of any plan (let alone serious effort) towards making this > a reality, when one takes into account the need for: > > - inter-operability (which I'm tempted to disregard as a dangerous > way to share data with an untrusted OS, but then if we don't > support TrueCrypt volumes at all, perhaps users who won't/can't > fully give up proprietary software will just be forced to either > store and share the very same data in cleartext, or to use > something less safe than Tails) > > - "hidden" volumes (which may be a false promise in TrueCrypt, but > still people want that and AFAIK there's nothing even approaching > it, be it in terms of peer-review of existing production-quality > implementations) Thanks to Jasper we can add "containers" to that list. All those are usability and interoperability issues that have real but non-obvious security implications (not in terms of crypto but in terms of user scenario). I'm not really convinced by containers and hidden volumes as such in the context of a pure Tails setup, so we're left with interoperability as the most interesting feature. > With this in mind, supporting the TrueCrypt on-disk format (even > minimally) still makes sense for the time being IMO. I doubt we'll > actively patch out the corresponding code from cryptsetup, so I take > for granted that we'll keep this support in Tails as long as > cryptsetup has it. Agreed. > We had good reasons to get rid of the TrueCrypt software itself, but > no existing GUI for TrueCrypt volumes is satisfying right now, in the > context of Tails. > > Now, of course a CLI-only interface isn't encouraging for Tails users > to go on using TrueCrypt volumes. This has both advantages (as > a long-term strategy, hopefully it'll encourage people to either fully > replace TrueCrypt volumes with a better design), and drawbacks (until > our fancy long-term plans are made real by $someone $some_day, Tails > users have the choice between using something we claim we don't really > support, with poor usability, and doing something even worse). > > So, the question I'm coming to is: assuming there *was* satisfying GUI > support for the TrueCrypt on-disk format (in GNOME Disks, Nautilus, > etc.), would we want to explicitly support that, or still depict it as > a suboptimal feature, and call it unsupported because we think it > should ideally be replaced by something else on the long term? We have a long tradition of advertising only one tool for one job. So what would we advertise TrueCrypt for? Exchanging encrypted data with other operating systems? With big fat warnings? Maybe... > In other words: how hard should we push for adding support for the > TrueCrypt on-disk format in udisks and friends? (Until 15 minutes ago, > I was convinced that it was the way to go, and prepared to go ping the > right folks about it, but now you've planted some non-negligible > amount of doubt in my mind, so I'm a bit lost in terms of strategy.) Me too :) -- sajolida _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
