[Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files

Post by Jasper
hello everyone,

Hi Jasper,

Post by Jasper
I'm the developer of a little graphical application that helps with
creating and using LUKS and TrueCrypt container files called luckyLUKS.
It was brought to life to offer an equivalent to the Windows TrueCrypt
application for some friends that are not too keen on using the command
line. luckyLUKS follows a keep-it-simple philosophy that aims to keep
users from shooting themselves in the foot when typing commands with
administrative privileges. You can find more information and a little
screencast on the homepage: https://github.com/jas-per/luckyLUKS

Thanks for the link and for the proposal.

We had been trying to get rid of TrueCrypt for many reasons and for
years before we actually managed to do so in Tails 1.2.1. So I'm pretty
sure that we don't want to make it easier for people to go on using it.

And, for LUKS devices, we are happy with the GUI interface offered by
GNOME Disks.

Post by Jasper
I'm also looking for a sponsor to get the application into Debian,
would be great if you could help finding a debian developer who might
be interested. I'd like to maintain the package myself so hopefully
https://mentors.debian.net/package/luckyluks
Reviews welcome!

I'm not so much into Debian myself, so I'll let others answer this part.

--
sajolida

intrigeri

2015-03-19 18:48:15 UTC

Hi,

Post by sajolida
We had been trying to get rid of TrueCrypt for many reasons and for
years before we actually managed to do so in Tails 1.2.1. So I'm pretty
sure that we don't want to make it easier for people to go on
using it.

I think you're mixing up "using the TrueCrypt software" and "using
TrueCrypt volumes". Let's clarify.

We stopped shipping the TrueCrypt software for good reasons, but we
still support TrueCrypt volumes (as you know, since you wrote part of
the documentation). For interoperability purposes (not mentioning the
"hidden volume" feature, which I'm less sure about), IMO it would be
good to support such volumes graphically.

Now, introducing yet another frontend would feel inconsistent IMO
(especially one that also supports LUKS, that we already have good
support for) => I believe the needed support should be added to
udisks first (that's #6337), so that GNOME Disks can support it as
well some day, in the very same interface as LUKS :)

Cheers,

--
intrigeri

Jasper

2015-03-19 23:46:09 UTC

sorry, intented to drop in on irc for a while, but being a bit busy atm.
spot on with the clarification between the TrueCrypt application and the
encryption format, let me in turn clarify the difference between
encrypted partitions and encrypted containers

tltr:
partions put another level of abstraction between user and use case - a
difficulty that a vast majority of the users wont be able to handle
unless you provide first class (graphical) support .. see the evolution
of installers for linux distros as an example: partitioning is so much
easier nowadays but it is still the main hurdle for people to give
linux a try. most users dont fully understand partitions and are afraid
to break things

from the users perspective, the TrueCrypt format is similar to FAT32 -
probably the worst of all widespread disk encryption formats (especially
if you dont use keyslots) but also the only one thats accessible from
windows, osx and linux alike. odds are this wont change anytime soon.
regular users wont be able to use TrueCrypt containers/partitions
without a GUI - your documentation on how to use containers on the
command line is fine, but only for the ~5% of users that have to
confidence to actually use the command line

while I share your concerns about alienating users with too many
different GUIs, right now you only (graphically) support luks
partitions, not luks containers. what probably adds to the confusion is
that the TrueCrypt format is rarely used with partitions (although you
can do that as well) but mostly with containers. the name might sound a
bit more general but luckyluks is only about luks containers - since
luks partitions are already covered eg by udisks2/gnome disks

advantages of encrypted containers:
-> No need to deal with partition table wizardry when creating an
encrypted container, you basically create a file on a harddrive, it
doesn't matter if its an internal one or an external usbstick etc..
-> Backup is straightforward as well, just copy the file somewhere else
-> sharing confidential information: again, copy the container
file. similar to gpg encrypted archives but easier to handle:
unlock/view or modify data/lock again
-> You can easily add some encrypted private data to an unencrypted
external harddrive without repartitioning
-> Lots of users are already quite familiar with all this, because
their first touch with data encryption has been TrueCrypt which uses
the encrypted container approach

advantages of encrypted partitions:
-> partition tables can be scanned automatically, so integration into
automounting tools can be possible

there is support for encrypted (luks, encfs) partitions in automounting
tools because it is straightforward to implement. unfortunately with
encrypted containers/partitons using the TrueCrypt format this is not
possible. they can only be verified as such if you successfully open
them with your password. btw, that would probably be the answer if
somebody from the udisks team finally finds some time to respond to the
bugreport from 2013 you've been referring to

hope you dont feel like I want to sell you a tool just because I put a
bit of effort into writing it ;) if I'd like to promote anything it is
the reduced complexity that encrypted containers offer for casual
users. maybe give it a thought - happy to discuss things

cheers,
jasper

On Thu, 19 Mar 2015 19:48:15 +0100

Post by intrigeri
Hi,

Post by sajolida
We had been trying to get rid of TrueCrypt for many reasons and for
years before we actually managed to do so in Tails 1.2.1. So I'm
pretty sure that we don't want to make it easier for people to go on
using it.

I think you're mixing up "using the TrueCrypt software" and "using
TrueCrypt volumes". Let's clarify.
We stopped shipping the TrueCrypt software for good reasons, but we
still support TrueCrypt volumes (as you know, since you wrote part of
the documentation). For interoperability purposes (not mentioning the
"hidden volume" feature, which I'm less sure about), IMO it would be
good to support such volumes graphically.
Now, introducing yet another frontend would feel inconsistent IMO
(especially one that also supports LUKS, that we already have good
support for) => I believe the needed support should be added to
udisks first (that's #6337), so that GNOME Disks can support it as
well some day, in the very same interface as LUKS :)
Cheers,

intrigeri

2015-03-20 07:35:42 UTC

right now you only (graphically) support luks partitions, not
luks containers.

I've not checked in Tails/Wheezy, but FYI Jessie's GNOME Disks has an
"Attach disk image" function.

Cheers,

--
intrigeri

sajolida

2015-03-20 12:40:07 UTC

right now you only (graphically) support luks partitions, not
luks containers.

I've not checked in Tails/Wheezy, but FYI Jessie's GNOME Disks has an
"Attach disk image" function.

Thanks for sharing your concerns regarding partitions vs containers. I
think that they make a lot of sense and I didn't think about that in
this way before.

Still, I would need to mature that idea in my head before being sure
that this is a desirable feature in the context of Tails.

Because, for example, using containers imply have other unencrypted data
on the same partition, right? So that would probably encourage mixing up
data from different identities on the same disk. Then this data would be
equally available to Tails (and its possible targeted attacks) and could
deanonymise you. Of course, you can also do that with LUKS partitions...
but what I want to say is that your idea that containers makes it easier
to manipulate encrypted files for the user might actually make things
more complicated conceptually in the context of Tails.

--
sajolida

Jasper

2015-03-22 19:36:20 UTC

On Fri, 20 Mar 2015 12:40:07 +0000

right now you only (graphically) support luks partitions, not
luks containers.

I've not checked in Tails/Wheezy, but FYI Jessie's GNOME Disks has
an "Attach disk image" function.

Thanks for sharing your concerns regarding partitions vs containers. I
think that they make a lot of sense and I didn't think about that in
this way before.
Still, I would need to mature that idea in my head before being sure
that this is a desirable feature in the context of Tails.
Because, for example, using containers imply have other unencrypted
data on the same partition, right? So that would probably encourage
mixing up data from different identities on the same disk. Then this
data would be equally available to Tails (and its possible targeted
attacks) and could deanonymise you. Of course, you can also do that
with LUKS partitions... but what I want to say is that your idea that
containers makes it easier to manipulate encrypted files for the user
might actually make things more complicated conceptually in the
context of Tails.

thank you for clarifying the conceptual approach of Tails in regard to
persistence. I agree that providing the least possible amount of
information in case of a successful attack is the only sane way if you
consider the giant target that Tails paints on its back. as you said,
the tradeoff is the same with partitions .. I read your instructions on
using/creating encrypted volumes but should have also read the explicit
warnings to be found in the instructions on persistence. what about
having a link to those warnings from the using/creating encrypted
volumes page as well?

I have to admit, the only usecase I evaluated Tails for might be a bit
specific: secure communication between a lawyer friend of mine and some
of his clients. he thought about giving them Tails on a usb-stick
preconfigured with pgp and otr messaging. obviously working with
documents that will deanonymise you is needed in this case. probably a
clean separation between the communication layer and the workspace
using a preconfigured whonix environment will be a approach more suited
for this usecase. thankfully computers are a lot less expensive these
days..

anyways, thanks for clarification and the effort you put into Tails -
very much appreciated!

cheers,
jasper

sajolida

2015-03-31 08:46:39 UTC

Post by Jasper
On Fri, 20 Mar 2015 12:40:07 +0000

right now you only (graphically) support luks partitions, not
luks containers.

I've not checked in Tails/Wheezy, but FYI Jessie's GNOME Disks has
an "Attach disk image" function.

Thanks for sharing your concerns regarding partitions vs containers. I
think that they make a lot of sense and I didn't think about that in
this way before.
Still, I would need to mature that idea in my head before being sure
that this is a desirable feature in the context of Tails.
Because, for example, using containers imply have other unencrypted
data on the same partition, right? So that would probably encourage
mixing up data from different identities on the same disk. Then this
data would be equally available to Tails (and its possible targeted
attacks) and could deanonymise you. Of course, you can also do that
with LUKS partitions... but what I want to say is that your idea that
containers makes it easier to manipulate encrypted files for the user
might actually make things more complicated conceptually in the
context of Tails.

Sure, the relevant parts would be:

* Storing sensitive documents
* Opening the persistent volume from other operating systems

I'll create a ticket for that.

Post by Jasper
I have to admit, the only usecase I evaluated Tails for might be a bit
specific: secure communication between a lawyer friend of mine and some
of his clients. he thought about giving them Tails on a usb-stick
preconfigured with pgp and otr messaging. obviously working with
documents that will deanonymise you is needed in this case. probably a
clean separation between the communication layer and the workspace
using a preconfigured whonix environment will be a approach more suited
for this usecase. thankfully computers are a lot less expensive these
days..

I think that Tails with a preconfigured persistence would work fine in
the case as well. They can store their sensitive documents in the
persistent volume. The only thing they should be careful about is to not
mix other documents from other identities or facets of their lives in
there, and not open the persistent volume from another operating system.

--
sajolida

Jasper

2015-03-22 19:23:59 UTC

On Fri, 20 Mar 2015 08:35:42 +0100

right now you only (graphically) support luks partitions, not
luks containers.

I've not checked in Tails/Wheezy, but FYI Jessie's GNOME Disks has an
"Attach disk image" function.

aye, the disk utils code is were you traditionally look for
"specifications" when it comes to new udisks dbus calls. never managed
to mount an encrypted file with write access though, but that might as
well be a udev config issue in debian (dont have a recent fedora vm for
testing)

whether creating a new encrypted luks "image" with udisks is possible
today remains a mistery until it eventually gets supported by gnome
disks. don't bother checking wheezy since it uses the abandoned
udisks-daemon as backend, jessie is running udisksd from udisks2

cheers,
jasper

intrigeri

2015-03-29 11:27:33 UTC

Post by Jasper
aye, the disk utils code is were you traditionally look for
"specifications" when it comes to new udisks dbus calls. [...]
whether creating a new encrypted luks "image" with udisks is possible
today remains a mistery until it eventually gets supported by gnome
disks.

I've found the UDisks documentation quite helpful (although sometimes
lacking clarity or details) when porting stuff to UDisks2 recently:

http://udisks.freedesktop.org/docs/latest/

The Format method from org.freedesktop.UDisks2.Block allows creating
encrypted filesystems, and in theory it should work on loop devices
as well. I've not tried this myself, though.

sajolida

2015-03-20 12:34:35 UTC

Post by intrigeri
Hi,

I think you're mixing up "using the TrueCrypt software" and "using
TrueCrypt volumes". Let's clarify.

I didn't miss that but I probably explained myself not clearly enough. 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).

Our documentation was conceived as a migration path -- we provide people
with instructions to move their data from TrueCrypt to LUKS -- and not
as a way of going on using TrueCrypt encryption forever. That's why I
think that having a graphical interface to do that is counterproductive;
or at least we shouldn't put effort into it ourselves.

--
sajolida

intrigeri

2015-03-20 23:12:08 UTC

Hi,

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?

(That's *not* a rhetorical question -- seriously, I've no idea.
There were issues with "hidden" volumes, but IIRC most of them either
don't apply in Tails, or were implementation problems more than
weaknesses in the on-disk format. I didn't look into this recently, so
it's entirely possible that I'm mistaken.)

Our documentation was conceived as a migration path -- we provide people
with instructions to move their data from TrueCrypt to LUKS -- and not
as a way of going on using TrueCrypt encryption forever.

Indeed.

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)

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.

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?

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

