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.
