July 2018 - cypherpunks-legacy

Re: The Case for Banning Reduced Hop Count Implementations
by Paul Syverson 06 Jul '18

06 Jul '18

Thank you Lucky. I had been meaning to write something like your post. On Mon, Nov 23, 2009 at 02:43:47AM -0500, Gregory Maxwell wrote: > On Mon, Nov 23, 2009 at 12:29 AM, Lucky Green <shamrock(a)cypherpunks.to> wrote: > [snip] > > seeking higher anonymity. The end state, if lower than three hop > > implementations are permitted to use the Tor network, is that Tor's > > network performance will acceptable only to users of lower hop clients. > > I presume you can back this assertion up with simulation results, at a minimum? > > I look forward to reading your paper. Even if Lucky's basic points are eventually born out, you are right that more analysis of latency and incentives would be valuable. To get an idea about incentive issues in anonymous communication in general and Tor in particular you might want to look at "On the Economics of Anonymity". Also "Anonymity Loves Company: Usability and the Network Effect" both available from the Freehaven anonbib. Also, "Deploying Low-Latency Anonymity: Design Challenges and Social Factors" which is available from the onion-router.net publications page. > > [snip] > > origin. The protocols commonly used for such downloads can accept higher > > latency than the interactive protocols needed by the part of the user > > Which is why twiddling the hop count isn't attractive for them. > > It is attractive for IRC, for example, because with the current hop > counts it can be difficult to keep a TCP connection up for long. > Long lived connections don't benefit much from the longer paths in > any case because the provide ample opportunity to simply correlate > entry and exit traffic and ignore the interior path. This has nothing to do with how long the connections are. Onion routing going back even before Tor acknowledges that if the entry and exit nodes are controlled/observed then an adversary will quickly and trivially link them. The nutshell way we have said this is that onion routing [including Tor] guards against traffic analysis not traffic confirmation. This was acknowledged in the original Tor design paper and was later born out by analysis ("Passive Attack Analysis for Connection-Based Anonymity Systems") experiments on the live Tor network ("Locating Hidden Services") and in simulation on PlanetLab ("Low-Resource Routing Attacks Against Tor"). These confirmed that correlation was fast and easy. "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries" showed that it could also be done sampling a tiny fraction of the traffic passing through an IX. This is also why onion routing's security is said to be roughly c^2/n^2, where c is the number of compromised nodes in the network and n is the total number of nodes. (Yes that is a little too quick, and you can raise questions. See "Towards an Analysis of Onion Routing Security", "A Model of Onion Routing with Provable Anonymity", and "Probabilistic Analysis of Onion Routing in a Black-box Model" for details.) The "Low-Resource" paper is especially telling wrt your point: the attacks were done during connection setup _before a single data cell was transmitted_ (and with vanishingly few false-positives). You just don't need to have a long-lived connection to fall victim to this. So why bother with multiple hops? One part of the answer is already given above: it reduces the threat quadratically. But why three hops instead of just two? This comes back to Lucky's other point that you skipped over. And this one is not subtle at all. Three hops is the minimum to guarantee that all an exit node knows is that a circuit came from someone using Tor. The exit cannot say even where in the Tor network the circuit started. Similarly, all an entry node knows is that the circuit is headed somewhere. (Yes, this too is actually more subtle; cf. "How Much Anonymity does Network Latency Leak?" But, a priori, given ordinary log information, it is correct. (Of course honest Tor nodes do not do any such logging.)) So, reducing the number of hops means that exit nodes have significantly more information about connection origins. Reducing hops to one means that they know everything about the origin of a connection (up to the IP address from which the connection entered the Tor network, which is all that Tor is designed to hide.) That makes their deniability of what they know about traffic exiting through them no longer plausible (because, well now it will be false). That any of the connections going through the network are single hop thus increases incentives to attack any exit node, also any entrance node---which basically means all the public nodes. Details would depend on likelyhood that a given circuit is one hop and on the incentives, legal considerations, resources, etc. of the adversary. But absent such details, it would be unwise to allow such a fundamental threat to the infrastructure itself. As Lucky observed, this is a threat to the public Tor network itself and should be treated as such. There are other drawbacks that could be noted, but that is the central one. HTH, Paul *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- 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

1 0

