Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.06 01.56, Bill Cox wrote: I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? It's unclear that there is one. I'd feel far happier recommending a (new, continued development, audited, etc.) version of Truecrypt with no deniability features at all. Using the features in such a way that you don't leave traces of the container has always been really, really difficult -- if you read the docs page on what's required to evade forensic detection, it should be pretty clear how unsuitable this feature is for regular users. Yes, some of those might be removable with significant developer effort, but I'm not sure why that's worth it, given the larger issues. I think we who are trying to keep TrueCrypt alive could use your advice. Happy to chat more. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQyydsACgkQQwkE2RkM0wpV/QD/R+Iu4JCX/sp9/gOA+XF7oyts p29Jw9tl3mT7Jbq2VvEBAJjUR+HB0Qmgfs/gFuHdhx1sJWdHa/qGpAg6xIU2Ouvl =jcFs -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Hi Bill,Just keep in mind that there hasn't been a single citation of any reliable research or human rights reports about deniability in this thread. So if you are looking for advice specifically on whether the system should even include deniability, you're basically working off an opinion of a researcher based on accounts she heard but cannot repeat to you. Best,Jonathan On Monday, October 6, 2014 12:56 PM, Eleanor Saitta e...@dymaxion.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.06 01.56, Bill Cox wrote: I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? It's unclear that there is one. I'd feel far happier recommending a (new, continued development, audited, etc.) version of Truecrypt with no deniability features at all. Using the features in such a way that you don't leave traces of the container has always been really, really difficult -- if you read the docs page on what's required to evade forensic detection, it should be pretty clear how unsuitable this feature is for regular users. Yes, some of those might be removable with significant developer effort, but I'm not sure why that's worth it, given the larger issues. I think we who are trying to keep TrueCrypt alive could use your advice. Happy to chat more. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQyydsACgkQQwkE2RkM0wpV/QD/R+Iu4JCX/sp9/gOA+XF7oyts p29Jw9tl3mT7Jbq2VvEBAJjUR+HB0Qmgfs/gFuHdhx1sJWdHa/qGpAg6xIU2Ouvl =jcFs -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
And just to keep the discussion on topic-- I'm talking about research or reports on the benefits/drawbacks of using software in the field that has some deniability features. -Jonathan On Monday, October 6, 2014 12:56 PM, Eleanor Saitta e...@dymaxion.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.06 01.56, Bill Cox wrote: I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? It's unclear that there is one. I'd feel far happier recommending a (new, continued development, audited, etc.) version of Truecrypt with no deniability features at all. Using the features in such a way that you don't leave traces of the container has always been really, really difficult -- if you read the docs page on what's required to evade forensic detection, it should be pretty clear how unsuitable this feature is for regular users. Yes, some of those might be removable with significant developer effort, but I'm not sure why that's worth it, given the larger issues. I think we who are trying to keep TrueCrypt alive could use your advice. Happy to chat more. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQyydsACgkQQwkE2RkM0wpV/QD/R+Iu4JCX/sp9/gOA+XF7oyts p29Jw9tl3mT7Jbq2VvEBAJjUR+HB0Qmgfs/gFuHdhx1sJWdHa/qGpAg6xIU2Ouvl =jcFs -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Mon, Oct 06, 2014 at 05:56:59PM +0100, Eleanor Saitta wrote: On 2014.10.06 01.56, Bill Cox wrote: I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? It's unclear that there is one. I'd feel far happier recommending a (new, continued development, audited, etc.) version of Truecrypt with no deniability features at all. Using the features in such a way that you don't leave traces of the container has always been really, really difficult -- if you read the docs page on what's required to evade forensic detection, it should be pretty clear how unsuitable this feature is for regular users. Yes, some of those might be removable with significant developer effort, but I'm not sure why that's worth it, given the larger issues. I think one of the challenges here is that, to the extent that deniable crypto-systems are used and understood in the real world, the switch from we will use our ingenious forensic tools to detect your subterfuge to we will beat you up until you tell us the password is prompted by Truecrypt's presence and notoriety, rather than any feature of the software. By that, I mean that the one data point I have is talking to activists who say that if their laptop or devices are inspected, having Tor and Truecrypt visibly installed is a signal for further interrogation. So we're really in a position where hiding the application from casual inspection is more important than the cryptosystem, because the cryptosystem is going to be bypassed by rubberhose cryptoanalysis once noticed. Security developers hate this, I think, because hiding an application's traces on a standard OS is an endless task with no guarantee that we haven't left some sort of fingerprint which is trivially detectable with the right kind of tool. This is one of the reasons why practical advice seems to be moving more towards the have a secure device which you hide rather than use secure software on your visible everyday device. A hidden, cordoned device allows us to make a much stronger assertion about the safety of its contents, and a much clearer moment to describe when its contents may be breached. Under this design, deniability really isn't something you implement in software. Deniability comes from physically hiding the device. There's no deniability *within* Truecrypt because Truecrypt use itself is already perceived as an indication of guilt. d. I think we who are trying to keep TrueCrypt alive could use your advice. Happy to chat more. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Deniability is not inherently better. Of course it has advantages. But a world that only had deniable cryptography would be worse than one which also had systems like TrueCrypt whose presence is not hidden. It makes no sense to argue that an improved version of TrueCrypt is no better if it’s not deniable. Maybe there will be a rubber hose attack, maybe not. Many attackers are not in a position to do that. And deniability has costs which may lower resistance to other types of attack. On October 6, 2014 at 11:54:03 AM, Danny O'Brien (da...@eff.org) wrote: On Mon, Oct 06, 2014 at 05:56:59PM +0100, Eleanor Saitta wrote: On 2014.10.06 01.56, Bill Cox wrote: I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? It's unclear that there is one. I'd feel far happier recommending a (new, continued development, audited, etc.) version of Truecrypt with no deniability features at all. Using the features in such a way that you don't leave traces of the container has always been really, really difficult -- if you read the docs page on what's required to evade forensic detection, it should be pretty clear how unsuitable this feature is for regular users. Yes, some of those might be removable with significant developer effort, but I'm not sure why that's worth it, given the larger issues. I think one of the challenges here is that, to the extent that deniable crypto-systems are used and understood in the real world, the switch from we will use our ingenious forensic tools to detect your subterfuge to we will beat you up until you tell us the password is prompted by Truecrypt's presence and notoriety, rather than any feature of the software. By that, I mean that the one data point I have is talking to activists who say that if their laptop or devices are inspected, having Tor and Truecrypt visibly installed is a signal for further interrogation. So we're really in a position where hiding the application from casual inspection is more important than the cryptosystem, because the cryptosystem is going to be bypassed by rubberhose cryptoanalysis once noticed. Security developers hate this, I think, because hiding an application's traces on a standard OS is an endless task with no guarantee that we haven't left some sort of fingerprint which is trivially detectable with the right kind of tool. This is one of the reasons why practical advice seems to be moving more towards the have a secure device which you hide rather than use secure software on your visible everyday device. A hidden, cordoned device allows us to make a much stronger assertion about the safety of its contents, and a much clearer moment to describe when its contents may be breached. Under this design, deniability really isn't something you implement in software. Deniability comes from physically hiding the device. There's no deniability *within* Truecrypt because Truecrypt use itself is already perceived as an indication of guilt. d. I think we who are trying to keep TrueCrypt alive could use your advice. Happy to chat more. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
This is not directed to anyone in particular. But, come on, everyone, let's have a respectful and constructive conversation. There's no need to get snippy. Thanks, Yosem One of the moderators On Sun, Oct 5, 2014 at 3:44 PM, Greg g...@kinostudios.com wrote: Dear Rich, On Oct 4, 2014, at 3:50 AM, Rich Kulawiec r...@gsp.org wrote: I'm not misunderstanding it. I didn't bother to read it Those two statements seem to be in conflict to me, as you are next making assumptions about what sorts of limits it puts on peer review. You use the words legally constrain the reviewers but neglect to mention how or why. That is not unimportant. It would be like me saying that America is legally constraining me but neglecting to mention that they are legally constraining me from running somebody over with a car. In or out of the pool. You wanna be closed source? Go for it. But please, stop disengenously pretending to be open source when you're clearly not. So far the only disingenuous language has been coming from you. We have been explicit in stating that we are not open source [1,2], and yet you are accusing us of doing so. That is libel and/or slander. Please stop. Kind regards, Greg Slepak [1] https://www.taoeffect.com/blog/2013/09/espionage-3-now-open-source-for-professionals/ (we preserved the URL to prevent broken internet links, but changed the title and added edits in bold) [2] https://www.espionageapp.com (read the section on source code available) -- Please do not email me anything that you are not comfortable also sharing with the NSA. This is dragging out, so I'm going to try to be brief. On Fri, Oct 03, 2014 at 06:07:36PM -0700, Greg wrote: You may also be misunderstanding our NDA. I'm not misunderstanding it. I didn't bother to read it, because the mere fact that it exists is the problem. People who are serious about open source and peer review of code do not limit peer review, nor attempt to legally constrain the reviewers, nor try to cherry-pick the reviewers based on perceived expertise or personal qualities. In or out of the pool. You wanna be closed source? Go for it. But please, stop disengenously pretending to be open source when you're clearly not. ---rsk p.s. In re: [...] we want to do our best to keep the software in the hands of honest, trustworthy folks [...] -- you've got to be kidding. I *hope* you're kidding. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Oct 5, 2014, at 3:48 PM, Yosem Companys compa...@stanford.edu wrote: This is not directed to anyone in particular. But, come on, everyone, let's have a respectful and constructive conversation. There's no need to get snippy. I agree, and sorry if my email came off that way. Let me try to improve the tone a bit: I *want* to open source Espionage completely, and philosophically I find myself agreeing with many of Rich's comments. There are currently at least two obstacles to making that happen: 1. If we released all of our code for Espionage right now, it would still not be 100% source because it relies on Apple's sparsebundles, which aren't even source available, but completely closed source. They wouldn't even reply back to an encrypted email I sent to them regarding the matter. So perhaps first we should find a suitable alternative. 2. Those interested in using an open source Espionage do not want to see it face the same fate that TrueCrypt faced. One of the most insightful comments I've seen as to why TC's developers abandoned the project was those who were auditing it received more compensation for their audit than the TC developers received in donations over the lifetime of the entire project. If that is true (and I suspect it is), I can see how that would be incredibly disheartened and demoralizing. Therefore, we must find a way to open source it in a way that (1) actually is open source, and (2) does not kill the project in the process. We have some ideas on how to do that, but it is not something that can happen overnight. We are working on it though. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. Thanks, Yosem One of the moderators On Sun, Oct 5, 2014 at 3:44 PM, Greg g...@kinostudios.com wrote: Dear Rich, On Oct 4, 2014, at 3:50 AM, Rich Kulawiec r...@gsp.org wrote: I'm not misunderstanding it. I didn't bother to read it Those two statements seem to be in conflict to me, as you are next making assumptions about what sorts of limits it puts on peer review. You use the words legally constrain the reviewers but neglect to mention how or why. That is not unimportant. It would be like me saying that America is legally constraining me but neglecting to mention that they are legally constraining me from running somebody over with a car. In or out of the pool. You wanna be closed source? Go for it. But please, stop disengenously pretending to be open source when you're clearly not. So far the only disingenuous language has been coming from you. We have been explicit in stating that we are not open source [1,2], and yet you are accusing us of doing so. That is libel and/or slander. Please stop. Kind regards, Greg Slepak [1] https://www.taoeffect.com/blog/2013/09/espionage-3-now-open-source-for-professionals/ (we preserved the URL to prevent broken internet links, but changed the title and added edits in bold) [2] https://www.espionageapp.com (read the section on source code available) -- Please do not email me anything that you are not comfortable also sharing with the NSA. This is dragging out, so I'm going to try to be brief. On Fri, Oct 03, 2014 at 06:07:36PM -0700, Greg wrote: You may also be misunderstanding our NDA. I'm not misunderstanding it. I didn't bother to read it, because the mere fact that it exists is the problem. People who are serious about open source and peer review of code do not limit peer review, nor attempt to legally constrain the reviewers, nor try to cherry-pick the reviewers based on perceived expertise or personal qualities. In or out of the pool. You wanna be closed source? Go for it. But please, stop disengenously pretending to be open source when you're clearly not. ---rsk p.s. In re: [...] we want to do our best to keep the software in the hands of honest, trustworthy folks [...] -- you've got to be kidding. I *hope* you're kidding. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of
Re: [liberationtech] TrueCrypt Alternatives?
On Thu, Oct 2, 2014 at 4:28 PM, Eleanor Saitta e...@dymaxion.org wrote: Field outcomes aren't about math. That's the point I'm trying to make here. The precautionary principle and a Do No Harm approach to software development are incredibly important when looking at the requirements specification of security tools intended to be used in a hostile environment. I cannot stress this strongly enough. Real-world field experience is the only reasonable and reliable guide for determining the appropriate design of security systems; anything else is at best a amateur[1]. For novel capabilities, *careful* field testing in moderate risk environments is necessary to establish a baseline. Building a real loop with existing training programs to ensure that you get field feedback when systems are used is similarly critical. Building software because it's cool is fine, as are projects we do because we believe in them, but at a certain point, there's a bar. Recommending your tools for use in the field in hostile environments is that bar. Beyond that bar, we have an ethical obligation to attempt to act in a professional manner. I am on the CipherShed project, which is working to sustain TrueCrypt while rewriting most of it. I'm working on it because it's cool. I have zero field experience. You described me quite well, I'm afraid. I really need to understand concerns about TrueCrypt. I got the game-theory thing. Bad guys keep breaking your fingers because they can't be sure you don't have more to tell. I get it. I will have an impact on the code going forward. Also, I am entirely a pragmatist. I am an engineer, not a cryptographer, and I build stuff that works in the real world. Can you explain a deniable crypto-system that fits the real world? I have enjoyed this thread so far, and I have to say, I lean towards the guy claiming real-world experience. I think we who are trying to keep TrueCrypt alive could use your advice. Bill -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Fri, Oct 03, 2014 at 10:23:09PM +, Jonathan Wilkes wrote: Hi Rich, Your footnote #1 is dubious at best. The cost of aiming peoples eyes at bugs is _not_ $0. Until it is, the free software community has a problem with too few resources chasing too many bugs. I'm not sure why you're bringing up by the cost, but I'll certainly agree with the second sentence: yes, there are too many bugs and too few people working on them. We seem to have backed into triage mode partly because of the aggregate size of the code in play, partly because of the increasing sophistication of attacks, and partly because we've all developed a lot of bad habits (including complacency). I think the past year and probably the next couple of years are going to see some major changes: I think a number of projects need to adopt an approach similar to that of OpenBSD's, [1] which is fanatical, intolerant, pedantic, demanding...and effective. But all that said, peer review remains the very best tool we have, even when it sucks, even when it isn't fast enough, even when it isn't thorough enough, even when *anything*. That's why science, law, engineering, medicine, et.al. use it: there isn't anything better. Should bash have undergone this years ago? Oh, sure. But it didn't. So the best we can do is to do it now, do it thoroughly, sweat the details, argue, test, patch and try not to repeat the error(s). And then we need to tackle all the other critical pieces of software infrastructure: postfix and freeradius, nagios and subversion, nginx and mariadb, top and stunnel -- everyone's laundry list will vary, but there are a lot of semi-visible moving parts that make up the 'net's infrastructure and no doubt many of them are languishing in vulnerable states. So: we need to get better at auditing code. We need to do more code auditing. We need to get better at writing code so that the previous two items aren't so onerous. We need to [do a bunch of other things too]. We also need to insist, without exception, that everyone put all of their work on the table for inspection. Some will choose not to acquiesce to that, and that's fine: but if/when that happens, we shouldn't expend another minute on it: dismiss and move on. As I snarkily said back when I wrote that long piece: source or GTFO. Anything that is not 100% open source can be, should be, and must be discarded immediately, with prejudice. ---rsk [1] Speaking of which, given this week's Xen vulnerability disclosure and the resulting disruption of numerous services/sites, I think it's worth citing this quote: You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. --- Theo De Raadt Seems rather prescient now, doesn't it? -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
This is dragging out, so I'm going to try to be brief. On Fri, Oct 03, 2014 at 06:07:36PM -0700, Greg wrote: You may also be misunderstanding our NDA. I'm not misunderstanding it. I didn't bother to read it, because the mere fact that it exists is the problem. People who are serious about open source and peer review of code do not limit peer review, nor attempt to legally constrain the reviewers, nor try to cherry-pick the reviewers based on perceived expertise or personal qualities. In or out of the pool. You wanna be closed source? Go for it. But please, stop disengenously pretending to be open source when you're clearly not. ---rsk p.s. In re: [...] we want to do our best to keep the software in the hands of honest, trustworthy folks [...] -- you've got to be kidding. I *hope* you're kidding. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Fri, Oct 3, 2014 at 2:50 AM, Greg g...@kinostudios.com wrote: Also, you convince me how to keep providing high quality software and support while simultaneously making Espionage completely free and open source and I will do it in a flash. Call up Red Hat and ask them about how they manage their open source Linux distribution. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Dear Natanael, Call up Red Hat and ask them about how they manage their open source Linux distribution. Oh, I am very familiar with the Red Hat model, and I respect it greatly, and am in fact pursuing something similar. Red Hat works because it is complicated, technical infrastructure software that requires a great deal of support, custom solutions, etc. That is not the market Espionage finds itself in, and so I cannot use their business model for it. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 10:44 PM, Natanael natanae...@gmail.com wrote: On Fri, Oct 3, 2014 at 2:50 AM, Greg g...@kinostudios.com wrote: Also, you convince me how to keep providing high quality software and support while simultaneously making Espionage completely free and open source and I will do it in a flash. Call up Red Hat and ask them about how they manage their open source Linux distribution. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On 10/03/2014 12:57 PM, Greg wrote: Dear Natanael, Call up Red Hat and ask them about how they manage their open source Linux distribution. Oh, I am very familiar with the Red Hat model, and I respect it greatly, and am in fact pursuing something similar. Red Hat works because it is complicated, technical infrastructure software that requires a great deal of support, custom solutions, etc. That is not the market Espionage finds itself in, and so I cannot use their business model for it. You could also do a 3-clause BSD license for the library (i.e., business logic), then separate out the GUI part and put whatever license you want on the bundle. You could even do deterministic builds of the library so that anyone can check the library inside the bundle against what they themselves can compile. That's not ideal, but it's certainly better than restricting access to the entire source. (And of course if you want to continue to do restricted access to the GUI code, that'd be even better.) What's more, any free software ideologue has the ability to try their hand at making an alternative GUI that's more user-friendly than the one you get paid directly by users to produce. (Though judging from the history and ethos of free software usability I'd say that's quite unlikely to happen.) -Jonathan Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 10:44 PM, Natanael natanae...@gmail.com mailto:natanae...@gmail.com wrote: On Fri, Oct 3, 2014 at 2:50 AM, Greg g...@kinostudios.com mailto:g...@kinostudios.com wrote: Also, you convince me how to keep providing high quality software and support while simultaneously making Espionage completely free and open source and I will do it in a flash. Call up Red Hat and ask them about how they manage their open source Linux distribution. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu mailto:compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Hi Greg. The burden of proof is on Espionage to convince people that it is safe. I can't trust it based on marketing claims alone. There is not a sufficiently detailed design document on the website, much less a battle-tested, peer-reviewed design. I don't see any reference to independent third-party audits. I can't find any indication the development team has security or crypto expertise and I cannot personally sign an NDA to view the source code. If I'm missing something or you're willing to give source access without an NDA, please let me know. Otherwise, I have to advise people to avoid Espionage. On Thu, Oct 2, 2014 at 5:50 PM, Greg g...@kinostudios.com wrote: Stating a thing does not make it true, not matter how many times it is repeated. It is not apply. It is apply. Anyone is welcome, so long as they: 1. Are software security professionals. (Nobody else matters in this context, after all.) 2. Don't work for government intelligence agencies. 3. Sign the NDA we give them, the salient points of which are enumerated on our site. They will be given a free license to Espionage. Also, you convince me how to keep providing high quality software and support while simultaneously making Espionage completely free and open source and I will do it in a flash. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Oct 3, 2014, at 12:04 PM, Steve Weis stevew...@gmail.com wrote: Hi Greg. The burden of proof is on Espionage to convince people that it is safe. I can't trust it based on marketing claims alone. There is not a sufficiently detailed design document on the website, much less a battle-tested, peer-reviewed design. And how many free opensource source encryption utilities like Espionage fit that description? None? Maybe the defunct TrueCrypt? As far as crypto goes, we are using scrypt (free/open source) [1] and Apple's disk images (100% closed source). [1] https://www.tarsnap.com/scrypt.html We're not thrilled about the Apple part. I linked to a review by @ioerror (and someone he worked with) that contains their analysis of it in the r/security link that was mentioned earlier in this thread. We are investigating ways of removing our dependence on Apple's sparsebundles. I don't see any reference to independent third-party audits. I would love to do a professional audit once we can safely afford one. In the meantime, those who would like to audit us pro-bono are welcome to so long as they sign the NDA: https://www.taoeffect.com/forum/index.php?board=14.0 BTW, does anyone here want to donate to an audit of Espionage? Cause that would be swell! (Should we start a TrueCrypt-like campaign? I'm not sure that would go over well given that we charge for it.) I can't find any indication the development team has security or crypto expertise and I cannot personally sign an NDA to view the source code. I have security expertise, but am not a cryptographer, and therefore I use existing code, like Colin Percival's scrypt. If I'm missing something or you're willing to give source access without an NDA, please let me know. Why are you unable to sign the NDA? Otherwise, I have to advise people to avoid Espionage. I'm sorry to hear that. :-( Here is a list of other software that supports deniability (but not the same kind that Espionage does) that you might want to recommend in its place: https://en.wikipedia.org/wiki/Deniable_encryption#Software Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Thu, Oct 2, 2014 at 5:50 PM, Greg g...@kinostudios.com wrote: Stating a thing does not make it true, not matter how many times it is repeated. It is not apply. It is apply. Anyone is welcome, so long as they: 1. Are software security professionals. (Nobody else matters in this context, after all.) 2. Don't work for government intelligence agencies. 3. Sign the NDA we give them, the salient points of which are enumerated on our site. They will be given a free license to Espionage. Also, you convince me how to keep providing high quality software and support while simultaneously making Espionage completely free and open source and I will do it in a flash. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Dear Jonathan, On Oct 3, 2014, at 11:41 AM, Jonathan Wilkes jancs...@yahoo.com wrote: You could also do a 3-clause BSD license for the library (i.e., business logic), then separate out the GUI part and put whatever license you want on the bundle. You could even do deterministic builds of the library so that anyone can check the library inside the bundle against what they themselves can compile. That's not ideal, but it's certainly better than restricting access to the entire source. (And of course if you want to continue to do restricted access to the GUI code, that'd be even better.) Thank you for that interesting idea! We actually do open source some of Espionage's code under liberal licenses. All of the following is used by Espionage: - https://github.com/taoeffect/TESetupAssistant - https://github.com/taoeffect/TERecord - https://github.com/taoeffect/TECommon Then there's scrypt: - https://www.tarsnap.com/scrypt.html As far as making a library, that actually is something we could do. The crypto meat of Espionage (if you ignore Apple's closed source disk images) is actually the deniability part, the way we encrypt and store several different Folder Sets in the database (which contain the passwords to individual disk images). We could open source that part, but we still cannot open source the disk image code (since we don't have access to it). So I am unsure whether it would make much of a difference to say, convince Steve Weis to recommend it. I'm curious actually, Steve, would you recommend Espionage if we open sourced the part of it that I mention above? And if so, how is that not hypocrisy? Thanks again Jonathan for the suggestion. I'd love to hear what you think about the above. Perhaps it might make sense to do this once we find a replacement for the sparsebundles? Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On 10/03/2014 12:57 PM, Greg wrote: Dear Natanael, Call up Red Hat and ask them about how they manage their open source Linux distribution. Oh, I am very familiar with the Red Hat model, and I respect it greatly, and am in fact pursuing something similar. Red Hat works because it is complicated, technical infrastructure software that requires a great deal of support, custom solutions, etc. That is not the market Espionage finds itself in, and so I cannot use their business model for it. You could also do a 3-clause BSD license for the library (i.e., business logic), then separate out the GUI part and put whatever license you want on the bundle. You could even do deterministic builds of the library so that anyone can check the library inside the bundle against what they themselves can compile. That's not ideal, but it's certainly better than restricting access to the entire source. (And of course if you want to continue to do restricted access to the GUI code, that'd be even better.) What's more, any free software ideologue has the ability to try their hand at making an alternative GUI that's more user-friendly than the one you get paid directly by users to produce. (Though judging from the history and ethos of free software usability I'd say that's quite unlikely to happen.) -Jonathan Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 10:44 PM, Natanael natanae...@gmail.com wrote: On Fri, Oct 3, 2014 at 2:50 AM, Greg g...@kinostudios.com wrote: Also, you convince me how to keep providing high quality software and support while simultaneously making Espionage completely free and open source and I will do it in a flash. Call up Red Hat and ask them about how they manage their open source Linux distribution. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Thu, Oct 02, 2014 at 05:50:08PM -0700, Greg wrote: K, thanks for the read (I read it but nothing there seems to apply, perhaps some of its points will be addressed below). I'm sorry that you feel that way; I included that link because I think the entire message applies, particularly this part: Of course the obvious answer is A, since B is more commonly known as snake oil. It's garbage. No thinking, responsible person would ever choose B, because -- absent the history and the research and the publication and everything else -- it might be the instant cure for Bieberitis, or it might be sugar pills, or it might be poison. There's no way to know. Espionage might be brilliant, beautiful, bug-free code that does exactly what it's claimed to do. Or it might be loaded with algorithmic mistakes, coding errors, security holes and back doors. There's no way to know. And the reason there is no way to know is that Tao Effect is refusing to freely/openly/completely publish the full source code, i.e.: Anyone is welcome, so long as they: 1. Are software security professionals. (Nobody else matters in this context, after all.) 2. Don't work for government intelligence agencies. 3. Sign the NDA we give them, the salient points of which are enumerated on our site. You're certainly welcome to set whatever policies you wish for your software (as is everyone). But by making this particular set of choices, you have immediately disqualified it from any further consideration, since it is not available for unconstrained peer review by arbitrary, independent third parties. (And can't be, since you've exempted anyone who doesn't meet your criteria and since anyone who signs your NDA is quite clearly no longer independent.) If you're serious about security, then you must be equally serious about independent and unlimited peer review, since -- so far -- it's the only tool we have that's been demonstrated to work in the field. It doesn't work very well sometimes (see Shellshock) [1] but it's still the best we've got. You can't have the former without the latter: it's not a sufficient condition, but it's certainly a necessary one. By the way #1, your statement (Nobody else matters in this context, after all) in point #1 is absolutely, utterly, completely wrong. Security bugs in software are identified all the time by people who are *not* software security professionals: as one of the more well-known examples, let me point out Cliff Stoll. There are of course myriad others, as everyone who has either studied the history of the field or lived through it is quite well aware. That's one of the reasons why completely open, completely unrestricted peer review is important: there's no way to know who will find something. By the way #2, in re point #2: government intelligence agencies either feel that your software is of sufficient interest to require their attention or they do not. If the latter, then they don't care. But if the former, then in all probability they already have it or will acquire it without your help or knowledge whenever they feel like troubling themselves enough to do so. ---rsk [1] Although one could argue that it *did* work in the case of Shellshock: it just took a while. And one of the things that's very clearly working right now, as I'm writing this, is that the exposure of this particular bug has triggered a massive examination of the relevant code, which in turn has spurred copious discussion, which in turn will eventually result in marked improvement, since there are now a large number of clueful, experienced, motivated eyeballs peering at bash and arguing over it. Compare/contrast this overwhelming and prompt response to this with the laconic/anemic reactions of, let's say, Adobe: Adobe Shockwave bundles Flash that's 15 months behind on security fixes http://arstechnica.com/security/2014/05/adobe-shockwave-bundles-flash-thats-15-months-behind-on-security-fixes/ or Oracle: Oracle reportedly knew of critical Java bugs under attack for 4 months http://arstechnica.com/security/2012/08/critical-java-bugs-reported-4-months-ago/ So while Shellshock has been annoying, at least it's being worked on with an appropriate sense of urgency. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Hi Rich, Your footnote #1 is dubious at best. The cost of aiming peoples eyes at bugs is _not_ $0. Until it is, the free software community has a problem with too few resources chasing too many bugs. Sitting my Debian box next to an XP box that's running Flash certainly doesn't change that. (Nor does it make the openssl library I'm running any less of a clusterfuck.) -Jonathan On Friday, October 3, 2014 5:46 PM, Rich Kulawiec r...@gsp.org wrote: On Thu, Oct 02, 2014 at 05:50:08PM -0700, Greg wrote: K, thanks for the read (I read it but nothing there seems to apply, perhaps some of its points will be addressed below). I'm sorry that you feel that way; I included that link because I think the entire message applies, particularly this part: Of course the obvious answer is A, since B is more commonly known as snake oil. It's garbage. No thinking, responsible person would ever choose B, because -- absent the history and the research and the publication and everything else -- it might be the instant cure for Bieberitis, or it might be sugar pills, or it might be poison. There's no way to know. Espionage might be brilliant, beautiful, bug-free code that does exactly what it's claimed to do. Or it might be loaded with algorithmic mistakes, coding errors, security holes and back doors. There's no way to know. And the reason there is no way to know is that Tao Effect is refusing to freely/openly/completely publish the full source code, i.e.: Anyone is welcome, so long as they: 1. Are software security professionals. (Nobody else matters in this context, after all.) 2. Don't work for government intelligence agencies. 3. Sign the NDA we give them, the salient points of which are enumerated on our site. You're certainly welcome to set whatever policies you wish for your software (as is everyone). But by making this particular set of choices, you have immediately disqualified it from any further consideration, since it is not available for unconstrained peer review by arbitrary, independent third parties. (And can't be, since you've exempted anyone who doesn't meet your criteria and since anyone who signs your NDA is quite clearly no longer independent.) If you're serious about security, then you must be equally serious about independent and unlimited peer review, since -- so far -- it's the only tool we have that's been demonstrated to work in the field. It doesn't work very well sometimes (see Shellshock) [1] but it's still the best we've got. You can't have the former without the latter: it's not a sufficient condition, but it's certainly a necessary one. By the way #1, your statement (Nobody else matters in this context, after all) in point #1 is absolutely, utterly, completely wrong. Security bugs in software are identified all the time by people who are *not* software security professionals: as one of the more well-known examples, let me point out Cliff Stoll. There are of course myriad others, as everyone who has either studied the history of the field or lived through it is quite well aware. That's one of the reasons why completely open, completely unrestricted peer review is important: there's no way to know who will find something. By the way #2, in re point #2: government intelligence agencies either feel that your software is of sufficient interest to require their attention or they do not. If the latter, then they don't care. But if the former, then in all probability they already have it or will acquire it without your help or knowledge whenever they feel like troubling themselves enough to do so. ---rsk [1] Although one could argue that it *did* work in the case of Shellshock: it just took a while. And one of the things that's very clearly working right now, as I'm writing this, is that the exposure of this particular bug has triggered a massive examination of the relevant code, which in turn has spurred copious discussion, which in turn will eventually result in marked improvement, since there are now a large number of clueful, experienced, motivated eyeballs peering at bash and arguing over it. Compare/contrast this overwhelming and prompt response to this with the laconic/anemic reactions of, let's say, Adobe: Adobe Shockwave bundles Flash that's 15 months behind on security fixes http://arstechnica.com/security/2014/05/adobe-shockwave-bundles-flash-thats-15-months-behind-on-security-fixes/ or Oracle: Oracle reportedly knew of critical Java bugs under attack for 4 months http://arstechnica.com/security/2012/08/critical-java-bugs-reported-4-months-ago/ So while Shellshock has been annoying, at least it's being worked on with an appropriate sense of urgency. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by
Re: [liberationtech] TrueCrypt Alternatives?
Dear Rich, I echo Jonathan's reply to your email. At the same time, I do feel a certain empathy and understanding of the feeling behind your words. If there was anything in your email that I came closest to agreeing with, it would be this: You can't have the former without the latter: it's not a sufficient condition, but it's certainly a necessary one. That idea of necessary but insufficient is a the strongest argument for letting others look at our code, and it is what drove me to make our source available. Now, the rest of your email, however, is simply misleading/untrue. Specifically, this accusation is untrue: And the reason there is no way to know is that Tao Effect is refusing to freely/openly/completely publish the full source code Let's break up those slashes. - freely We _are_ making our code available for _free_. - openly We _are not_ making it 100% open. - completely We _are_ making _all_ of our code available. So let's please keep this discussion honest. Give us our due credit where it is deserved, and throw criticism at us where we deserve it, but always be truthful. You may also be misunderstanding our NDA. We are not merely copy/pasting legalese boilerplate that we found somewhere. This is our NDA, and it is unique in its terms (at least I haven't see anything like it). So, on that: And can't be, since you've exempted anyone who doesn't meet your criteria and since anyone who signs your NDA is quite clearly no longer independent. Half-true. Yes, we have exempted anyone who doesn't meet our criteria, and this is because we want to do our best to keep the software in the hands of honest, trustworthy folks, for the sake of everyone who uses our software. However, those who agree to the NDA do maintain their independence. The terms _explicitely_ enumerate the following rights: You may build and release copies of Espionage using the original and unmodified source code that we send you (and all associated materials). You may not: sell, re-brand, or add anything to the copies that you distribute that was not included in the original materials that we sent you. Additional terms may apply. See full terms in the contract we send you. You may publish and document any security vulnerabilities that you find in Espionage as long as you do so in the manner specified in the agreement (see previous terms). The previous terms refer primarily to an embargo of 3 months, the purpose of which is to give us time to fix any problems found in the audit. That, again, is for the safety of everyone who uses our software. One final point that you ignored: As mentioned previously, we are incapable of open sourcing all of the crypto that Espionage uses, because it belongs to Apple. We _are_ trying to fix that by moving Espionage's architecture away from Apple's sparsebundles, but that is going to take a lot of time and research to do properly, and therefore our time is better spent doing *that*, than on figuring out how to make our code open source while avoiding TrueCrypt's fate. You want us to stay in business after all, right? We are the folks who dedicate our hours to this program. We are the ones who answer your support emails. We are the ones who implement your feature requests. We are the ones who fix Espionage when things go wrong. All of that must be paid for. Going 100% open source (say, after we find a replacement for sparsebundles) is a risk not only for us, but to everyone who uses Espionage. There is the very real risk that if we do that in a couple of months or years someone will be posting an email to this list entitled Espionage Alternatives? That is a lose-lose for everyone. We are taking the Middle Way here: making all of our code available for review, while keeping Espionage alive. Still, community feedback is valuable to us, so thank you for sharing your perspective. As soon as we see a better idea that works, we will work to implement it. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Well, to be completely honest I wouldn't use security software with a proprietary GUI myself. But I'm not most people, and it would be better for your business logic to be open source than for the whole thing to be subject to the terms you describe. -Jonathan On Friday, October 3, 2014 9:07 PM, Greg g...@kinostudios.com wrote: Dear Rich, I echo Jonathan's reply to your email. At the same time, I do feel a certain empathy and understanding of the feeling behind your words. If there was anything in your email that I came closest to agreeing with, it would be this: You can't have the former without the latter: it's not a sufficient condition, but it's certainly a necessary one. That idea of necessary but insufficient is a the strongest argument for letting others look at our code, and it is what drove me to make our source available. Now, the rest of your email, however, is simply misleading/untrue. Specifically, this accusation is untrue: And the reason there is no way to know is that Tao Effect is refusing to freely/openly/completely publish the full source code Let's break up those slashes. - freely We _are_ making our code available for _free_.- openly We _are not_ making it 100% open.- completely We _are_ making _all_ of our code available. So let's please keep this discussion honest. Give us our due credit where it is deserved, and throw criticism at us where we deserve it, but always be truthful. You may also be misunderstanding our NDA. We are not merely copy/pasting legalese boilerplate that we found somewhere. This is our NDA, and it is unique in its terms (at least I haven't see anything like it). So, on that: And can't be, since you've exemptedanyone who doesn't meet your criteria and since anyone who signs your NDA is quite clearly no longer independent. Half-true. Yes, we have exempted anyone who doesn't meet our criteria, and this is because we want to do our best to keep the software in the hands of honest, trustworthy folks, for the sake of everyone who uses our software. However, those who agree to the NDA do maintain their independence. The terms _explicitely_ enumerate the following rights: - You may build and release copies of Espionage using the original and unmodified source code that we send you (and all associated materials). You may not: sell, re-brand, or add anything to the copies that you distribute that was not included in the original materials that we sent you. Additional terms may apply. See full terms in the contract we send you. - You may publish and document any security vulnerabilities that you find in Espionage as long as you do so in the manner specified in the agreement (see previous terms). The previous terms refer primarily to an embargo of 3 months, the purpose of which is to give us time to fix any problems found in the audit. That, again, is for the safety of everyone who uses our software. One final point that you ignored: As mentioned previously, we are incapable of open sourcing all of the crypto that Espionage uses, because it belongs to Apple. We _are_ trying to fix that by moving Espionage's architecture away from Apple's sparsebundles, but that is going to take a lot of time and research to do properly, and therefore our time is better spent doing *that*, than on figuring out how to make our code open source while avoiding TrueCrypt's fate. You want us to stay in business after all, right? We are the folks who dedicate our hours to this program. We are the ones who answer your support emails. We are the ones who implement your feature requests. We are the ones who fix Espionage when things go wrong. All of that must be paid for. Going 100% open source (say, after we find a replacement for sparsebundles) is a risk not only for us, but to everyone who uses Espionage. There is the very real risk that if we do that in a couple of months or years someone will be posting an email to this list entitled Espionage Alternatives? That is a lose-lose for everyone. We are taking the Middle Way here: making all of our code available for review, while keeping Espionage alive. Still, community feedback is valuable to us, so thank you for sharing your perspective. As soon as we see a better idea that works, we will work to implement it. Kind regards,Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. What lack of awareness? How about you actually try the software before you go around insulting it and its developers? Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? If so, I'd love to see the research that you've done that justifies the feature set you've selected, because this would be a seriously amazing addition to the field (I'm completely sincere here). 95+% of the time when I see people talking about deniability, they have no direct field experience to back up their assertions of utility, and the arguments they make look exactly like yours. If you're going to contest my statement, feel free to provide reliable field data. Short of that, you're simply wrong here. You are welcome to criticize our software based on knowledge and experience that you actually have, but don't go around making up nonsense and applying said nonsense to software that you admit having not tried. So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. Again, field data or nothing. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQtWRkACgkQQwkE2RkM0wosIgD+P4NbMFYfFWk9c9oR2uP1pnWz 8FoePGWnDU9n38kEd6cA/j2ZvOtQGlUVlGnItrFBr0CFlqEK6F9srLPnZm6qKOss =3Tmh -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Truecrypt has not properly been audited. For information, Truecrypt have been audited and agreed in version 6.0a by ANSSI (French national IT Sec agency). Rapport (french only) : http://www.ssi.gouv.fr/fr/produits-et-prestataires/produits-certifies-cspn/certificat_cspn_2008_03.html 2014-10-02 18:54 GMT+05:00 Eleanor Saitta e...@dymaxion.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. What lack of awareness? How about you actually try the software before you go around insulting it and its developers? Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? If so, I'd love to see the research that you've done that justifies the feature set you've selected, because this would be a seriously amazing addition to the field (I'm completely sincere here). 95+% of the time when I see people talking about deniability, they have no direct field experience to back up their assertions of utility, and the arguments they make look exactly like yours. If you're going to contest my statement, feel free to provide reliable field data. Short of that, you're simply wrong here. You are welcome to criticize our software based on knowledge and experience that you actually have, but don't go around making up nonsense and applying said nonsense to software that you admit having not tried. So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. Again, field data or nothing. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQtWRkACgkQQwkE2RkM0wosIgD+P4NbMFYfFWk9c9oR2uP1pnWz 8FoePGWnDU9n38kEd6cA/j2ZvOtQGlUVlGnItrFBr0CFlqEK6F9srLPnZm6qKOss =3Tmh -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Oct 2, 2014, at 6:54 AM, Eleanor Saitta e...@dymaxion.org wrote: On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. There are different types of deniable encryption systems, with very _different_ deniability properties. It is therefore erroneous to make sweeping claims about all of them, *especially* when you haven't looked into the details. Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? Unlike you, I've done my homework and researched the deniability properties of encryption systems and why some are better than others. In my research, I have not found any information where X deniability system lead to Y outcome for Z reasons. If you have such research, please forward it to me, I will read it. Now, I repeat my previous question/request: How about you actually try the software before you go around insulting it and its developers? Re this: So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. I wasn't the one making game theory proofs. Go back and read again. Again, field data or nothing. If there is no useful field data, I'm afraid you'll just have to be disappointed. I can make a quip like this too though: RTFM or STFU :P Kind regards, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 6:54 AM, Eleanor Saitta e...@dymaxion.org wrote: Signed PGP part On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. What lack of awareness? How about you actually try the software before you go around insulting it and its developers? Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? If so, I'd love to see the research that you've done that justifies the feature set you've selected, because this would be a seriously amazing addition to the field (I'm completely sincere here). 95+% of the time when I see people talking about deniability, they have no direct field experience to back up their assertions of utility, and the arguments they make look exactly like yours. If you're going to contest my statement, feel free to provide reliable field data. Short of that, you're simply wrong here. You are welcome to criticize our software based on knowledge and experience that you actually have, but don't go around making up nonsense and applying said nonsense to software that you admit having not tried. So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. Again, field data or nothing. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
P.S. I would rather keep the tone of this conversation civil, and I recognize that in matching what I felt was your tone (in the previous email) it does not help accomplish that, so, sorry for that. From my POV, this is where the upset comes from: somebody asks for a TrueCrypt alternative and I reply with one that I've been pouring my heart into since 2008. I think I'm doing a good thing, being on topic, sharing useful info (albeit in a way that counts as self-promotion, but nobody else mentioned our software and we do not spend money on advertising). Then said software and developers of it are attacked by someone who didn't take the time to even understand what it does. That got to me. I will try to not let it, but I ask for your help in doing so. If you could please keep the scope of your deniability critiques to the deniability of the software you are critiquing, it would be appreciated, and it would help keep the tone of this conversation more civil. Thank you, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 12:39 PM, Greg g...@kinostudios.com wrote: On Oct 2, 2014, at 6:54 AM, Eleanor Saitta e...@dymaxion.org wrote: On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. There are different types of deniable encryption systems, with very _different_ deniability properties. It is therefore erroneous to make sweeping claims about all of them, *especially* when you haven't looked into the details. Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? Unlike you, I've done my homework and researched the deniability properties of encryption systems and why some are better than others. In my research, I have not found any information where X deniability system lead to Y outcome for Z reasons. If you have such research, please forward it to me, I will read it. Now, I repeat my previous question/request: How about you actually try the software before you go around insulting it and its developers? Re this: So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. I wasn't the one making game theory proofs. Go back and read again. Again, field data or nothing. If there is no useful field data, I'm afraid you'll just have to be disappointed. I can make a quip like this too though: RTFM or STFU :P Kind regards, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 6:54 AM, Eleanor Saitta e...@dymaxion.org wrote: Signed PGP part On 2014.10.01 04.22, Greg wrote: On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? No, incidents involving deniable encryption systems. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. What lack of awareness? How about you actually try the software before you go around insulting it and its developers? Have you done field research on the real-world outcomes of deniable encryption systems and how they shape the outcome of hostile field interrogation? If so, I'd love to see the research that you've done that justifies the feature set you've selected, because this would be a seriously amazing addition to the field (I'm completely sincere here). 95+% of the time when I see people talking about deniability, they have no direct field experience to back up their assertions of utility, and the arguments they make look exactly like yours. If you're going to contest my statement, feel free to provide reliable field data. Short of that, you're simply wrong here. You are welcome to criticize our software based on knowledge and experience that you actually have, but don't go around making up nonsense and applying said nonsense to software that you admit having not tried. So, game theory is all well and good, but you'll have to excuse me if I note that adversaries in the field that are likely to rip your fingernails off don't do game theory proofs. Again, field data or nothing. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.02 20.39, Greg wrote: There are different types of deniable encryption systems, with very _different_ deniability properties. What you're failing to see here, I think, is that your adversary is almost never a cryptographer. You adversary is a goon who likes to crush fingers, who's heard a rumor that your tool lets people hide things from him. He doesn't like it when people hide things from him. He thinks you're hiding something from him. He's going to keep crushing your fingers until you prove to him that you aren't. You don't have that many fingers left. Unlike you, I've done my homework and researched the deniability properties of encryption systems and why some are better than others. Field outcomes aren't about math. That's the point I'm trying to make here. The precautionary principle and a Do No Harm approach to software development are incredibly important when looking at the requirements specification of security tools intended to be used in a hostile environment. I cannot stress this strongly enough. Real-world field experience is the only reasonable and reliable guide for determining the appropriate design of security systems; anything else is at best a amateur[1]. For novel capabilities, *careful* field testing in moderate risk environments is necessary to establish a baseline. Building a real loop with existing training programs to ensure that you get field feedback when systems are used is similarly critical. Building software because it's cool is fine, as are projects we do because we believe in them, but at a certain point, there's a bar. Recommending your tools for use in the field in hostile environments is that bar. Beyond that bar, we have an ethical obligation to attempt to act in a professional manner. E. [1]: I mean this in the literal sense of the word, not to be in any way demeaning. There are requirements for professionalism in this field; operational field outcomes reviews are as much a requirement as proper code review, cryptoanalytic review, UX testing, QA, and good documentation. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQttVsACgkQQwkE2RkM0woj9gD/c1eOZvCwwNcElcYKb9fHrIb6 KRnpWph84MhD9N8e9e0A/0UtT0GzwTTyFbI2h3l7jPjIsqnwRn3rmKgpx8DRX7L1 =oYU9 -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Oct 2, 2014, at 1:28 PM, Eleanor Saitta e...@dymaxion.org wrote: Signed PGP part On 2014.10.02 20.39, Greg wrote: There are different types of deniable encryption systems, with very _different_ deniability properties. What you're failing to see here, I think, is that your adversary is almost never a cryptographer. You adversary is a goon who likes to crush fingers, who's heard a rumor that your tool lets people hide things from him. He doesn't like it when people hide things from him. He thinks you're hiding something from him. He's going to keep crushing your fingers until you prove to him that you aren't. You don't have that many fingers left. I see all of that. Stop telling me what I fail to see. Have you read everything in the reddit r/security link I sent you? You have two possible defensible stances based on everything you have said so far: 1. Activists shouldn't encrypt any data whatsoever. 2. Activists should use Espionage-style PD if they are going to choose to use encryption. This is logic. Logic applies to everyone, regardless of whether they are cryptographers, thugs, or people who fail to understand logic. Real-world field experience is the only reasonable and reliable guide for determining the appropriate design of security systems; anything else is at best a amateur[1]. For novel capabilities, *careful* field testing in moderate risk environments is necessary to establish a baseline. Building a real loop with existing training programs to ensure that you get field feedback when systems are used is similarly critical. Feel free to forward concrete suggestions to the emails I've previously provided you with. We have no intention to simulate breaking somebody's fingers. If you know of a way to do that in an ethical way, please forward those ideas to my Inbox. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. Unlike you, I've done my homework and researched the deniability properties of encryption systems and why some are better than others. Field outcomes aren't about math. That's the point I'm trying to make here. The precautionary principle and a Do No Harm approach to software development are incredibly important when looking at the requirements specification of security tools intended to be used in a hostile environment. I cannot stress this strongly enough. Real-world field experience is the only reasonable and reliable guide for determining the appropriate design of security systems; anything else is at best a amateur[1]. For novel capabilities, *careful* field testing in moderate risk environments is necessary to establish a baseline. Building a real loop with existing training programs to ensure that you get field feedback when systems are used is similarly critical. Building software because it's cool is fine, as are projects we do because we believe in them, but at a certain point, there's a bar. Recommending your tools for use in the field in hostile environments is that bar. Beyond that bar, we have an ethical obligation to attempt to act in a professional manner. E. [1]: I mean this in the literal sense of the word, not to be in any way demeaning. There are requirements for professionalism in this field; operational field outcomes reviews are as much a requirement as proper code review, cryptoanalytic review, UX testing, QA, and good documentation. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Ai karumba, I dislike our ancient email system that does not allow you to edit things. On Oct 2, 2014, at 1:37 PM, Greg g...@kinostudios.com wrote: Stop telling me what I fail to see. * Please tell me what I fail to see, but only do so when you've read and understood what the other person was saying, and structure your replies in such a way that the other party can understand that you've understood them. For example, instead of telling me: [broken fingers], try quoting the part of the r/security link that I sent you were I discuss broken fingers (look for rubber hosing), then read *all* of the replies below it, and *then* formulate an argument that demonstrates that I've still failed to see something. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.02 21.37, Greg wrote: Have you read everything in the reddit r/security link I sent you? Of course not. It turns out I have other things to do than read voluminous ramblings by folks on Reddit who don't actually do field work. I'll add it to my queue for when I've got a slow Sunday. You have two possible defensible stances based on everything you have said so far: 1. Activists shouldn't encrypt any data whatsoever. 2. Activists should use Espionage-style PD if they are going to choose to use encryption. You have failed to demonstrate this in any way, other than by brute force assertion, appear to have no field experience, and frankly, it's not clear if you ever even had a real security audit or cryptographic review. Brute assertion for commercial products, in particular, tends to be indicative of a failure to understand real-world deployment constraints. As does naming something Espionage, but that's largely irrelevant. I'm going to stop responding to this thread from this point on, because it's clear to me that no further useful discussion will occur here. Everyone else, hopefully this exchange has been educational as far as the kinds of testing we should be seeing tools go through. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQtuu4ACgkQQwkE2RkM0wr+vgD/a4pHH9SKosesYRv8G6xfDyjA /JZ0CWTDXTfbpMGDH0sBAJrFO63qudSYMP2cjPs93Fp5/4nv51Xgg3QUrL+xMbN8 =rahm -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Oct 2, 2014, at 1:51 PM, Eleanor Saitta e...@dymaxion.org wrote: You have failed to demonstrate this in any way, other than by brute force assertion I demonstrated it by logic. You have only yourself to blame for _choosing_ to ignore the other side's argument: Have you read everything in the reddit r/security link I sent you? Of course not. End of discussion. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 1:51 PM, Eleanor Saitta e...@dymaxion.org wrote: Signed PGP part On 2014.10.02 21.37, Greg wrote: Have you read everything in the reddit r/security link I sent you? Of course not. It turns out I have other things to do than read voluminous ramblings by folks on Reddit who don't actually do field work. I'll add it to my queue for when I've got a slow Sunday. You have two possible defensible stances based on everything you have said so far: 1. Activists shouldn't encrypt any data whatsoever. 2. Activists should use Espionage-style PD if they are going to choose to use encryption. You have failed to demonstrate this in any way, other than by brute force assertion, appear to have no field experience, and frankly, it's not clear if you ever even had a real security audit or cryptographic review. Brute assertion for commercial products, in particular, tends to be indicative of a failure to understand real-world deployment constraints. As does naming something Espionage, but that's largely irrelevant. I'm going to stop responding to this thread from this point on, because it's clear to me that no further useful discussion will occur here. Everyone else, hopefully this exchange has been educational as far as the kinds of testing we should be seeing tools go through. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
We have placed this thread under moderation, as it is now violating guideline #3: 3. To maintain civil discourse, we have a zero-tolerance policy for anyone who posts ad hominems, or otherwise inflammatory, extraneous, or off-topic messages. You are welcome to continue other substantive discussions. Best, Yosem One of the list moderators On Thu, Oct 2, 2014 at 1:41 PM, Greg g...@kinostudios.com wrote: Ai karumba, I dislike our ancient email system that does not allow you to edit things. On Oct 2, 2014, at 1:37 PM, Greg g...@kinostudios.com wrote: Stop telling me what I fail to see. * Please tell me what I fail to see, but only do so when you've read and understood what the other person was saying, and structure your replies in such a way that the other party can understand that you've understood them. For example, instead of telling me: [broken fingers], try quoting the part of the r/security link that I sent you were I discuss broken fingers (look for rubber hosing), then read *all* of the replies below it, and *then* formulate an argument that demonstrates that I've still failed to see something. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
1. Well, this has certainly been an interesting discussion, but until Espionage is FULLY open-source, it's moot, because it hasn't (yet) been exposed to unlimited peer review by arbitrary, independent third parties. Please see: https://mailman.stanford.edu/pipermail/liberationtech/2013-March/007499.html Yes, I do note (per the Tao Effect web site) that people can apply to see the source. Not good enough. 2. About this comment on Reddit: Because Espionage creates fake data for everyone, it is a fact that at least some of the data on your drive is fake. Therefore when you say that data is fake, it's completely believable that it is, because some of it is. We extensively document this feature, so the interrogator knows, too, that your hard drive is guaranteed to contain fake data. Plausible deniability is an interesting concept, but you know, if I'm the one tortudeploying enhanced interrogation techniques against you because you have something I want very very badly, I'm not going to spend my coffee break RTFM'ing about Espionage. To put it another way: If you or I or anyone else are going to suggest that people put their lives (and those of their allies, families, friends, etc.) on the line and rely on this concept to save them, then we should probably verify that it actually works *first*. This isn't an Espionage or Truecrypt et.al. issue per se, it's a conceptual issue and one which is very hard to research, since of course we can't just poll the people whose answers matter the most. (And even if we did, we couldn't trust the answers.) In addition, some of the instance in which it failed in the field are and will likely remain (indefinitely) unknown to us, since the only people likely to report those failures to us are imprisoned or dead. This it not to say that it *never* works: it probably does, some of the time. It is to say that we shouldn't blithely presume that it's *always* going to work, and we especially shouldn't presume that it will work when the stakes are high. ---rsk -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.09.28 04.15, Greg wrote: Dear Rory, See this list on ArsTechnica's forum: http://arstechnica.com/civis/viewtopic.php?f=21t=1245367 I work for Tao Effect LLC, our software is on that list, and you can read about how its plausible deniability compares to TrueCrypt's here (forgive this subreddit's insane color scheme): http://www.reddit.com/r/security/comments/2b5icu/major_advancements_in_deniable_encryption_arrive/cj24a1n In case anyone on this list wants a license, here's a code for 15% off: LIBERATIONTECH There are 10 of them and you can use them on espionageapp.com http://espionageapp.com/. They expire November 1st. While code available is nice, it's sadly not really sufficient to make this relevant for the activist world. Non-multiplatform tools aren't a replacement for Truecrypt, and having to pay for licenses makes your tool completely inaccessible to most folks in authoritarian regimes or in the majority world who may actually need it. Furthermore, when dealing with the exigencies of security in the field, having to deal with license keys at all imposes a serious overhead to expedient solutions in emergencies. And finally, the least useful part of Truecrypt is the deniability. There are very good reasons why tools that attempt to provide deniability may actually significantly harm field outcomes, something which developers seem to not understand. (Also, it's bloody hard to get right, and almost everyone fails, although I haven't looked at this solution in particular.) E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQq0xAACgkQQwkE2RkM0wq0hwD/a/cWXFzWRDtBR9YtzxNvtZra zDovJhYWMG4mS/SIBjcBAIh6gCKBZOIXcPJ13TasQy9V3H/h4Gu0kIZz5eMBFGci =K6CP -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Hi Eleanor, I understand the logic of the argument, but are there news stories about people being harmed in the field due specifically (or mainly) to deniability of the software they are using? (Or research on the topic, though I'm not sure how it could be a falsifiable or reproducible.) -Jonathan On Tuesday, September 30, 2014 11:58 AM, Eleanor Saitta e...@dymaxion.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.09.28 04.15, Greg wrote: Dear Rory, See this list on ArsTechnica's forum: http://arstechnica.com/civis/viewtopic.php?f=21t=1245367 I work for Tao Effect LLC, our software is on that list, and you can read about how its plausible deniability compares to TrueCrypt's here (forgive this subreddit's insane color scheme): http://www.reddit.com/r/security/comments/2b5icu/major_advancements_in_deniable_encryption_arrive/cj24a1n In case anyone on this list wants a license, here's a code for 15% off: LIBERATIONTECH There are 10 of them and you can use them on espionageapp.com http://espionageapp.com/. They expire November 1st. While code available is nice, it's sadly not really sufficient to make this relevant for the activist world. Non-multiplatform tools aren't a replacement for Truecrypt, and having to pay for licenses makes your tool completely inaccessible to most folks in authoritarian regimes or in the majority world who may actually need it. Furthermore, when dealing with the exigencies of security in the field, having to deal with license keys at all imposes a serious overhead to expedient solutions in emergencies. And finally, the least useful part of Truecrypt is the deniability. There are very good reasons why tools that attempt to provide deniability may actually significantly harm field outcomes, something which developers seem to not understand. (Also, it's bloody hard to get right, and almost everyone fails, although I haven't looked at this solution in particular.) E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQq0xAACgkQQwkE2RkM0wq0hwD/a/cWXFzWRDtBR9YtzxNvtZra zDovJhYWMG4mS/SIBjcBAIh6gCKBZOIXcPJ13TasQy9V3H/h4Gu0kIZz5eMBFGci =K6CP -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.-- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.09.30 18.01, Jonathan Wilkes wrote: Hi Eleanor, I understand the logic of the argument, but are there news stories about people being harmed in the field due specifically (or mainly) to deniability of the software they are using? (Or research on the topic, though I'm not sure how it could be a falsifiable or reproducible.) I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQrJRoACgkQQwkE2RkM0wohJQD/crteV0ZMLmZe5cbuNUgYrw45 FZYX657kGhcl0sYmfQMA/2YD3SBHWyqThFjWuF8xuhAh7BkQwEo3ouNchdAbBtml =2qRF -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Eleanor, maybe you can help shed some light on this lack of awareness. How do you think developers should be analyzing risk here? Do you have specific suggestions and/or can you point to sources where that information can be found? On Tue, Sep 30, 2014 at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.09.30 18.01, Jonathan Wilkes wrote: Hi Eleanor, I understand the logic of the argument, but are there news stories about people being harmed in the field due specifically (or mainly) to deniability of the software they are using? (Or research on the topic, though I'm not sure how it could be a falsifiable or reproducible.) I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. E. - -- Ideas are my favorite toys. -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlQrJRoACgkQQwkE2RkM0wohJQD/crteV0ZMLmZe5cbuNUgYrw45 FZYX657kGhcl0sYmfQMA/2YD3SBHWyqThFjWuF8xuhAh7BkQwEo3ouNchdAbBtml =2qRF -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Tue, 2014-09-30 at 14:55 -0700, Huned Botee wrote: Eleanor, maybe you can help shed some light on this lack of awareness. How do you think developers should be analyzing risk here? Do you have specific suggestions and/or can you point to sources where that information can be found? The problem with a deniable filesystem is that not only can you deny it exists, you also can't prove it doesn't. Given that the presence of software-for-deniable-encryption on a machine is decent evidence (in the Bayesian sense) for presence of a deniable filesystem, this is a problem: not being able to prove you don't know something when someone thinks you do is hard, as many people in Guantanamo might attest. -- Mathematics is the supreme nostalgia of our time. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Dear Eleanor, On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. Incidents involving our software? More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. What lack of awareness? How about you actually try the software before you go around insulting it and its developers? There are very good reasons why tools that attempt to provide deniability may actually significantly harm field outcomes, something which developers seem to not understand. And there are very good reasons why this statement of yours is bunk when applied to Espionage: http://www.reddit.com/r/security/comments/2b5icu/major_advancements_in_deniable_encryption_arrive/cj24a1n You are welcome to criticize our software based on knowledge and experience that you actually have, but don't go around making up nonsense and applying said nonsense to software that you admit having not tried. On the other hand, criticizing Espionage for not being free is a fine, legitimate criticism, and something that I'd be happy to brainstorm with you if you'd like to find a solution for how to get it to those activists who need it but cannot afford it. You can email me privately either at this email about that or to: cont...@taoeffect.com My GPG key info is stored in Namecoin at id/greg: dns.dnschain.net/id/greg Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Sep 30, 2014, at 2:48 PM, Eleanor Saitta e...@dymaxion.org wrote: Signed PGP part On 2014.09.30 18.01, Jonathan Wilkes wrote: Hi Eleanor, I understand the logic of the argument, but are there news stories about people being harmed in the field due specifically (or mainly) to deniability of the software they are using? (Or research on the topic, though I'm not sure how it could be a falsifiable or reproducible.) I don't have any field stories that I have permission to share, but yes, I've heard of specific incidents. More generally, it represents an utter lack of awareness on the part of developers for the security risk analysis choices faced by individuals actually at risk. E. -- Ideas are my favorite toys. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Dear Rory, See this list on ArsTechnica's forum: http://arstechnica.com/civis/viewtopic.php?f=21t=1245367 I work for Tao Effect LLC, our software is on that list, and you can read about how its plausible deniability compares to TrueCrypt's here (forgive this subreddit's insane color scheme): http://www.reddit.com/r/security/comments/2b5icu/major_advancements_in_deniable_encryption_arrive/cj24a1n In case anyone on this list wants a license, here's a code for 15% off: LIBERATIONTECH There are 10 of them and you can use them on espionageapp.com. They expire November 1st. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On May 29, 2014, at 1:10 AM, Security First i...@secfirst.org wrote: Hi everyone, While the jury is still out on how this TrueCrypt issue plays out. With TC such a big part of the furniture in LibTech community practises, lessons, manuals, advice, etc., the question I'm sure a lot of us are thinking is: What are the best alternatives to TrueCrypt for the people we work with and train? Is there anything that comes close in terms of open source, cross platform etc? (Pity about the TC license issues as it would be great to see people in the community who might want to fork it and carry it on.) All the best, Rory -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] TrueCrypt Alternatives?
Hi everyone, While the jury is still out on how this TrueCrypt issue plays out. With TC such a big part of the furniture in LibTech community practises, lessons, manuals, advice, etc., the question I'm sure a lot of us are thinking is: What are the best alternatives to TrueCrypt for the people we work with and train? Is there anything that comes close in terms of open source, cross platform etc? (Pity about the TC license issues as it would be great to see people in the community who might want to fork it and carry it on.) All the best, Rory -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Thu, May 29, 2014 at 09:10:08AM +0100, Security First wrote: While the jury is still out on how this TrueCrypt issue plays out. Hmmm.. What are the best alternatives to TrueCrypt for the people we work with and train? http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software dm-crypt/LUKS and freeOTFE do provide an alternative, but not exactly as easy to use. That page is missing an upcoming relevant player there.. Dyne's Tomb: http://www.dyne.org/software/tomb/ But for now it can only be used from command line. As jaromil suggests, there is no true cryptographic safety on Windows machines, so you might as well stop trying to do that on such a computer. Still, I don't get these periodic DoT*-attacks against Truecrypt. Last year there was this rumour going around about Truecrypt not having been properly audited, and then the code that turned out not having been audited for years was openssl. Now there is again fear of backdoors in downloadables from some well-intended website. But who thinks *he can download binaries via the web and expect them to be free of backdoors? The whole approach is broken. The web is not trustworthy. You need someone to get the source codes, look over it, make sure it is the correct one, generate binaries and distribute them over safe channels. I have been using truecrypt built from sources for a decade now, the only trouble it gives me is performance when dealing with legacy file systems such as NTFS. Please get your paranoia properly structured and oriented to the things that are well worth being paranoid about. *) denial of trust -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Truecrypt has not properly been audited. The only audit to date is what has been organised by Matthew Green of Johns Hopkins University. I believe there is still more to go on this, but in light of recent events, one wonders of this is worth it. On Thursday, May 29, 2014, carlo von lynX l...@time.to.get.psyced.org wrote: On Thu, May 29, 2014 at 09:10:08AM +0100, Security First wrote: While the jury is still out on how this TrueCrypt issue plays out. Hmmm.. What are the best alternatives to TrueCrypt for the people we work with and train? http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software dm-crypt/LUKS and freeOTFE do provide an alternative, but not exactly as easy to use. That page is missing an upcoming relevant player there.. Dyne's Tomb: http://www.dyne.org/software/tomb/ But for now it can only be used from command line. As jaromil suggests, there is no true cryptographic safety on Windows machines, so you might as well stop trying to do that on such a computer. Still, I don't get these periodic DoT*-attacks against Truecrypt. Last year there was this rumour going around about Truecrypt not having been properly audited, and then the code that turned out not having been audited for years was openssl. Now there is again fear of backdoors in downloadables from some well-intended website. But who thinks *he can download binaries via the web and expect them to be free of backdoors? The whole approach is broken. The web is not trustworthy. You need someone to get the source codes, look over it, make sure it is the correct one, generate binaries and distribute them over safe channels. I have been using truecrypt built from sources for a decade now, the only trouble it gives me is performance when dealing with legacy file systems such as NTFS. Please get your paranoia properly structured and oriented to the things that are well worth being paranoid about. *) denial of trust -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu javascript:;. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
On Thu, May 29, 2014 at 08:51:21PM +1000, Tom O wrote: Truecrypt has not properly been audited. The only audit to date is what has been organised by Matthew Green of Johns Hopkins University. I believe there is still more to go on this, but in light of recent events, one wonders of this is worth it. You mean Heartbleed? Nothing in the whole industry is properly audited, some stuff is just sufficiently old. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
No I mean TrueCrypt Site is is truecryptauditedyet.com Heartbleed was a vuln found by researchers at Google (Heel Mehta), not the result of an audit. I assure you that there are significant software projects that go through intense auditing. Nothing is secure, but there are some things less secure than others. On 29 May 2014 22:37, carlo von lynX l...@time.to.get.psyced.org wrote: On Thu, May 29, 2014 at 08:51:21PM +1000, Tom O wrote: Truecrypt has not properly been audited. The only audit to date is what has been organised by Matthew Green of Johns Hopkins University. I believe there is still more to go on this, but in light of recent events, one wonders of this is worth it. You mean Heartbleed? Nothing in the whole industry is properly audited, some stuff is just sufficiently old. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
Sorry the link should be www.istruecryptauditedyet.com On 29 May 2014 22:37, carlo von lynX l...@time.to.get.psyced.org wrote: On Thu, May 29, 2014 at 08:51:21PM +1000, Tom O wrote: Truecrypt has not properly been audited. The only audit to date is what has been organised by Matthew Green of Johns Hopkins University. I believe there is still more to go on this, but in light of recent events, one wonders of this is worth it. You mean Heartbleed? Nothing in the whole industry is properly audited, some stuff is just sufficiently old. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] TrueCrypt Alternatives?
For those with imminent interest: http://rpmfusion.org/Package/realcrypt cheers /t -Original Message- From: liberationtech [mailto:liberationtech-boun...@lists.stanford.edu] On Behalf Of carlo von lynX Sent: Thursday, May 29, 2014 2:37 PM To: liberationtech Subject: Re: [liberationtech] TrueCrypt Alternatives? On Thu, May 29, 2014 at 08:51:21PM +1000, Tom O wrote: Truecrypt has not properly been audited. The only audit to date is what has been organised by Matthew Green of Johns Hopkins University. I believe there is still more to go on this, but in light of recent events, one wonders of this is worth it. You mean Heartbleed? Nothing in the whole industry is properly audited, some stuff is just sufficiently old. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
