Re: [liberationtech] TrueCrypt Alternatives?
On Oct 2, 2014, at 4:55 PM, Rich Kulawiec wrote: > 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 K, thanks for the read (I read it but nothing there seems to apply, perhaps some of its points will be addressed below). > Yes, I do note (per the Tao Effect web site) that people can "apply" to > see the source. > > Not good enough. 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. You want free and open source? Use TrueCrypt. You want to see Espionage's source? Apply. > 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. Yes, you will. If you want the data, you will read about Espionage and how it works. You have no other choice. https://www.youtube.com/watch?v=NRISmm3dpVw Cheers, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 2, 2014, at 4:55 PM, Rich Kulawiec wrote: > > 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. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/li
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.
[liberationtech] Please Help with "secure mobile communications" training materials
From: Hans-Christoph Steiner I'm going to be doing a "secure mobile communications" training in November, so I thought I'd take this opportunity to gather relevant materials, organize it, and hopefully get it incorporated into https://www.level-up.cc Any suggestions for materials, please send my way! It can be slides, web pages, text, images, videos, audio, ideas, whatever! .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -- 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 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 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?
On Oct 2, 2014, at 1:51 PM, Eleanor Saitta 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 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?
-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?
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 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?
On Oct 2, 2014, at 1:28 PM, Eleanor Saitta 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?
-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?
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 wrote: > On Oct 2, 2014, at 6:54 AM, Eleanor Saitta wrote: > >> >> On 2014.10.01 04.22, Greg wrote: >>> On Sep 30, 2014, at 2:48 PM, Eleanor Saitta >>> 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 wrote: > >> Signed PGP part >> On 2014.10.01 04.22, Greg wrote: >>> On Sep 30, 2014, at 2:48 PM, Eleanor Saitta >>> 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
Re: [liberationtech] TrueCrypt Alternatives?
On Oct 2, 2014, at 6:54 AM, Eleanor Saitta wrote: > > On 2014.10.01 04.22, Greg wrote: > > On Sep 30, 2014, at 2:48 PM, Eleanor Saitta > > 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 wrote: > Signed PGP part > On 2014.10.01 04.22, Greg wrote: > > On Sep 30, 2014, at 2:48 PM, Eleanor Saitta > > 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?
> 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 : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2014.10.01 04.22, Greg wrote: > > On Sep 30, 2014, at 2:48 PM, Eleanor Saitta > > 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014.10.01 04.22, Greg wrote: > On Sep 30, 2014, at 2:48 PM, Eleanor Saitta > 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.