[cryptography] crypto.cat
by Mario Contestabile 06 Jul '18

06 Jul '18

You guys have any cypherpunk opinions on https://crypto.cat/ ? It's a "secure" online communication tool, apparently used by Anonymous. It was developed by Nadim Kobeissi, (yet another Montrealer). Mario _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

1 0

[cryptography] bitcoin stats (Re: OT: Skype-Based Malware Forces Computers into Bitcoin Mining)
by Adam Back 06 Jul '18

06 Jul '18

vs the other things malware does it also seems like a much more benign "payload" - uses a bit more electricity! I imagine they throttle it down dynamically when the user actually does things to hide the computer slow down. (Though typically you wont notice with GPU mining unless you are playing video games). But you may notice the increased GPU fan noise and heat on mid/high range cards. Seems bitcoin mining is using 40MW of power (estimate) thats 0.025% of the amount used by US households (30,000 US households - obviously bitcoin mining is global - its just a comparative stat). Thats a lot of 55.1 bit hashcash mining those miners are doing! Bits is more human readable by my thinking from hashcash difficulty measurement and visually easy to confirm from the hash output. http://blockexplorer.com/block/00000000000001c7e0186b24825b3f2973ef6e8556bb… you can see the SHA256 output 00000000000001c7e0186b24825b3f2973ef6e8556bbc5f6a0aaadf363114fd1 has 13 hex 0 nibbles = 52 bits plus the next digit is a one 0001 in binary so thats three more - so its a 55 bit. And the difficulty parameter is measured in the number of 2^32 hashes (MAX_UINT == ~4 billion) so you can get back to it from 55.1-32=23.1 via 2^23.1 (in bc e(l(2)*23.1) ~ 9 million. Much better :) And converting GPU card mining stats into bits is also easy 400Mh (amd 7870) = 28.6. So that means I have 55.1-28.6 = 26.5 bits short (I need 2^26.5 bits to match the network hash rate). And also you can recreate the network hashrate as 2^55.1/600 (60 seconds x 10 mins per block) or subtract 9.2 as log2(600) = 9.22 so 55.1-9.2=45.9 = 2^45.9 so subtract 40 for terahash/sec = 2^5.9 = 59.7. (Except some web stats are misreporting network hash in 1000^4 rather than 1024^4). Anyway I think humans work better with massive numbers in the log scale. Adam On Wed, Apr 17, 2013 at 10:27:01PM -0400, Kevin W. Wall wrote: > You know Bitcoin must have "arrived" when this is going on. > (For that matter, I even heard Bitcoin mentioned on NPR a few > days ago.) > > As reported on IEEE Computer Society's _Computing Now_ > news site: > <http://www.computer.org/portal/web/news/home/-/blogs/skype-based-malware-fo…> _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

1 0

Re: [HacDC:Byzantium] Future paths?
by Sky- AA6AX 06 Jul '18

06 Jul '18

