Hi,
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.
> but I have no strong argument against TrueCrypt on-disk
> format as such myself.
Thanks for clarifying!
>> 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.
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 :)
>> 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.
Cheers,
--
intrigeri
