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

Delete this message

Reply to this message
Autor: u
Data:  
A: The Tails public development discussion list, ghostlands
Assumptes vells: Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Assumpte: Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Hi,

> 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


Looks like this would be Windows only, so I can't see the relevance of
this tool for Tails.

> 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.


Cheers
u.


>
> 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