Cheers,

--
intrigeri

Jasper

2015-03-22 19:18:46 UTC

Post by intrigeri
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.)

if you want to ease your mind, all information needed regarding both
on-disk formats are to be found in the cryptsetup wiki[1][2]. in short:
on most systems LUKS with default settings offers a bit better
protection against brute force/dictionary attacks on low entropy
passphrases. the main difference is TrueCrypt fancying obscurity while
LUKS is providing an unencrypted header. other than that its just a
different combination of well known crypto - its the implementation
that matters, the format itself seems alright. more certainty after the
results of a complete crypto audit will finally be available this
spring[3]

regarding dbus calls to udisks for TrueCrypt support via cryptsetup:
imho this doesn't help too much unless your aim is to stall development
in userspace even further. from the remains of TrueCrypt another
slightly different on-disk format has been established already
(VeraCrypt, support will be in cryptsetup 1.7) more interesting are
developments like TOTP authentication.[4] recreating the cryptsetup api
on top of dbus/udisks is of course possible .. a much more flexible
approach would be controlled access to the device mapper from userspace
(see [5] and the linked discussion from dm-devel) since udisks and
device mapper are very close friends at redhat I'd be eager to hear the
pong to your ping - this is not rhetorical either ;)

cheers,
jasper

[1]https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
[2]https://code.google.com/p/cryptsetup/wiki/TrueCryptOnDiskFormat
[3]https://cryptoservices.github.io/fde/2015/02/18/truecrypt-phase-two.html
[4]http://tools.ietf.org/html/rfc6238
[5]https://code.google.com/p/cryptsetup/issues/detail?id=208

