Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCryp…

Delete this message

Reply to this message
Author: ghostlands
Date:  
To: tails-dev, sajolida
New-Topics: Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Subject: Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Hi, random lurker speaking up here with a question.

I don't mean to distract from the topic, but regarding
interoperability, what about FreeOTFE? It's source was available,
and someone else has picked it up and forked it on GitHub as
DoxBox: https://github.com/t-d-k/doxbox

Is there any consideration underway to support this solution and
its development? I know it wouldn't solve all of the issues with
the absence of TrueCrypt, but it certainly would broaden the
relevance of LUKS.

gl



On Thu, 02 Apr 2015 19:39:15 +0000 "sajolida"
<sajolida@???> wrote:
>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
>Tails-dev@???
>https://mailman.boum.org/listinfo/tails-dev
>To unsubscribe from this list, send an empty email to Tails-dev-
>unsubscribe@???.