I agree with making it really clear and in plain language. I think that having a desktop option and labeling it as the "normal" bootup is going to be critical in most emergency operations. Otherwise some folks might even think the computer did not boot up because it just "doesn't look right." So this has to be the default option. In terms of naming, I'd call the other option "Boot to shell" or "Boot to command line" or some phrase that every one of us geeks will recognize, plus 5% of muggles will recognize, and everyone else will go for the "normal" or "desktop" boot up process without even asking what that other one means. I'm certain that in the next San Francisco earthquake we will use the Byzantium nodes not only for setting up mesh connectivity, but also as communications terminals themselves, pounding on the node keyboards just as much as on other computers. So I would still urge "boot to desktop" as the topmost and default option even if I thought there was only a 10% chance that I'd need the screen and keyboard in order to participate in chat with network users. It's worth the overhead to not have to reboot the computer if I run out of stations to type at. I pay homage to those of you who helped out in NYC and I see an important lesson there -- which is that mesh communication even if not needed by first-responders may be needed by citizens, which I think might still be a similar configuration scenario. In my tests I had to use my local Byzantium node to participate in chat because I didn't have enough machines with enough battery power to keep them all powered up all the time. In our central EOC, of course, we have standby AC power, but out in the field it's going to be iffy. I'd guess that we would set up mesh at in-the-field command posts to connect a number of machines. If first-responder channels were down, we would use amateur radio for the longer distances if we couldn't hop to some Internet connection that has survived. The standard FEMA NIMS model is well-understood here and routinely drilled. And I'd think that I'd want to have several Byzantium nodes in a command center or staging location or field command center to increase reliability and probably stretch range as well since one center might be spread out over a city block or more. Our NERT (neighborhood) assembly and staging areas are usually playgrounds or other large sites. Maybe someone can briefly point out to me whether having "more Byzantium nodes than you think you'll need" is the best way to go or not. (I suspect it is.) And I wonder what your experience is with link distance and robustness. Here in my neighborhood my computers can see lots of Wi-fi systems that are maybe 200 to 300 feet away, and a few that (astoundingly) purport to be a couple of miles away, but without involving high-gain antennas I don't know that I can link them together. Will test that out next time. -Sky On Dec 31, 2012, at 11:26 AM, Ben Mendis <ben.mendis(a)gmail.com> wrote: > * PGP Signed by an unknown key > > > On 12/30/2012 11:33 PM, haxwithaxe wrote: >>> I've copied the contents of one of the USB keys we had in Red Hook >>> into a subdirectory on Windbringer, and I'm working on turning it into >>> something that is recognizable as v0.3a (because we've made enough >>> changes to the system that it pretty much warrants a new release). >>> I'm working on the boot splash right now (which is, strangely, the >>> hardest part to get right). We should probably write a new set of >>> release notes on ByzantiumPad that explains the changes we made >>> (namely, tearing out the control panel and the network apps, and >>> describing both the autoconfiguration daemon and how interoperability >>> with the Commotion Wireless firmware works). What I'm not so sure >>> about is whether or not we should have v0.3a boot to the desktop or >>> not. This release is fully self-configuring, so once it's up, it's >>> up. There isn't a whole lot of user interaction in this release >>> because we got rid of that during the Red Hook relief operation, but >>> that also confused people ("What? That's IT?!") >> i suggest we boot to the desktop as a normal porteus live distro does >> and have firefox popup with "you're up!" or "there was a problem :(" >> >>> We could set the desktop up in v0.3a to open Firefox and display a >>> page to the effect of "Your Byzantium node is now fully operational. >>> No, seriously - it's automatically configured itself.", but the >>> question is then whether or not it's worth the use of memory and >>> compute cycles on a running X server that isn't doing anything >>> helpful. >> they will likely want to use their laptop once it's running :P >> we can always rebrand a copy of the "text mode" boot item as "powersave" :P >> > I don't know about that renaming. I think it needs to be clear that > choosing one will result in a shell-prompt that won't be useful to most > people, but the other option results in a familiar desktop with a web > browser which could be essential to many people. > > > * Unknown Key > * 0x3233ED30 > -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en. ----- 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

1 0

Re: [liberationtech] /. ITU Approves Deep Packet Inspection
by Philipp Winter 06 Jul '18

06 Jul '18

On Wed, Dec 05, 2012 at 08:28:36PM +0100, Petter Ericson wrote: > Transparent IPv4-to-IPv6 tunneling, detection of certain > forms of abuse, QoS modificaton, traffic monitoring and > shaping. > > Obviouly, these are mostly happening at a firewall or > equivalent, which is kind of the point. Very little DPI > is legitimate in core networking. I would not limit your point to core networking. DPI technology is also used by organizations at the networking edges to conduct censorship. I agree that there is some legitimate use for DPI but giving up on that is a small price to pay considering the mass surveillance and censorship which is made so easy by DPI. Looking into packet payload should be considered taboo for middle boxes. No matter where they are. Cheers, Philipp -- 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

1 0

New encryption technology closes WLAN security loopholes
by Somebody 06 Jul '18

06 Jul '18

[1] "New encryption technology closes WLAN security loopholes" Next Comm has launched new wireless LAN security technology called Key Hopping. The technology aims to close security gaps in Wired Equivalent Privacy (WEP). It uses the MD5 (message digest, version 5) algorithm that allows for rapid changes in encryption keys used, some as often as every three seconds, denying hackers the time they need to piece together an encryption pattern. SOURCE: Internet News http://www.internetnews.com/wireless/article/0,,10692_884041,00.html <Somebody's .sig> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

[liberationtech] 'crowdsourcing versus containment' workshop featuring anti-kettling app Sukey (London, UK)
by dan mcquillan 06 Jul '18