sajolida

2015-04-01 11:08:49 UTC

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.

Post by intrigeri
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
- 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.

Post by intrigeri
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.

Post by intrigeri
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...

Me too :)

--
sajolida

sajolida

2015-04-05 20:02:09 UTC

I'm replacing this in the thread it belongs. ghostlands, please do
"Reply" to this email if you want to stay in the loop.

PS: And please reply inline (below the quote) as we usually do.

Post by g***@hush.com
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.

Right, if we're left with interoperability as the main reason to stick
with the TrueCrypt disk format, then we might as well look at this
option the other way around and advertise tools to open LUKS on other
operating systems.

--
sajolida

intrigeri

2015-04-06 08:22:46 UTC

Hi,

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.

Post by sajolida
but I have no strong argument against TrueCrypt on-disk
format as such myself.

Thanks for clarifying!

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.

Agreed.

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

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

sajolida

2015-04-06 14:06:27 UTC

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

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.

Agreed.

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

Post by intrigeri
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.

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

intrigeri

2015-04-06 15:01:02 UTC

Post by sajolida
Then I'll let you create tickets or send emails upstream accordingly,

Done 1.5 year ago:

https://labs.riseup.net/code/issues/6337
https://bugs.freedesktop.org/show_bug.cgi?id=70164

:)

