Re: [cryptography] [liberationtech] CryptoParty Handbook
- Forwarded message from Seth David Schoen sch...@eff.org - From: Seth David Schoen sch...@eff.org Date: Thu, 4 Oct 2012 17:06:27 -0700 To: liberationtech liberationt...@lists.stanford.edu Subject: Re: [liberationtech] CryptoParty Handbook User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: liberationtech liberationt...@lists.stanford.edu Andrew Mallis writes: 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 I'm grateful to people for doing this (and happy that it built upon some prior sprints that I was part of!) but I'm a bit worried about errors. Starting from the end of the book I fairly quickly came upon two things that concerned me: Quantum cryptography is the term used to describe the type of cryptography that is now necessary to deal with the speed at which we now process information and the related security measures that are necessary. Essentially it deals with how we use quantum communication to securely exchange a key and its associated distribution. As the machines we use become faster the possible combinations of public-key encryptions and digital signatures becomes easier to break and quantum cryptography deals with the types of algorithms that are necessary to keep pace with more advanced networks. I think the first and third sentences of this paragraph are completely mistaken. (The second sentence is right to assert that quantum cryptography deals with key-exchange mechanisms.) First, quantum cryptography for key exchange is unrelated to the speed at which we now process information. In fact, conventional encryption has scaled well and more than kept pace with increases in communications data rates, particularly since our CPUs have gotten faster much faster than our communications links have. That's one reason that it's now much more feasible to use HTTPS routinely for web services -- current CPUs can handle the ciphers involved efficiently, and some CPUs even have hardware acceleration for AES. It's also not clear that using quantum cryptography is necessary for anyone today. QKD still requires strong authentication https://en.wikipedia.org/wiki/Quantum_key_distribution#Man-in-the-middle_attack so although it could reduce the need to make assumptions about the difficulty of solving math problems that are used in other forms of key distribution, it does _not_ make the authentication problem go away. The authentication problem is the logistically difficult thing about using all distributed cryptosystems, so when you use QKD you still encounter these logistical difficulties, in addition to (in most existing implementations) the extra major logistical difficulty of needing a physically directly connected fiber optic cable (!) between the parties who are trying to establish a key. Yikes! The book's suggestion that [a]s the machines we use become faster the combinations of public-key encryptions and digital signatures becomes easier to break is also not an argument for using quantum cryptography, just appropriate key lengths. See http://www.keylength.com/ 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. 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: CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file sys‐ tem modes: * log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) * file systems that write
Re: [cryptography] [liberationtech] CryptoParty Handbook
- Forwarded message from Asher Wolf asherw...@cryptoparty.org - From: Asher Wolf asherw...@cryptoparty.org Date: Fri, 05 Oct 2012 13:26:09 +1000 To: liberationt...@lists.stanford.edu Subject: Re: [liberationtech] CryptoParty Handbook User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Reply-To: liberationtech liberationt...@lists.stanford.edu At the moment, public edit function on the crowd-sourced portal for the CryptoParty Handbook has been removed due to ongoing attempts at vandalism of the document. If you would like to contribute, make edits or alterations, please either email me at: asherw...@cryptoparty.org On 5/10/12 12:11 PM, Nick M. Daly wrote: 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 -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] cjdns review
On Fri, Oct 05, 2012 at 10:58:40AM +0200, Guus Sliepen wrote: 1. Measure. Don't speculate. I found a benchmark here: https://github.com/cjdelisle/cjdns/blob/master/rfcs/benchmark.txt So it seems that is not as slow as I suspected: it can forward packets at a rate of 7 Gbit/s on an Opteron 6128. So for a VPN or overlay network that is OK. But for their intended goal of being able to work completely independent of, and a replacement for, an existing Internet, it does require an awful lot of CPU power on routers. Current routers have memory lookups on expensive (CAM) route memory, so if the logic is easy enough to cast into ASIC (or even an FPGA) the resulting packet forwarding rate might be actually quite impressive for amount of silicon and power footprint. 4. Perhaps most importantly, the public-key computation (Curve25519) is reusable (see crypto_box_afternm()) whenever the sender-receiver set is the same. This means that specifying crypto_box() for every packet does _not_ imply public-key cryptography for every packet. I did not know of this feature; and delving into the source code of cjdns, crypto_box_afternm() is indeed what is being used. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] cjdns review
On 05.10.2012 10:58, Guus Sliepen wrote: I found a benchmark here: https://github.com/cjdelisle/cjdns/blob/master/rfcs/benchmark.txt So it seems that is not as slow as I suspected: it can forward packets at a rate of 7 Gbit/s on an Opteron 6128. I think you have misread. The benchmark actually shows 700Mb/s, not 7Gb/s. Just pointing it out to avoid confusion when checking local performance. Also, cjd (aka Caleb James DeLisle, developer of cjdns) asked me to share some words from him to this list (edited for readability): cjd There are 3 (or possibly 2) layers of encryption on cjdns traffic. The innermost layer is the end-to-end crypto which most people agree makes sense. The outermost layer (hop-to-hop) is entirely optional since you can speak with your neighbor in any protocol you and he can agree on. This leaves the middle layer which is between routers, since traffic only needs to be sent to another router if a path to it's final destination is not known, router-to-router traffic is not as common as one would expect. From a security perspective, the most troubling fact is that poly1305 authentication is switched off for the inner 2 layers of crypto to save overhead, relying instead on the TCP/UDP checksum to indicate forgery. This can however easily be fixed by sending an authenitcate packets bit when beginning a session. The implementation just currently chooses not to. /cjd -- Jonas ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] I downloaded the TOR Browser pack for Windows today
It had no certificate. Why is that? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] I downloaded the TOR Browser pack for Windows today
On 2012-10-06 12:12 PM, Randall Webmail wrote: It had no certificate. Why is that? Central authority is a security hole. Suppose the state wants a more cooperative Tor. The guy who is most cooperative will get to be designated the real Tor. Instead, you should verify the digital signatures of Tor Browser * Microsoft Windows https://media.torproject.org/video/torbrowser-docs/How-to-verify-signatures-in-Windows.mp4 * Apple OSX https://media.torproject.org/video/torbrowser-docs/How-to-verify-signatures-in-OSX.mp4 * Linux https://media.torproject.org/video/torbrowser-docs/How-to-verify-signatures-in-Linux.mp4 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