06 Jul '18

(for any London/UK folk on the list) You are invited to a workshop at Goldsmiths with @samthetechie, co-founder of anti-kettling app Sukey. Sukey is a web app that is designed to keep people safe, mobile and informed during demonstrations. It emerged the night before the student protest in November 2010 and is now being developed as an open source tool for any demonstration. In this workshop with we'll get under the hood to explore what coding & design decisions were made and why, and we'll discuss the future for Sukey in an world of #occupy movements. More broadly, what are the different ways that software can be developed for social and political movements and what are the different kinds of knowledge, organisation and information that need to be brought together in order to make such systems work well? What are the problems introduced by 'informationalising' protest and direct action and how do software and politics change when they are brought together in such ways. VENUE: Room 326, New Academic Building, Goldsmiths, University of London, New Cross, London, SE14 6NW The New Academic Building is building #2 on this campus map (PDF) and is a 5-10 minute walk from New Cross Gate or New Cross Stations. App: http://sukey.org/ Code: http://snarl.github.com/ This workshop is organised by the Centre for Cultural Studies http://www.gold.ac.uk/cultural-studies/ and the Department of Computing. http://www.gold.ac.uk/computing/ _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/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

1 0

New encryption technology closes WLAN security loopholes
by Somebody 06 Jul '18

06 Jul '18

[1] "New encryption technology closes WLAN security loopholes" Next Comm has launched new wireless LAN security technology called Key Hopping. The technology aims to close security gaps in Wired Equivalent Privacy (WEP). It uses the MD5 (message digest, version 5) algorithm that allows for rapid changes in encryption keys used, some as often as every three seconds, denying hackers the time they need to piece together an encryption pattern. SOURCE: Internet News http://www.internetnews.com/wireless/article/0,,10692_884041,00.html <Somebody's .sig> --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

[liberationtech] 'crowdsourcing versus containment' workshop featuring anti-kettling app Sukey (London, UK)
by dan mcquillan 06 Jul '18

06 Jul '18

(for any London/UK folk on the list) You are invited to a workshop at Goldsmiths with @samthetechie, co-founder of anti-kettling app Sukey. Sukey is a web app that is designed to keep people safe, mobile and informed during demonstrations. It emerged the night before the student protest in November 2010 and is now being developed as an open source tool for any demonstration. In this workshop with we'll get under the hood to explore what coding & design decisions were made and why, and we'll discuss the future for Sukey in an world of #occupy movements. More broadly, what are the different ways that software can be developed for social and political movements and what are the different kinds of knowledge, organisation and information that need to be brought together in order to make such systems work well? What are the problems introduced by 'informationalising' protest and direct action and how do software and politics change when they are brought together in such ways. VENUE: Room 326, New Academic Building, Goldsmiths, University of London, New Cross, London, SE14 6NW The New Academic Building is building #2 on this campus map (PDF) and is a 5-10 minute walk from New Cross Gate or New Cross Stations. App: http://sukey.org/ Code: http://snarl.github.com/ This workshop is organised by the Centre for Cultural Studies http://www.gold.ac.uk/cultural-studies/ and the Department of Computing. http://www.gold.ac.uk/computing/ _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/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

1 0

[tor-talk] Tor as ecommerce platform
by morristan 06 Jul '18

06 Jul '18

Silk Road reported to make $1.9 million per month, http://www.forbes.com/sites/andygreenberg/2012/08/06/black-market-drug-site… Tor Project reported to make $1.3 million per year, https://www.torproject.org/about/findoc/2010-TorProject-combined-Form990_PC… (page 3). Read carefully, Tor Project lost $17,285 in 2010 on revenues of $1.336 million. In plain english, they spent more than they received. Perhaps the Silk Road people should donate to Tor. Perhaps they should fund hidden service improvements in Tor. Perhaps both. This informs me a few things: 1. Tor is easier to use than we think, given motivation to do so. 2. 150,000 or so people use Tor for hidden services, or for silk road alone (a hidden service). 3. Tor is not profiting from hidden services. 4. Tor and hidden services are good enough for an ecommerce platform. Who will make the first profitable, legal ecommerce site on dot onion? Morris Tan Prisoner #655321 _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- 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

1 0