@the_one_of_us_who'll_attend_GUADEC: please add this to your
mission file.

g***@hush.com

2015-04-05 14:23:38 UTC

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"

I think that our long-term objective is to have people move out

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

Post by intrigeri
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.

Post by intrigeri
Ideally we'd like to be able to fully replace TrueCrypt volumes

(I'm

Post by intrigeri
assuming that I'm missing information that makes you think we

should)

Post by intrigeri
with something else, but nothing equivalent exists yet. Sadly,

I'm not

Post by intrigeri
aware of any plan (let alone serious effort) towards making this
- inter-operability (which I'm tempted to disregard as a

dangerous

Post by intrigeri
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

Post by intrigeri
fully give up proprietary software will just be forced to

either

Post by intrigeri
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

Post by intrigeri
still people want that and AFAIK there's nothing even

approaching

Post by intrigeri
it, be it in terms of peer-review of existing production-

quality

Post by intrigeri
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.

Post by intrigeri
With this in mind, supporting the TrueCrypt on-disk format (even
minimally) still makes sense for the time being IMO. I doubt

we'll

Post by intrigeri
actively patch out the corresponding code from cryptsetup, so I

take

Post by intrigeri
for granted that we'll keep this support in Tails as long as
cryptsetup has it.

Agreed.

Post by intrigeri
We had good reasons to get rid of the TrueCrypt software itself,

but

Post by intrigeri
no existing GUI for TrueCrypt volumes is satisfying right now,

in the

Post by intrigeri
context of Tails.
Now, of course a CLI-only interface isn't encouraging for Tails

users

Post by intrigeri
to go on using TrueCrypt volumes. This has both advantages (as
a long-term strategy, hopefully it'll encourage people to either

fully

Post by intrigeri
replace TrueCrypt volumes with a better design), and drawbacks

(until

Post by intrigeri
our fancy long-term plans are made real by $someone $some_day,

Tails

Post by intrigeri
users have the choice between using something we claim we don't

really

Post by intrigeri
support, with poor usability, and doing something even worse).
So, the question I'm coming to is: assuming there *was*

satisfying GUI

Post by intrigeri
support for the TrueCrypt on-disk format (in GNOME Disks,

Nautilus,

Post by intrigeri
etc.), would we want to explicitly support that, or still depict

it as

Post by intrigeri
a suboptimal feature, and call it unsupported because we think

Post by intrigeri
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...

Post by intrigeri
In other words: how hard should we push for adding support for

the

Post by intrigeri
TrueCrypt on-disk format in udisks and friends? (Until 15

minutes ago,

Post by intrigeri
I was convinced that it was the way to go, and prepared to go

ping the

Post by intrigeri
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
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to Tails-dev-

2015-07-01 15:20:28 UTC

Hi,

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

Post by g***@hush.com
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.

Post by g***@hush.com
gl
On Thu, 02 Apr 2015 19:39:15 +0000 "sajolida"

I think that our long-term objective is to have people move out

using TrueCrypt technologies in general (be it the software,

the