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 + sajolida sajol...@pimienta.org 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@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
ghostla...@hush.com: On Sun, 05 Apr 2015 20:01:44 + sajolida sajol...@pimienta.org wrote: 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. ghostla...@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. How's this? :) No interest in my DoxBox suggestion/question, though? I'm curious if anyone here thinks this is code worth using or even just paying attention to. It is literally the only serious LUKS implementation for Windows, it seems possibly important. Hi, and sorry for not answering better your previous email. I knew about FreeOFTE but I didn't knew it was taken over by doxbox, thanks for that info. Indeed, I think having better LUKS tools in other operating systems would also be a valid way to go. Doxbox seems to be quite fresh still but active. I hope it lives long. Ah, and we would also need an implementation for Mac OS X. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 05 Apr 2015 20:01:44 + sajolida sajol...@pimienta.org wrote: 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. ghostla...@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 How's this? :) No interest in my DoxBox suggestion/question, though? I'm curious if anyone here thinks this is code worth using or even just paying attention to. It is literally the only serious LUKS implementation for Windows, it seems possibly important. ghostlands -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wsBcBAEBAgAGBQJVNfQAAAoJEJRqj8F0y8k5o0IH/3FTuY/Vg2vyDQdfjfxD9f63JPNm nT+a+K07/amYz7WSVKCR/ZjvrUXeKxZ1TWpt7zZwsw1JTTbW0h48S171iyqFNg/UAJ20 Ghs5KIi1mV+xxXxKxxJs3lfoitT4NlUx5evgEWR8deJpy8b3Q3qq1O+8vZVh99dvrhec JQj0YlL7qxZ36WJK5NZHsUSxuVtNNOlccmTn2Im3i4RU76coLyzBASu7Hb8L26sj/ZNb ye2NIOSE0cuwibBbIpkeK5ZhBRkVw6YqZpqpS0SR+QADkw2JxZ/G31rCePIRsDykB5vW Rb506Rj4gmlVpRfgLJ5OIogAQwoOXv50N/3LVXvpr6k= =1aTn -END PGP SIGNATURE- ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
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
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
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. ghostla...@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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Jasper: On Fri, 20 Mar 2015 12:40:07 + sajolida sajol...@pimienta.org wrote: intrigeri: Jasper wrote (19 Mar 2015 23:46:09 GMT) : 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? Sure, the relevant parts would be: * Storing sensitive documents * Opening the persistent volume from other operating systems I'll create a ticket for that. 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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Jasper wrote (22 Mar 2015 19:23:59 GMT) : 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. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
On Fri, 20 Mar 2015 12:40:07 + sajolida sajol...@pimienta.org wrote: intrigeri: Jasper wrote (19 Mar 2015 23:46:09 GMT) : 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 signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
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 signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
On Fri, 20 Mar 2015 08:35:42 +0100 intrigeri intrig...@boum.org wrote: Jasper wrote (19 Mar 2015 23:46:09 GMT) : 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 signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Jasper wrote (19 Mar 2015 23:46:09 GMT) : 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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Hi, 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? (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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
intrigeri: Jasper wrote (19 Mar 2015 23:46:09 GMT) : 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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
intrigeri: Hi, sajolida wrote (10 Mar 2015 16:08:41 GMT) : 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. 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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
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 intrigeri intrig...@boum.org wrote: Hi, sajolida wrote (10 Mar 2015 16:08:41 GMT) : 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, signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Hi, sajolida wrote (10 Mar 2015 16:08:41 GMT) : 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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] GUI for encrypted volumes from LUKS/TrueCrypt container files
Jasper: hello everyone, Hi 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. 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 there wont be too much work involved: 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 ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
