Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] CryptoParty Handbook

Bernard Tyers - ei8fdb ei8fdb at
Tue Oct 9 05:18:10 PDT 2012

Hash: SHA1

On 8 Oct 2012, at 23:46, Jacob Appelbaum wrote:

> Asher Wolf:
>> The argument everyone is politely avoiding - while pondering the
>> numerous ways CryptoParty will expose already compromised individuals -
>> is whether the masses SHOULD use crypto.
> I'm not ignoring it and most of the world has been using crypto for
> online stuff since SSLv2 was released to the world.
>> Rain-check: it's happening - or at least, the users are are trying -
>> regardless of whether they're are doing it right, or regardless of
>> whether more experienced ppl are willing to offer their advice or not,
>> and completely separate to the philosophical, technical and security
>> related-discussions that are currently swirling.
>> Basically: hello crypto, the users are here.
> I'm sorry to say it but a lot of the users have been here for a while -
> most people that use crypto just don't know they're doing it.
> Ironically, if users don't get good advice, they'll just be in the same
> spot - thinking they're safe when they're not - all over again!

Yes, the users have been here for a long time. They are hanging around in the corner trying to talk to the guy who just seems like such a dick, but in fact is just unable to talk to people who don't speak his lingo, and he is not interested in talking to them.

Ultimately some people will want to talk to him, and other won't, but at least get over the awkward introductions.

>>> From experience, most of the non-tech ppl who attended Melbourne's
>> Cryptoparty had previously attempted to install various tools by
>> themselves and had either (a) failed (b) installed them incorrectly (c)
>> couldn't figure out how to configure them (d) given up 'til now.
>> CryptoParty is essentially the user saying: We are working together to
>> trying to figure out how to do it better. We need these tools.
>> Whatever the best-practice model actually is, it'll be crowdsourced,
>> because people are unwilling to wait for easy 'crypto manna from
>> heaven', offered up on a plate.
>> And frankly, the users have much to learn from the crypto experts and
>> it'd be a damn shame if knowledgeable people refused to teach or share
>> their expertise because ppl are "doing it wrong."
> I think that the real changes belong in the platforms - anything that
> requires configuration is probably already doomed to fail and screw a
> user. That's generally the approach that I've seen work - everything
> that requires 0) user education and 1) realistic honesty about threats
> or risks results in 2) denial or mistakes or a bork'ed tool shooting the
> user in the foot.

While you've probably got a really good reason for saying 0) and 1) above, I'd like to hear them, just because I used to think similar things as 0) and 1).

The more I have been reading about [NORMAL USERS] the more I think we (the people who know about the complicated shit) are not going to save them all. It may sound disingenuous to say but, there is no point trying. Humans are humans. Getting people to think themselves about these topics it a lot more successful than giving them tools and hoping they use them.

I'm surprised to hear you say everything that requires user education fails. I (think) I know your reasoning.

>> We've known we've been doing it wrong for a long time now and going back
>> to Facebook to organise is no longer an option.
>> The creation of CryptoParty was a spontaneous, viral storm. It was NOT a
>> concerted, centrally-organised campaign, with funding or even a
>> best-practice model. My hope is that experts contribute to eventually
>> provide a best-practice model, and that users give the necessary
>> feedback allowing for tweaks in tools and creation of more accessible
>> crypto.
> Since clearly a few loud people were bent out of shape by my comments -
> they have no idea that I encouraged you or tried to help out; so let me
> set the record straight: go you!
> I think it is *great* to make the book and I think it is great to do it
> with a set of unifying principles - it will help to ensure that good
> stuff gets into the book and crappy stuff stays out of the book or is so
> noted as crappy or contentious. I think that means that peer review is
> essential before rushing to publish.

(This may sound insulting, but its not meant to.)

Absolutely 100% completely agree. It should have been peer-reviewded from the start.

It was (IMO) wrong, and slightly misguided to write a handbook which is ultimately about a complex and technical set of topics, without having some expert advice or input. That is not to insult the work the people did. I just think it was executed incorrectly.

To continue my previous self-bashing thread, technical people need to be more easier to deal with. We need to be more intelligent in how we explain what are complicated subjects. 

Saying "data confidentiality, authentication, threat-model, non-repudiation," to most people means squat. As someone explained, "every time you walk across a road, you make a threat-model/assessment" makes more sense.
We also need to understand that most people don't really care about the super complicated stuff thats involved in crypto/security.

On the other hand, to bash the people who are not crypto/security experts, they have to understand that the subjects are involved are complicated, not easily reduced. They also need to understand the implications of giving wrong/bad information.

They also need to know when something the technical people say is not just hot-air, or BS.

One giant PDF for this cryptoparty handbook was the wrong approach. It should have been Git or a closed wiki. It should have been broken down into chapters and had people who know about the topics working on it too. Sure it would have taken more time, but it would have saved all this thrashing about.

Git is not something most people would want to use (or indeed heard of) but for an editing process its a good option. There should have been a change log all the while. 

When its finished, or ready for purpose, then publish it in PDF/mobi/whatever.

Learning how crypto / security works is not rocket science. Anyone can learn the approaches used, the right or wrong ways to do something. You may not become a leading developer of it but thats ok. Not everyone will.

People can learn how to install PGP, Enigmail, the Tor browser bundle, Truecrypt, but if they aren't educated on how best to use them (to think for themselves) then the cryptoparty is wasting their time.

I was present (and helped out a bit ) at the Tor talk the London crytoparty and it was wonderful to see discussions with the "non-technical" (I hate saying that but I don't know what else to say) people who attended to Tor talks. They were thinking about things. They just needed some help.

It was clear to see there were people present who had thought about these tools. Their issue was not "Should I should use this?", it was "How the fuck do I know when/where to use it?"

> I really encourage you to put in a few chapters about the following:
> social and technical compartmentalization
> targeted exploitation realities (from Core Impact to Metasploit)
> threat modeling
> intention/goal based risk analysis
> physical security risks
> practical information on real surveillance/censorship systems
> getting involved
>   going from a user (to a translator or...) to a developer
> outlining the currently missing tools that we need to build

The list of topics you added above, to me, are topics that show cryptography and security is not just about whizz-bang technical stuff - they are about looking at a subject critically, with rational thought and making decisions based on logic rather than trust or "it'll be ok.

Once you understand the threats, then you yourself can come to a decision as to what tool is right for the job.


- --------------------------------------
Bernard / bluboxthief / ei8fdb

IO91XM /

Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -


More information about the liberationtech mailing list