Re: [liberationtech] CryptoParty Handbook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2012 06:10 AM, Julian Oliver wrote: Seth, your comments about the Quantum Crypto text are excellent and, on looking more closely, factually correct. I personally don't think such material has a place in a handbook like this but with your clarifications it will at least render it great reference material. Your comments about journaled file-systems and shredders/wipers were super and so will be added to the next edition. I think that quantum crypto needs to be explained in the 'book, at least at a high level. In some discussions I've had with people about crypto, someone's always brought up Quantum computers broke all crypto anyway, so there's no reason to do all of this, followed by a mostly uphill fight to convince them that there's no reliable evidence that there are quantum computers at Ft. Meade pwning us all. In other words, some solid ground to stand on when the trolls come 'round (and the do). I've forked the repo on Github and when I get some time this weekend I'll start working on some stuff. Missing chapters like Threat Modeling (introducing it to newbies, first of all) This. So much this. need to be written, as well as an unintimidating reference table for strength of encryption by type and threat context. This is something that came up in I think there is some pretty reliable research out there that can be referenced in the 'book. Still, I don't think it justifies those few security pros clumsily (and somewhat destructively) writing off the book entirely. Rather than being black and white More 'dead duck' discussions, I take it? when it comes to security it's far more constructive to let people into the process of learning to think for themselves by understanding such particular risks; to be aware, agile and vigilant. Security itself is a process in constant Toolkits, not cookbooks. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Sing loud! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlB3IkYACgkQO9j/K4B7F8EXMACgryyoLanzR9QkyYK9LYRkqu6p JSYAni4rpH18lvs0uE6IsoD7zeuQFS0k =Ocm4 -END PGP SIGNATURE- -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Hi list, Great to be subscribed! I'm one of the core group that spearheaded the CryptoParty Handbook here in Berlin and thought I'd share a few words on its reception. I'd like to emphasise that the point of the book is not as a static reference guide but a text intended to grow in direct response to the inevitable evolution of threats. As such each draft should never be considered definitive, with the first draft was written and distributed with the expressed statement it needs work. More so (and as the name suggests) it's material intended for reference (and discussion) at Crypto Parties. Around 20 people were involved in total during the 'book sprint' of just 3 days. We went in knowing it was not possible to write a definitive, bug-free guide in 56 hours, let alone on a topic such as securing oneself in this techno-political jungle we call the Internet. For this reason we invited help, opening it up for public review. Seth, your comments about the Quantum Crypto text are excellent and, on looking more closely, factually correct. I personally don't think such material has a place in a handbook like this but with your clarifications it will at least render it great reference material. Your comments about journaled file-systems and shredders/wipers were super and so will be added to the next edition. Missing chapters like Threat Modeling (introducing it to newbies, first of all) need to be written, as well as an unintimidating reference table for strength of encryption by type and threat context. This is something that came up in discussion during the book sprint. Currently there's a bit of an issue with the Github fork running off on its own but only because it's splitting expertise and can't be easily merged. I'm personally for the BookType/Booki version as we can export to E-Pub/PDF/Kindle and use the lovely CSS formating and renderer. It makes attractive books whilst letting those that simply want to fix a typo an opportunity to contribute without having to learn the wily ways of Git (which I use for code development, but not the writing of essays/books). Indeed the unchecked references to PPTP were unfortunate, imported from the book Basic Internet Security (Gerber, Hassan, Stein, van Geffen, van Santen, van der Velden, den Tex, Schmidt et al). It was trusted material. I don't think any of us knew PPTP was cloud-crackable albeit we did know it was less secure than OpenVPN (I'm doubly thankful I use OpenVPN on my own server!). It shouldn't have gone into the first draft without appropriate warnings for fear of it being misconstrued as endorsement of this readily breakable PPP tunnelling method. Still, I don't think it justifies those few security pros clumsily (and somewhat destructively) writing off the book entirely. Rather than being black and white when it comes to security it's far more constructive to let people into the process of learning to think for themselves by understanding such particular risks; to be aware, agile and vigilant. Security itself is a process in constant dialogue with awareness, not a boolean of safety. Telling people not to use the book as a whole, while not taking the time to contribute welcomed specific criticism, only keeps people vulnerable. Why? Firstly - perhaps obviously - it discourages people from gleaning any other good from the book, whether that be getting people started with Tor, Anonymised searching, Encrypted VoIP or basic Email and Browsing security. Lots of folk have written in to say it's the best pro-newbie guide they've read to these effects. Secondly, hundreds of VPN services still use PPTP (including Riseup.net, PirateBay, iPredator). So it follows that to /not/ reference this fact - alongside stark warnings as to the risks - in such a book may result in less people using VPNs and remaining out in the open. Why do these providers use PPTP? Perhaps some actually believe that after the minor MS-CHAPv2/MPPE improvements it's safe whereas others consider speed important (faster than OpenVPN), especially in mobile contexts. There's a conspicuous lack of OpenVPN clients out there for Smartphones. Thankfully the excellent GuardianProject is changing that. While I personally support the general consensus to remove all the VPN HOWTO references using PPTP from the handbook, I do feel it's better to let people take and make risks in Knowledge. To this end PPTP would not be excluded from the book but discussed and warned against. As much as saying the following will be enough to send some crypto geeks running down a hill with an axe, there may be cases where using a PPTP VPN might even be a little bit better than not using a VPN altogether.. Let me unpack that seemingly ridiculous statement: A BlackBerry user simply wants to get through the company or UNI gateway without being spied upon but doesn't really have a lot at stake if caught. Thus the convenience of using a PPTP VPN service with a free app on their smartphone fits their
Re: [liberationtech] CryptoParty Handbook
..on Wed, Oct 10, 2012 at 12:10:10PM +0200, Julian Oliver wrote: There's a conspicuous lack of OpenVPN clients out there for Smartphones. Should've read: There's a conspicuous lack of OpenVPN clients out there for non-rooted Smartphones making L2TP/IPSec is the next best choice. Cheers, -- Julian Oliver http://julianoliver.com http://criticalengineering.org -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Hi Julian, congratulations with the cryptoparty book; On 10/10/12 12:10, Julian Oliver wrote: Indeed the unchecked references to PPTP were unfortunate, imported from the book Basic Internet Security (Gerber, Hassan, Stein, van Geffen, van Santen, van der Velden, den Tex, Schmidt et al). It was trusted material. I don't think any of us knew PPTP was cloud-crackable albeit we did know it was less secure than OpenVPN (I'm doubly thankful I use OpenVPN on my own server!). It shouldn't have gone into the first draft without appropriate warnings for fear of it being misconstrued as endorsement of this readily breakable PPP tunnelling method. In the introduction to VPN networks 'Basic internet Security' says: PPTP is one of the older VPN technologies. While PPTP is known to use weaker encryption than either L2TP/IPSec or OpenVPN, it may still be useful for bypassing Internet blocking and give some level of encryption. The client software is conveniently built into most versions of Microsoft Windows, Apple, Linux computers and even mobile phones. It is very easy to setup. While it is easy to copy content to add to a book, (BIS did this from Security in a box and from Circumventing censorship) You should be careful when to do that. I do not understand why you did not just give a list of resources including the above mentioned and focus more on the Cryptoparty specific content. About trusted source: unchecked means copy paste without review, that is also bad practice with trusted content, because the content is part of a longer story, if you are just in a chinese room shuffling symbols you should not edit or include a chapter. The whole idea of books is to transfer knowledge from one place to another. Also what was secure or acceptable for some use cases yesterday can be very problematic today. Cheers, Sacha -- Greenhost - Sustainable Hosting T: +31204890444 i...@greenhost.nl https://greenhost.nl/ A digital signature can be attached to this e-mail, you need opengpg software to verify it. see: http://tinyurl.com/openpgp-manual Key fingerprint = 4F15 CE56 36AB A1C2 0D81 BE10 E12B B435 F2D5 2E48 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Hey Sasha, ..on Wed, Oct 10, 2012 at 01:08:22PM +0200, Sacha van Geffen wrote: congratulations with the cryptoparty book; On 10/10/12 12:10, Julian Oliver wrote: Indeed the unchecked references to PPTP were unfortunate, imported from the book Basic Internet Security (Gerber, Hassan, Stein, van Geffen, van Santen, van der Velden, den Tex, Schmidt et al). It was trusted material. I don't think any of us knew PPTP was cloud-crackable albeit we did know it was less secure than OpenVPN (I'm doubly thankful I use OpenVPN on my own server!). It shouldn't have gone into the first draft without appropriate warnings for fear of it being misconstrued as endorsement of this readily breakable PPP tunnelling method. In the introduction to VPN networks 'Basic internet Security' says: PPTP is one of the older VPN technologies. While PPTP is known to use weaker encryption than either L2TP/IPSec or OpenVPN, it may still be useful for bypassing Internet blocking and give some level of encryption. The client software is conveniently built into most versions of Microsoft Windows, Apple, Linux computers and even mobile phones. It is very easy to setup. While it is easy to copy content to add to a book, (BIS did this from Security in a box and from Circumventing censorship) You should be careful when to do that. I do not understand why you did not just give a list of resources including the above mentioned and focus more on the Cryptoparty specific content. The book is a handbook, so it should contain the HOWTOs alongside introductions to core concepts, threats, etc. There was a lot missing from Basic Internet Security that needed to be covered for it to be a guide for real newbies. There were also some tool areas not properly covered and or uppacked for use at Crypto Parties. Adam Hyde led the sprints of both books. Some people at our last two CryptoParties didn't know what a server was, thought the Cloud had something to do with satellite Internet while another thought email client relates to a commercial client you send an email to. Even 'Operating System' needs to be unpacked as one person mistook the OS in OS X as relating only to Apple. Another thought it was necessary to use Google to access the Internet as he types each URL into the Google field, effectively using Google search as a proxy DNS. The list goes on. Many that use and depend upon the Internet find it utterly baffling. Your great little outline to PPTP from Basic Internet Security was simply skipped in the intro to VPNs (Browsing section) and will go into the v1.1 Cheers, -- Julian Oliver http://julianoliver.com http://criticalengineering.org -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Hi Julian, On 10/10/12 13:41, Julian Oliver wrote: Hey Sasha, . The book is a handbook, so it should contain the HOWTOs alongside introductions to core concepts, threats, etc. There was a lot missing from Basic Internet Security that needed to be covered for it to be a guide for real newbies. There were also some tool areas not properly covered and or uppacked for use at Crypto Parties. Adam Hyde led the sprints of both books. that makes sense, still the main point from my last mail was that if you copy content you should also take the time to check whether the content is (still) accurate. I am glad you trust us in what we have written, but you can't use that as the only excuse for having it included, you as writers should take your responsibility here. On the other hand this has also shown me one of the things to take care of when publishing free books, and that is that the basic unit seems to be the chapter, and that chapter needs to be self-contained, if our warning would have been closer to the actual pptp instructions it would have been included in your manual as well. Some people at our last two CryptoParties didn't know what a server was, thought the Cloud had something to do with satellite Internet while another thought email client relates to a commercial client you send an email to. Even 'Operating System' needs to be unpacked as one person mistook the OS in OS X as relating only to Apple. Another thought it was necessary to use Google to access the Internet as he types each URL into the Google field, effectively using Google search as a proxy DNS. The list goes on. Many that use and depend upon the Internet find it utterly baffling. Yeah, I know this can happen, I could quite easily add some experiences to that list. Then again one of the great things with cryptoparties is that there are actually people around that can help each other and explain things ;) Your great little outline to PPTP from Basic Internet Security was simply skipped in the intro to VPNs (Browsing section) and will go into the v1.1 Cheers, -- Greenhost - Sustainable Hosting T: +31204890444 i...@greenhost.nl https://greenhost.nl/ A digital signature can be attached to this e-mail, you need opengpg software to verify it. see: http://tinyurl.com/openpgp-manual Key fingerprint = 4F15 CE56 36AB A1C2 0D81 BE10 E12B B435 F2D5 2E48 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
..on Wed, Oct 10, 2012 at 03:08:25PM +0200, Sacha van Geffen wrote: Hi Julian, On 10/10/12 13:41, Julian Oliver wrote: Hey Sasha, . The book is a handbook, so it should contain the HOWTOs alongside introductions to core concepts, threats, etc. There was a lot missing from Basic Internet Security that needed to be covered for it to be a guide for real newbies. There were also some tool areas not properly covered and or uppacked for use at Crypto Parties. Adam Hyde led the sprints of both books. that makes sense, still the main point from my last mail was that if you copy content you should also take the time to check whether the content is (still) accurate. I am glad you trust us in what we have written, but you can't use that as the only excuse for having it included, you as writers should take your responsibility here. I don't think any of us make that our excuse. We ommitted to copy in your (and/or write other) text to put VPN/PPTP in security context. I'm not sure why/how that happened. An ever visible security checklist for each chapter would've fixed that! On the other hand this has also shown me one of the things to take care of when publishing free books, and that is that the basic unit seems to be the chapter, and that chapter needs to be self-contained, if our warning would have been closer to the actual pptp instructions it would have been included in your manual as well. Agreed. Robust copyability. Cheers, -- Julian Oliver http://julianoliver.com http://criticalengineering.org -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Re: the book edit portal - I do not have control over the platform it is being edited on. The handbook project was launched by people in Berlin's CryptoParty, and I was brought on board at a later point. On 9/10/12 9:30 AM, Jacob Appelbaum wrote: @samthetechie Why were you offended? Did you work on any of the software in the book? Did you try to help a bunch of the first CryptoParty events out? Sam organised and ran CryptoParty London. He stepped up when nobody else did. He found a venue. He asked for access to edit the book repeatedly. He has run impromptu cryptoparty sessions with activists since. He should be commended for that. I did those things - Jacob, I'm aware you had contact with at least couple of cryptopartie, which is great. Your work talking about privacy, surveillance and Tor was instrumental in beginning the conversations that lead to CryptoParty. Due to the respect many people have for you, it's reasonable to assume events around the world would approach you to speak. I'm not aware that you attended a party or spoke at one yet. Can you advise me if this is different? We want your involvement, and are very grateful for your critical analysis so far. and you say that I should do more because I dared to not endorse it with fanfare? I agree that the book doesn't need any more endorsements - only critical analysis and editing and content revision. I am concerned though that some of the ways in which the conversation is being framed around issues with the current edition are not particularly productive in encouraging people to continue. One of the things I believe is there's only a certain number of people with the correct skill set and motivation to successfully pull of certain projects. It's important to get the process of constructive criticism right - otherwise interaction becomes demoralising. I did not work on the technical aspects of the book. I cannot. I do not have the right skill set. I have fielded maybe 6 criticisms of current version of the book since Jacob's comments on twitter. I've tried to encourage people to write their own revisions and directed the concerns towards @julian0liver who was with the original team working on the handbook when possible. x. Asher -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
My biggest concern is with getting insecure suggestion out of the book asap. Jake, if the entire chapter is worse than useless, please delete it? x. Asher On 9/10/12 9:36 AM, Jacob Appelbaum wrote: The chapter that talked about using PPTP is straight up crazy talk. Anyone using PPTP is worse off unless they merely wanted to get owned with a few hour delay. All the best, Jacob -- Greg Norcie (g...@norcie.com) GPG key: 0x1B873635 On 10/7/12 3:45 PM, Alec Muffett wrote: Would love to hear why. On behalf of all of us who suffered quietly through the Cryptocat journobitchfest, might I please just beg, no, or at least not on this list? I went to the London crypto party, I've met some of the people, I have opinions upon which I am sitting until the enthusiasm wanes a bit and folk are less defensive; and then I will blog them, and the discussion can happen in the blogosphere. Perhaps I am wrong, perhaps everyone does want to listen in on discussion of a book. Perhaps the book is liberation-related technology. Discussion of it will likely be hot air, however, especially since the authors themselves claim it is a moving target. - alec -- http://dropsafe.crypticide.com/aboutalecm -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On 9/10/12 9:46 AM, Jacob Appelbaum wrote: 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! That's what we want to avoid. 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 requires pushing developers to create user accessible, secure platforms. 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. We don't know what we don't know. We're asking for help, and I at least, appreciate your imput. 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! Thanks, I appreciate the support. All of your contribution is appreciated. 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. Agreed, and I did voice concerns at the short deadline for publishing. 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 This list is appreciated. Thank you for the feedback. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On Fri, Oct 05, 2012 at 05:43:46AM +0200, Maxim Kammerer wrote: Did anyone try this with devices that are supposed to be resistant to file shredding due to wear leveling? I tried the following on two USB keys, one ~12 years old, another ~6 years old, both formatted as FAT32: echo test_string_123 x for i in $(seq 20); do cat x x x1; mv x1 x; done cp x /media/... sync shred -u /media/... sync cp /dev/sd... image LC_ALL=C grep -wc test_string_123 image The result was 0 in both cases. That's expected, because you're still going through the translation layer. If you had instead hooked up a microcontroller to the data pins of the flash chips on the circuitboard, you'd find that much of the data you'd written is still on the flash chips; it's simply in pages that aren't referenced by the current FTL state. Think of flash as a series of 6 whiteboards with 4 post-it notes tracking which page of notes is which. You start out writing to the board with 1 on it; when you fill that up you go to 2, then 3, then 4. Since you only have 4 post-it notes (4GB of memory) but the board with 1 on it is full of crud, you move the 1 post-it to a new board and continue writing. A gnome comes along and starts erasing the old 1 board because it doesn't have a post-it. Before the gnome finishes erasing old-1, you move 2 to a new whiteboard and keep writing. Now, what happened when you ran shred? The 4 post-it notes (the FTL) got moved to fresh boards, which got filled with random writing. But the original board with test_string_123 on it doesn't have a post-it note and the gnome got tired, so the board isn't erased and there's no way to read it (because you can only read boards with post-it notes). In fact, one of the boards got used so much that its stand broke, and the gnome wheeled it into the corner without erasing it. Both of these gnome problems are real problems with FTL based systems; erase blocks can wear out and fail to erase, and the background erase process can fail to erase data as expected. Neither problem is very likely for any particular write, nor for any particular data, but just to be safe I always recommend using full-disk encryption when using SSDs, and physically destroying any removable flash-based media that have critically important data on them. PGP can be used to symmetrically encrypt data before putting it on an SD card/USB drive, too. -andy -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Oct 2012, at 22:35, Brian Conley wrote: Greg its called orbot and it runs on Android. Secondly I used to agree with you, but I'm increasingly coming to the conclusion that user education, not simplification, is the more important piece of the user security and privacy problem. I am glad someone else is saying this. While it's wonderful to say sure security is easy, alls you gots to do is [LOTS OF SHIT THAT PEOPLE DON'T UNDERSTAND] and voilà you're secure, people want tools they can use. As a geek/technical person/engineer/whatever you call me, I will say technical people are our own worst enemies. We overly complicate things, which is fine if you want to make people discover/learn through doing - but they have to be presented to the right people in the right way. Most people, in fact even some technical people (shock!), want tools that just work. Yes, they want them to be secure, but not at the expense of being easy to use. Yes, as a technical person I love delving into the guts of something technical and just geeking out (as much as I hate that phrase), but I want to do that when I want. I use the computer operating system I use, not because it's beautiful and shiny and whatever - I use it because a) on the user interface level it is reasonably easy to use, coherent, and consistent and b) because if I want to hack something deep down, I (mostly) can. Technology is a tool. It is a tool to help you carry out a task and to get to an end goal. If the technology gets in the way of carrying out that task, then (in my view) it has failed. Particularly if the user does not know how to fix it. Security should be integrated into the tool. It should not be a bolt on. It should be integrated. The complexity of it should be secondary, not hidden, to the ultimate goal. If the user wants to get at the complexity, then they should be able. Sending a PGP encrypted e-mail to you mom, should be as easy as sending an un-encrypted e-mail to your mom. But the education of why you should be sending an e-mail encrypted should also be given. Granted, a valid threat-model should be explained, as a given. That said, the tools do need to get more accessible, but we are getting there. I don't believe there has been as sizable a change in public health and user information campaign efforts. Technical people are our own worst enemies. We make things look more complicated than they need to be. Sometimes its laziness (naughty!), and sometimes I think its a job security thing (bad, but understandable...to a point). What came out of the London Cryptoparty for me was, the amount of thought some people have put into the decision to not use a security tool. A clearly intelligent person said (paraphrasing): we spent time looking at the tool but we couldn't understand how it worked. Not the technical operation, but what we needed to do. Was it a desktop application. Did we have to run it on a server. Was it a mobile application. The guy had obviously spent time looking at it, but could not understand what he needed to do. He wasn't an idiot. He was someone who should be using the tool, *but decided against it because he didn't know its function*. That to me was a (pardon the language) fucking eye opener. (NB: I am not having a go at the developers of this tool. Their work is excellent. But it just hows me how complicated (leaving aside the cryptographic/technical complexity) this is.) It might be easy to say, but this almost as important as the security of the tool. Maybe as important. Yes, the tool needs to be secure, but it needs to be easy to use. Otherwise, doesn't matter. That's not to say that I agree with giving people simplified, basic or plain wrong information. (more on that in a later e-mail) Security is complicated stuff. Cryptography is complicated stuff. But it doesn't have to be presented as complicated to use it. I know bugger all about how a car works in detail, but I can operate a car, and when necessary do simple troubleshooting. Any other approach and people are being treated like children. GIve them the information, but ultimately they'll decide if they want to use it. Bernard (getting the flame-retardent suit ready) - -- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQdAk/AAoJENsz1IO7MIrr9XkH/12a+XSf/sX6dvtYxHv7QhNA ZzrfmLcdV/zek5AGUrVxJrxIgPzdiGyQHqi+be9VMXCPgo1sZ7iLSTwm7ic/20J/ w4oenKbXUnjotbF0/ZdEYNp0LsFxrjpP/b74XN4F4Rx78Ax6hPlD8P4k2lW4ep/0 FjwPk1UK495mQJm6fXt3f2WEoB1uAA0clxjpXoUy8vZMjKeXtWu4is2qPbmc1o8W FmDZH8A2izCLsrcqxW8kTwXoOc93hRAbWh+/fSvRV7lOPYXJPB2/6NNiL9AtKSq9 3EqP9ZzO8vQZ12CtRMn98ZbnnvIZRW48TremzqOFuG3mds+9PzFR/IjKVclJoVg= =I2MK -END PGP SIGNATURE- -- Unsubscribe, change to digest, or change password
Re: [liberationtech] CryptoParty Handbook
I still haven't understood the canonical url for editing - can you tell me where the main book editing page is? I agree with Adam that Github won't involve the right people but if that is the only interface, I'll fork the book and send a pull request. Thanks, please list issues here: https://github.com/cryptoparty/handbook/issues We'll try to get people to edit all known issues asap. Thanks, Asher. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On 9/10/12 10:36 PM, Jacob Appelbaum wrote: I did not work on the technical aspects of the book. I cannot. I do not have the right skill set. This attitude, I think, is a key issue this community and many others face. You cannot? Or you will not? I believe that you are totally able to learn and I think that it is very demoralizing when people say they are *unable* or *unwilling* to learn. That isn't to say that you will become a developer of cryptographic protocols. It is to say that many people will need to make choices about security and trusting a vanguard is dangerous. We're always trusting someone and I realize that reality. I didn't write my own compiler to compile my email client before sending this email with hand crafted electrons... However the high level view of most of this stuff is well within the grasp of each person - it just requires an interest and *educational resources* that empowers *all people* to learn. Wait, I'm just trying to remember when I last slept more than 4 hours in a night while trying to educate myself. I've gone from being a Facebook user to running OTR, PGP and Tor all in under a month. I'm trying to put in the time I have free - mostly between 1am and 4am - towards learning. Note: I'm a sole parent, without access to child support, no childcare and trying to support myself, my son, put myself through postgraduate studies and contribute to social movements. 1 year ago I didn't own a laptop. Everything I created online in the past 2 years prior was on the only thing I could afford - a phone. The CryptoParty peeps in Germany wrote the book during a time frame that coincided mostly between 12 midnight and 4am my time here in Australia. I tried to contribute where I could. But I can't spot issues I don't even understand yet. I don't know what I don't know. It takes time to learn. I outlaid the costs on CryptoParty Melbourne from my own pocket, to educate myself, as much as other people. Am I unable or unwilling to learn? Am I demoralizing others by being unwilling to learn? You decide. Am I always trusting others rather than trying to understand for myself? Well, I cannot read the code (yet) behind certain platforms. When I try to develop an informed decision around security based on the best info I have at hand - usually by watching the tech journos and tech experts on twitter - and then I am often called to account - personally - for my decisions to use or not use certain platforms. Am I being empowered to learn? Am I empowering others to learn? I hope so. I'm trying to be the best example I can be, and to be honest it is not easy. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Bernard Tyers - ei8fdb: 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. I'm not into your analogy but I understand it. Ultimately some people will want to talk to him, and other won't, but at least get over the awkward introductions. Are these the users using HTTPS? :-) 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). A few mail clients would ask you for your username/password - the user would type them in and then the mail client would be setup. Sadly - those mail clients didn't use crypto and from the very first step - they were owned. I advocate that no user should ever need that education (hit cancel, setup the account by hand manually, etc). Realistic honesty means that people who fall back to saying well, I'm not worried anyway or I have nothing to hide need our support. These kinds of justifications are part of a coping mechanism that kicks in as a result of user education, pride or often, shame. 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. This is why a platform fix will help every single user who decides to use it. When people use Tails - I think they're way better off over say, an old Windows system with Tor Browser for anonymous browsing. I'm surprised to hear you say everything that requires user education fails. I (think) I know your reasoning. The key is that a user may learn to click cancel in the above example but I don't think they *should* be required to do so to be safe. 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
Re: [liberationtech] CryptoParty Handbook
Asher Wolf: On 9/10/12 10:36 PM, Jacob Appelbaum wrote: I did not work on the technical aspects of the book. I cannot. I do not have the right skill set. This attitude, I think, is a key issue this community and many others face. You cannot? Or you will not? I believe that you are totally able to learn and I think that it is very demoralizing when people say they are *unable* or *unwilling* to learn. That isn't to say that you will become a developer of cryptographic protocols. It is to say that many people will need to make choices about security and trusting a vanguard is dangerous. We're always trusting someone and I realize that reality. I didn't write my own compiler to compile my email client before sending this email with hand crafted electrons... However the high level view of most of this stuff is well within the grasp of each person - it just requires an interest and *educational resources* that empowers *all people* to learn. Wait, I'm just trying to remember when I last slept more than 4 hours in a night while trying to educate myself. I do not doubt for even a minute that this is true. I merely wish to suggest that what I took from your other mail is one of a statement regarding innate ability. A lot of people use that kind of language without even realizing it - it is similar to sexism and actually, I think often is a product of sexism in a lot of cases. If you had included I'm working on it but I don't understand x or y, who does? - I would have taken it entirely differently. The former is seemingly an expression of a lack of a safe space or something worse and the latter is one that encourages collaboration. I'm sure there are other paths. I've gone from being a Facebook user to running OTR, PGP and Tor all in under a month. That is proof that ability is not static and that with the Will to change, we will asses our capabilities and realistically adapt. Sometimes we'll fail and sometimes we'll succeed. The important point is that while we all have limits (physical, mental, capital, social, etc), we must never mistake capacity and ability - both in terms of time bounded ability or skill bounded ability. No one is born a writer - we all practice. That isn't to then go on to say pull up by the bootstraps! but rather to say - some of us face more hardship than others. Short of serious genetic, environmental or abuse issues, we're all able to grow, learn and adapt. Obviously systemic sexism, racism, classism and so on will impact the realistic and practical time constraints that we're all facing during that growth. I'm trying to put in the time I have free - mostly between 1am and 4am - towards learning. I think it would be an interesting experiment to run an indygogo fund to support your work here; perhaps where the idea is to produce a free book and part of what people contribute is time or other resources, including capital. I'd contribute both to that cause. Your dedication and passion is apparent and I respect that our goals, as well as our tactics and strategy overlap. I also respect that they often diverge. Note: I'm a sole parent, without access to child support, no childcare and trying to support myself, my son, put myself through postgraduate studies and contribute to social movements. 1 year ago I didn't own a laptop. Everything I created online in the past 2 years prior was on the only thing I could afford - a phone. That says to me that you're making progress toward your goal and that is exactly why I said that I respected the effort; regardless of the content, I might add. The CryptoParty peeps in Germany wrote the book during a time frame that coincided mostly between 12 midnight and 4am my time here in Australia. I tried to contribute where I could. But I can't spot issues I don't even understand yet. I don't know what I don't know. It takes time to learn. Of course. I outlaid the costs on CryptoParty Melbourne from my own pocket, to educate myself, as much as other people. Am I unable or unwilling to learn? Am I demoralizing others by being unwilling to learn? You decide. I think that the language used in the previous email does actually reflect a kind of demoralization. I don't blame you for it but it certainly *shocked* me because some of this story is known to me from when we met in person. That subtext doesn't carry through - so it is lost. Am I always trusting others rather than trying to understand for myself? Well, I cannot read the code (yet) behind certain platforms. When I try to develop an informed decision around security based on the best info I have at hand - usually by watching the tech journos and tech experts on twitter - and then I am often called to account - personally - for my decisions to use or not use certain platforms. I think that is a reasonable strategy - though I would be concerned about many of the tech journalists - they often have terrible information security
Re: [liberationtech] CryptoParty Handbook
On 12-10-09 10:41 AM, Jacob Appelbaum wrote: ttscanada: On 12-10-09 4:23 AM, Bernard Tyers - ei8fdb wrote: Sending a PGP encrypted e-mail to you mom, should be as easy as sending an un-encrypted e-mail to your mom. But the education of why you should be sending an e-mail encrypted should also be given. Granted, a valid threat-model should be explained, as a given. Thank you. I understand that this is a *crypto* party discussion - but I really hope the end result of this manual focuses on use cases and threat modeling as well as the technology. I agree entirely. We need to look at the real uses. We should stop degrading the hypothetical mom though, the question is about literacy and to suggest that women are less literate is pretty offensive. Obviously, it wasn't intended in that way but boy, I've certainly had someone read me the riot act for saying that exact example. +1 Some ideas of security rely far more on technical contortions than real life assessment, the equivalent of entering a crowd wearing a flame retardant SWAT suit instead of just taking an alley. Secure anonymity is frequently the dead opposite of security based on trust networks such as pgp signed emails which depend on a real life identity being known and completely remove deniability or ease of frequently switching identities. I think this is rather bogus. Anonymity, in terms of traffic analysis resistance, as far as the local network is concerned is not in conflict with identified services. Hmm. I was not clear. My point was that I would like to see the benefits of anonymity pointed out (as opposed to simply privacy) more often than it is. Of course traffic analysis is a major threat to anonymity, my concern is in encouraging people to think that they are somehow safe simply because the content of their emails is encrypted. We all know that people all over the world are suffering the consequences of simply pulling attention or association, no proof of content required. Trust networks are the antithesis of the type of anonymity required to combat pulling attention. I regularly sign or encrypt email with GPG that is sent with Thunderbird (with TorBirdy) via Gmail over Tor. I do this because location anonymity is important to me and without Tor's anonymity, gmail would know every location and so too would my location be revealed by the headers in my email. Additionally, I think this makes it harder to target a specific MITM flaw in my email client - there were years where you could downgrade the STARTTLS in some email clients. While a Tor exit node might be able to do that if the flaw exists, the Tor exit node doesn't know that I'm me automatically, so selective targeting becomes significantly harder. Not impossible, of course. Juts today - I was on a network that blocked chat services and what we found was that most people didn't notice because their chat was running over Tor with TLS, a few were going to Tor Hidden Services - only those that felt they didn't need anonymity were impacted. Oh the irony of thinking of the issue of anonymity as only personal privacy, rather than the larger issue of traffic analysis, surveillance, filtering and censorship. Yes, you are outlining two cases where you are communicating with people you know as a person known to them. I am suggesting we (as in large scale movements around the world) need to look more closely at data driven (as opposed to personality driven) models ... ie if/when Tribler gets onion routing working and an anonymous entity can drop data to a hashtag (instead of a person), this is to me a more secure communication model than one which relies on relationships between individuals, ie f2f or other. Then we have to deal with voice amplification and astroturfing issues, but it is the path I would rather proceed down than the trust networks being advocated by for instance, OWS which are fairly obviously problematic. Of course this only applies to some specific instances such as large scale organizing; as I said, let's look at what is best in each case. Let's not lose track of the end goal, which is security not just security tools. The end goal for me is about social justice and law alone has not and will not produce social justice in isolation. We also need various innovations working in concert with policies. We won't have security without code to back it up - that is what we're seeing all over the world with the massive expansion of surveillance and censorship. The people, corporations, and governments running national firewalls were supposedly doing it for benevolent reasons. As expected from historical context, they're expanding their power and their impact, to benefit of powerful stake holders, to keep their position and influence well secured. Agreed, overcoming the guardian coupd'état is the real end goal. http://georgiebc.wordpress.com/2012/09/17/individuals-in-society/ All the best, Heather All the best, Jacob -- Unsubscribe,
Re: [liberationtech] CryptoParty Handbook
Case in point: I received an invitation under the names of five separate organizations I am affiliated with (none of which are OWS related) to fill this out. It originally said real name required, was changed to alias after I objected publicly, but the rest still stands. http://occupywallst.org/media-survey/ All the crypto and Tor in the world isn't going to help with this. All the best, Heather On 12-10-09 1:26 PM, ttscanada wrote: On 12-10-09 10:41 AM, Jacob Appelbaum wrote: ttscanada: On 12-10-09 4:23 AM, Bernard Tyers - ei8fdb wrote: Sending a PGP encrypted e-mail to you mom, should be as easy as sending an un-encrypted e-mail to your mom. But the education of why you should be sending an e-mail encrypted should also be given. Granted, a valid threat-model should be explained, as a given. Thank you. I understand that this is a *crypto* party discussion - but I really hope the end result of this manual focuses on use cases and threat modeling as well as the technology. I agree entirely. We need to look at the real uses. We should stop degrading the hypothetical mom though, the question is about literacy and to suggest that women are less literate is pretty offensive. Obviously, it wasn't intended in that way but boy, I've certainly had someone read me the riot act for saying that exact example. +1 Some ideas of security rely far more on technical contortions than real life assessment, the equivalent of entering a crowd wearing a flame retardant SWAT suit instead of just taking an alley. Secure anonymity is frequently the dead opposite of security based on trust networks such as pgp signed emails which depend on a real life identity being known and completely remove deniability or ease of frequently switching identities. I think this is rather bogus. Anonymity, in terms of traffic analysis resistance, as far as the local network is concerned is not in conflict with identified services. Hmm. I was not clear. My point was that I would like to see the benefits of anonymity pointed out (as opposed to simply privacy) more often than it is. Of course traffic analysis is a major threat to anonymity, my concern is in encouraging people to think that they are somehow safe simply because the content of their emails is encrypted. We all know that people all over the world are suffering the consequences of simply pulling attention or association, no proof of content required. Trust networks are the antithesis of the type of anonymity required to combat pulling attention. I regularly sign or encrypt email with GPG that is sent with Thunderbird (with TorBirdy) via Gmail over Tor. I do this because location anonymity is important to me and without Tor's anonymity, gmail would know every location and so too would my location be revealed by the headers in my email. Additionally, I think this makes it harder to target a specific MITM flaw in my email client - there were years where you could downgrade the STARTTLS in some email clients. While a Tor exit node might be able to do that if the flaw exists, the Tor exit node doesn't know that I'm me automatically, so selective targeting becomes significantly harder. Not impossible, of course. Juts today - I was on a network that blocked chat services and what we found was that most people didn't notice because their chat was running over Tor with TLS, a few were going to Tor Hidden Services - only those that felt they didn't need anonymity were impacted. Oh the irony of thinking of the issue of anonymity as only personal privacy, rather than the larger issue of traffic analysis, surveillance, filtering and censorship. Yes, you are outlining two cases where you are communicating with people you know as a person known to them. I am suggesting we (as in large scale movements around the world) need to look more closely at data driven (as opposed to personality driven) models ... ie if/when Tribler gets onion routing working and an anonymous entity can drop data to a hashtag (instead of a person), this is to me a more secure communication model than one which relies on relationships between individuals, ie f2f or other. Then we have to deal with voice amplification and astroturfing issues, but it is the path I would rather proceed down than the trust networks being advocated by for instance, OWS which are fairly obviously problematic. Of course this only applies to some specific instances such as large scale organizing; as I said, let's look at what is best in each case. Let's not lose track of the end goal, which is security not just security tools. The end goal for me is about social justice and law alone has not and will not produce social justice in isolation. We also need various innovations working in concert with policies. We won't have security without code to back it up - that is what we're seeing all over the world with the massive expansion of surveillance and censorship. The people, corporations, and governments
Re: [liberationtech] CryptoParty Handbook
On 12-10-09 1:53 PM, Jacob Appelbaum wrote: Heather Marsh: Yes, you are outlining two cases where you are communicating with people you know as a person known to them. I am suggesting we (as in large scale movements around the world) need to look more closely at data driven (as opposed to personality driven) models ... ie if/when Tribler gets onion routing working and an anonymous entity can drop data to a hashtag (instead of a person), this is to me a more secure communication model than one which relies on relationships between individuals, ie f2f or other. Then we have to deal with voice amplification and astroturfing issues, but it is the path I would rather proceed down than the trust networks being advocated by for instance, OWS which are fairly obviously problematic. Well, sorta. I have quite a few jabber accounts and sometimes, one per contact when I don't know them or when I do not want to be contacted at all times. :) With that said - I think GNUNet already does what you want re: hashtags of data, doesn't it? I mean, you literally search for a SHA1 cryptographic hash - I guess GNUNet could call it a hashtag just for hilarity... It would be between gnunet and tribler, but tribler is in the lead for both scaleability, with 1.2 million downloads, and close to livestreaming on android etc., and features in their protocols which allow some really interesting applications for mass collaboration channels. Plus they are ahead working on p2p knowledge repositories which is the only way I can think of to combat unverified astroturfing in a system besides trust networks. We need something that can scale to handle protests in Madrid or Beijing with something close to real time messaging and streaming. This being the current alternative (jk). http://occupywallst.org/media-survey/ All the best, Heather Marsh -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Greg Norcie: Any book written by non-experts about something as complicated as crypto will have imperfections. But sometimes security researchers become paralyzed with the need for something to be perfect. You need to look at it from a public health perspective. Also - sometimes people without a real understanding of things give bad advice and it is actually bad advice. From a public health perspective, I have a hard time believing that homeopathetic remedies are a net positive when they're basically just bullshit cargoculting. The point isn't to be perfect - no one is seriously arguing for perfect. Most of the (usable) security community agrees that perfection is the enemy of good enough; the operative point of that tired phrase however is that something is actually good enough! The handbook is not perfect by any means, but someone using it is probably better off than if they were simply going in blind. The chapter that talked about using PPTP is straight up crazy talk. Anyone using PPTP is worse off unless they merely wanted to get owned with a few hour delay. All the best, Jacob -- Greg Norcie (g...@norcie.com) GPG key: 0x1B873635 On 10/7/12 3:45 PM, Alec Muffett wrote: Would love to hear why. On behalf of all of us who suffered quietly through the Cryptocat journobitchfest, might I please just beg, no, or at least not on this list? I went to the London crypto party, I've met some of the people, I have opinions upon which I am sitting until the enthusiasm wanes a bit and folk are less defensive; and then I will blog them, and the discussion can happen in the blogosphere. Perhaps I am wrong, perhaps everyone does want to listen in on discussion of a book. Perhaps the book is liberation-related technology. Discussion of it will likely be hot air, however, especially since the authors themselves claim it is a moving target. - alec -- http://dropsafe.crypticide.com/aboutalecm -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
I think this is a great project. But I do think that a manual is a stopgap measure - it would also be great if we worked towards making these tools usable enough that they didn't need a manual. If we can make an iPod so easy enough for our grandparents to use, we should be able to do the same with Tor, PGP, etc. It will be a long, arduous process, but I think it can be done. Usable security it not an oxymoron :) -- Greg Norcie (g...@norcie.com) GPG key: 0x1B873635 On 10/4/12 5:13 PM, Andrew Mallis wrote: FYI This 392 page, Creative Commons licensed handbook is designed to help those with no prior experience to protect their basic human right to Privacy in networked, digital domains. By covering a broad array of topics and use contexts it is written to help anyone wishing to understand and then quickly mitigate many kinds of vulnerability using free, open-source tools. Most importantly however this handbook is intended as a reference for use during Crypto Parties. PDF available for download and more info: https://cryptoparty.org/wiki/CryptoPartyHandbook *Andrew Mallis* #ows Tech Ops http://www.nycga.net/groups/tech | FGA http://wiki.occupy.net/wiki/Federated_General_Assembly | Occupy Directory http://directory.occupy.net -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
I was actually really offended by @ioerror's comment on twitter. Even if it was justified technically I think the mature approach is to use his personal reach and voice online to rally collaborators to help make the handbook better not declaim it for the sake of it... I nearly tweeted back with the link to the editing portal with a simple statement well volunteered... @samthetechie On 7 October 2012 20:37, Yosem Companys compa...@stanford.edu wrote: I think Jacob has some issues about the CryptoParty Handbook. As he noted on Twitter: The #CryptoParty handbook is really unimpressive and fraught with peril. A good idea and a nice effort but ultimately quite dangerous. Would love to hear why. Thanks, Yosem On Sun, Oct 7, 2012 at 12:09 PM, Greg Norcie g...@norcie.com wrote: I think this is a great project. But I do think that a manual is a stopgap measure - it would also be great if we worked towards making these tools usable enough that they didn't need a manual. If we can make an iPod so easy enough for our grandparents to use, we should be able to do the same with Tor, PGP, etc. It will be a long, arduous process, but I think it can be done. Usable security it not an oxymoron :) -- Greg Norcie (g...@norcie.com) GPG key: 0x1B873635 On 10/4/12 5:13 PM, Andrew Mallis wrote: FYI This 392 page, Creative Commons licensed handbook is designed to help those with no prior experience to protect their basic human right to Privacy in networked, digital domains. By covering a broad array of topics and use contexts it is written to help anyone wishing to understand and then quickly mitigate many kinds of vulnerability using free, open-source tools. Most importantly however this handbook is intended as a reference for use during Crypto Parties. PDF available for download and more info: https://cryptoparty.org/wiki/CryptoPartyHandbook *Andrew Mallis* #ows Tech Ops http://www.nycga.net/groups/tech | FGA http://wiki.occupy.net/wiki/Federated_General_Assembly | Occupy Directory http://directory.occupy.net -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Sigh. The handbook is not perfect by any means, but someone using it is probably better off than if they were simply going in blind. ...and 50 Shades of Grey is better than nothing as far as relationship manuals go? Yes, that's flippant, but (eg) someone to whom I am talking has just downloaded 28Mb of PDF to try and determine what has changed since last time, and that's just a matter of logistics. I've already pointed out on twitter that - at least as-of 2 days ago - there was nothing about the operational security / virus / government agent risk of someone walking into a Cryptoparty with something evil on a USB stick. Bad advice is worse than no advice at all, but both are worse than good advice. My advice: delete the PDF and produce several such somethings along the lines of FAQs, a-la ancient shit like http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html -a -- http://dropsafe.crypticide.com/aboutalecm -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Edits to the #CryptoParty handbook can be made here: https://github.com/cryptoparty/handbook -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On Fri, Oct 05, 2012 at 05:43:46AM +0200, Maxim Kammerer wrote: Did anyone try this with devices that are supposed to be resistant to file shredding due to wear leveling? I tried the following on two USB Wear levelling is a function of newer devices (your old USB flash sticks are unlikely to have it, but your new SSD definitely has) and it hides damaged blocks transparently by using the overprovisioned flash block pool (its size depending on on whether consumder or enterprise drive, the latter having more overprovisioning). It might be possible to access the damaged blocks via a debug function, or by flashing the drive with custom firmware. keys, one ~12 years old, another ~6 years old, both formatted as FAT32: echo test_string_123 x for i in $(seq 20); do cat x x x1; mv x1 x; done cp x /media/... sync shred -u /media/... sync cp /dev/sd... image LC_ALL=C grep -wc test_string_123 image The result was 0 in both cases. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On Fri, Oct 5, 2012 at 8:33 AM, Eugen Leitl eu...@leitl.org wrote: Wear levelling is a function of newer devices (your old USB flash sticks are unlikely to have it, but your new SSD definitely has) and it hides damaged blocks transparently by using the overprovisioned flash block pool (its size depending on on whether consumder or enterprise drive, the latter having more overprovisioning). Does it mean that you ran the commands above on a FAT32-formatted media and got a result different from 0? It might be possible to access the damaged blocks via a debug function, or by flashing the drive with custom firmware. Did you try a bigger file? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Good day to you all :) On 10/05/2012 03:57 AM, Griffin Boyce wrote: Hey all, Considering both the complexity of material and the time constraints involved, the handbook came out beautifully. It's well-laid out and covers a surprisingly large number of topics step-by-step at a beginner level. Anyone who has a solid understanding of how to use the internet can be taught how to use common encryption tools with this manual. And that in and of itself is amazing. Yes, I found amazing that such a thing was produced in such a short amount of time. It can't be expected to be perfect and totally up-to-date with bleeding edge knowledge on security, but can be a very good start for introducing a lot of topics, provided that some mistakes are corrected (e.g. the file shredding things). In any case the initiative is excellent. It could deserve translations in other languages. Having it in wiki format is tricky because of vandalism, but perhaps turning it into a github repository might be a better option. That way, you could see updates line-by-line and cherry-pick the ones you want/don't want. I was wondering if a LaTeX file + git repository could be a good idea? Any comment on this? Cheers, KheOps -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On Thu, 4 Oct 2012 14:13:13 -0700 Andrew Mallis o...@ideograph.ca wrote: This 392 page, Creative Commons licensed handbook is designed to help those with no prior experience to protect their basic human right to Privacy in networked, digital domains. This seems like good stuff, but I have to ask one obnoxious question: what is the actual license for the book? Creative Commons covers a wide range of possibilities from truly free to nearly fully proprietary. I can't find any information on what the actual license is on the web page or in the book itself. Thanks, jon -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
For what it's worth regarding multiple passes to sanitize data: http://www.infosecisland.com/blogview/16130-The-Urban-Legend-of-Multipass-Hard-Disk-Overwrite.html http://cs.harvard.edu/malan/publications/pet06.pdf On Thu, Oct 4, 2012 at 5:06 PM, Seth David Schoen sch...@eff.org wrote: I was also concerned by the Securely Destroying Data section. Although it acknowledges some situations under which erased data (or even overwritten data) could be recovered, it seems to treat these situations as exceptional and multiple-overwrite tools generally reliable. It doesn't mention that these tools are potentially quite untrustworthy on current filesystems even under normal conditions, because of data journaling. (I first learned about this problem from John Gilmore.) In fact, even the man page for shred gives a warning about this: -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
If someone wanted to make an edit, what is the best way to note that or redistribute a derivative work? Thanks for the hard work! On Oct 4, 2012 9:27 PM, Asher Wolf asherw...@cryptoparty.org wrote: As one of the people asked to participate in the writing in the CryptoParty Handbook, I was initially concerned about the speed at which it was being produced. However, noting the need for crowd-sourced participation on the text, and the number of attempts to vandalize the document, I do believe it was necessary to publish a first, open-ended version asap, to give people something to build on. The core idea was to maintain the Handbook as an open document, that can have content added, deleted, and altered at anytime. I would invite everyone to participate, in helping to make the CryptoParty Handbook a better resource for everyone. https://cryptoparty.org/wiki/CryptoPartyHandbook Currently the portal for making additions and alterations to the handbook is closed due to vandalism, but I will gladly pass on any relevant info to be added or changed to the book. Please feel free to email me: asherwolf [at] cryptoparty [dot] org - Asher Wolf -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
Andrew Mallis o...@ideograph.ca writes: This 392 page, Creative Commons licensed handbook is designed to help those with no prior experience to protect their basic human right to Privacy in networked, digital domains... Most importantly however this handbook is intended as a reference for use during Crypto Parties. Andrew, this is great work. I started reading it on the bus today and found a few bits that could be updated or clarified. The numbers are page numbers. - [ ] 5: Remove the link to opensourceecology.org. - [ ] 7: as many or as few as two people - an incomplete thought. - [ ] 12: add the you've got no business in my business argument: Privacy exists because part of the human experience is personal, intimate, even. Robbing people of that devalues human life and experience. - [ ] 21: give time values to password lengths and predictability. e.g.: a completely random 8 character password provides up to 12 hours of privacy after your password is exposed, if attacked by one average blackhat [0]. Attacked by a script kitten? Maybe longer, depending on the strength of their graphics card(s). Attacked by a nation-state? It's probably seconds. - [ ] 22: add grc.com/passwords as a link for fully random passwords. - [ ] 25: Lower threatenable area: consider POP3 for your email to move it off the easily accessible servers as quickly as possible. If it's inconvenient for you, it'll be even more so for your attackers. Is there a preferred contribution method? I didn't see one mentioned in the PDF, but I probably missed it. Nick 0: http://arstechnica.com/security/2012/08/passwords-under-assault/ -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] CryptoParty Handbook
On Fri, Oct 5, 2012 at 2:06 AM, Seth David Schoen sch...@eff.org wrote: NIST and others have thought about what appropriate cryptographic key lengths are to respond to the phenomenon of computers getting faster. That's why current NIST recommendations call for using 2048-bit RSA instead of 1024-bit RSA -- not a quantum cryptosystem, just a stronger key length. Recommended key lengths get larger mostly due to theoretic advances, much less so due to computers getting faster. Cryptographic algorithms are supposed to be resistant to brute force attacks for the foreseeable future at the time of their design, when used with the default key length. Some people see this concern as hypothetical, but it's pretty easy to test with loopback mounting. I just made a 100 MB file, initialized it with zeroes, created an ext4 filesystem in it, and loopback mounted the filesystem. Then I created several very large text files with repeating, easy-to-recognize contents, and then deleted the files with shred -u. It was still possible to find a small number of copies of the text file contents in the underlying storage file afterward -- probably because of data journaling in ext4. Did anyone try this with devices that are supposed to be resistant to file shredding due to wear leveling? I tried the following on two USB keys, one ~12 years old, another ~6 years old, both formatted as FAT32: echo test_string_123 x for i in $(seq 20); do cat x x x1; mv x1 x; done cp x /media/... sync shred -u /media/... sync cp /dev/sd... image LC_ALL=C grep -wc test_string_123 image The result was 0 in both cases. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
