intrigeri:
> sajolida wrote (01 Apr 2015 11:08:49 GMT) :
>> 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,
>
> This doesn't match my memories, quite the contrary. There must have
> been a fair amount of misunderstanding along the way. See e.g.:
> https://mailman.boum.org/pipermail/tails-dev/2014-April/005596.html
>
> Now, I can very well imagine having contradicted myself somewhere
> else, or another thread having lead us collectively to the vision
> you're referring to, that I really can't remember.
Fair enough, thanks for updating my memory.
>>> 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.
>
> Agreed.
>
>>> 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...
>
> I don't think that the "only one tool for one job" argument is very
> relevant here. First, because the scenario you're replying to is about
> adding support for the TrueCrypt on-disk format to existing tools
> (GNOME Disks and friends). Secondly, because GNOME Disks and friends
> support more than one filesystem, more than one partition table
> format, etc., so supporting another on-disk encryption format is no
> big deal as I see it. Third, because the same reason that led us to
> document keyringer (basically: it doesn't solve _exactly_ the same use
> case as KeePassX) applies just fine here too.
I agree with you. I overplayed the "only one tool for one job" argument.
I was mostly not seeing ourselves advertising TrueCrypt as an
alternative to LUKS for general disk encryption ("you can use LUKS or
use TrueCrypt").
> Now, regarding the "advertising" part: yes, I think it should be
> documented (if at all) only for interoperability purposes.
> I'm writting "if at all" because people who want to use TrueCrypt
> volumes can create them on their other OS, and then all we need on our
> side is documenting how to unlock/open such volumes in Tails. The good
> news is that we already have a perfect place for that, which is
> doc/encryption_and_privacy/truecrypt :)
Right, so if we ever get graphical tools to do that we'll replace the
command line instructions with graphical instructions.
>>> 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 :)
>
> I'm not lost anymore since you clarified that you're not aware of good
> reasons why we should get rid of the TrueCrypt on-disk format.
> The path forward seems pretty clear to me again.
Then I'll let you create tickets or send emails upstream accordingly,
because the underlying technicalities are not clear enough to me.
--
sajolida
