November 2013 - cypherpunks - lists.cpunks.org

[IP] Why The Deep Web Has Washington Worried | TIME.com
by Eugen Leitl 06 Nov '13

06 Nov '13

----- Forwarded message from David Farber <farber(a)gmail.com> ----- Date: Wed, 6 Nov 2013 11:28:54 -0500 From: David Farber <farber(a)gmail.com> To: ip <ip(a)listbox.com> Subject: [IP] Why The Deep Web Has Washington Worried | TIME.com Message-Id: <20C7D1B2-B0E0-4D39-9854-CDF2AA1EC3EA(a)gmail.com> X-Mailer: Apple Mail (2.1816) Reply-To: dave(a)farber.net http://swampland.time.com/2013/10/31/the-deep-web-has-washington-worried/ Why The Deep Web Has Washington Worried >From online drug bazaars to virtual currency tax shelters, the growing anonymous web has many corners of Washington concerned Washington has no idea what to make of the Dread Pirate Roberts. As Lev Grossman and I write in this week’s cover story, the Dread Pirate Roberts allegedly ran the Silk Road, the world’s most successful online drug bazaar, until the feds caught him earlier this month. His real name, according to a 39-page federal complaint against him, is Ross Ulbricht, 29. He supposedly took the pseudonym from a character in the movie and book, The Princess Bride. In the Silk Road, DPR, as his followers called him, created a business model for anyone wanting to sell illicit items online using free encryption software called Tor and the virtually anonymous crypto-currency Bitcoin. Though the feds have taken Silk Road offline, there are plenty of folks lining up to be the next Dread Pirate Roberts. Lev and I examine the greater implications of the Deep Web, the massive and growing anonymous area of the Internet. But from the perspective of lawmakers and law enforcement in Washington, Silk Road presents a double conundrum. It’s a blueprint for criminals the world over at a time when FBI resources are stretched thin and political will to empower government snooping has cratered. And it has created a regulatory headache in figuring how to deal with whole new currencies, tax havens and virtual online markets. While Tor is used by everyone from law enforcement to Syrian dissidents to protect valuable information, it is a double-edged sword. Many experts warn that groups ranging from the Russian mafia to international drug cartels are looking closely at the lessons learned from the Silk Road. It took the FBI more than two years of investigative work to find Ulbricht. They don’t have the resources to compete with Silicon Valley in hiring, or the tools—a long-hoped for modernization of the law governing online wiretapping is on ice in Congress thanks to Edward Snowden. ( Developing technology to fight the Deep Web, or the anonymous non-searchable web, “is not adequately funded—it’s nowhere near adequately funded,” says Marcus Thomas, former assistant director of the FBI’s technology division and now on the advisory board Subsentio, which helps companies comply with online warranted wiretaps. “Historically it was well funded, but recently especially with sequestration, it’s been hard hit. It’s always been a difficult thing to build cost benefit analysis for. How much money should you spend building a technology you may not use for a year, if ever?” Chester Wisnieski, a senior information technology security adviser at Sophos, adds that the FBI doesn’t have enough trained staff. “If you look at the FBI—how many agents do they have in cyber? Less than 200,” he said. “There’s been a very fast shift of traditional crimes moving online and don’t have skilled agents to deal with it.” The policy problem is compounded by Bitcoin, which represents another set of jurisdictional tangles for Washington. The Senate Homeland Security Committee, officials tell TIME, plans on holding hearings on Bitcoin within the month. The committee sent letters to nine federal agencies in July asking for their thoughts on Bitcoins and other virtual currencies in the hopes of developing a holistic approach to the so-called cryptocurrency that neither stifles the currency’s potential nor enables criminals to abuse it. “As with all emerging technologies, the federal government must make sure that potential threats and risks are dealt with swiftly,” Committee Chairman Tom Carper, a Delaware Democrat, and the committee’s top Republican, Tom Coburn, wrote in the letters. “However, we must also ensure that rash or uninformed actions don’t stifle a potentially valuable technology.” Bitcoin can be a force for good. “We’ve grown used to the idea that virtual transactions should be tracked because they can be; whereas Bitcoin brings anonymity back into online commerce,” says Sasha Meinrath, director of the New America Foundation’s Open Technology Institute. “It’s amazing how scary this notion is to law enforcement. But I see it as akin to trade in gold, cash transactions, and barter: not something to be feared, but simply another useful tool for commerce.” And yet, virtual currencies have a complex past. In recent years, Liberty Reserve and e-Gold both ran afoul of the law, mostly for money laundering. U.S. Immigration and Customs Enforcement seized funds from the world’s largest Bitcoin exchange, Mt. Gox, in May charging that the company was operating an unlicensed money transmitting service. Mt. Gox has since moved to put names to Bitcoin transfers and register with federal and state governments. There is about $2 billion Bitcoin in existence today. Authorities say Silk Road transactions amounted to $1.2 billion in Bitcoin. Indeed, regulators have already taken an active interest in Bitcoin. The Senate Finance Committee is looking at language to regulate virtual currencies its tax code overhaul. They’re also considering giving the IRS more money to track virtual tax havens, Senate sources tell TIME. A Government Accountability Office report in June warned that virtual currencies like Bitcoin could be abused as tax havens. New York Financial Services Superintendent Benjamin Lawsky sent subpoenas to 22 Bitcoin businesses this summer saying it was considering new regulatory guidance on virtual currencies. “If virtual currencies remain a virtual Wild west for narcotraffickers and other criminals,” he said announcing the subpoenas, “that would not only threaten our country’s national security, but also the very existence of the virtual currency industry as a legitimate business enterprise.” A Commodities Futures Trading Commissioner said his agency is looking into regulating Bitcoins as a commodity. And Treasury’s Financial Crimes Enforcement Network put out guidance in March saying Bitcoin brokers would have to follow wire service regulations—a potentially onerous requirement as each wire service must register state by state. All of this means that no one is quite sure how to handle bitcoin: is it a currency? A bond? A commodity? Should dealers be regulated like wire services or brokers? Should profits be taxed as capital gains? Few in Washington have even begun to consider these questions, and yet given the rapid growth of Bitcoin, the Deep Web and websites like the Silk Road they will surely be forced to soon. Internet users are increasingly looking for anonymity as their preferences and personal information are tracked and traded like pork belly futures. For many, the Deep Web represents a haven from those prying eyes. But, as in real life, when there’s anonymity, there are dark alleys where people will abuse it. In the physical world, should we choose it, we can live a cash-based anonymous existence. Should we be able to do so online, even if it means anyone can buy drugs, fake IDs or illicit weapons as well? These are the questions Washington must grapple with as it looks at how to regulate cyrpotcurrencies and police the Deep Web. Click here to join TIME for as little as $2.99 to read Lev Grossman and Jay Newton-Small’s full cover story on the Deep Web. ------------------------------------------- Archives: https://www.listbox.com/member/archive/247/=now RSS Feed: https://www.listbox.com/member/archive/rss/247/25094221-ddf8422b Powered by Listbox: http://www.listbox.com ----- End forwarded message -----

1 0

code & diagrams (urls)
by brian carroll 06 Nov '13

06 Nov '13

w h i t e s p a c e Codebases: Millions of lines of code (via digg.com) http://dailyinfographic.com/wp-content/uploads/2013/10/1276_lines_of_code2.… Cipher Mysteries (via zero) The latest news, views, research and reviews on uncracked historical ciphers… http://www.ciphermysteries.com/2010/07/18/a-beautiful-infinity Language of Flowers http://en.wikipedia.org/wiki/Language_of_flowers "The language of flowers, sometimes called floriography, is a means of cryptological communication through the use or arrangement of flowers. Meaning has been attributed to flowers for thousands of years, and some form of floriography has been practiced in traditional cultures throughout Europe, Asia, and the Middle East. Plants and flowers are used as symbols in the Hebrew Bible—particularly of love and lovers in the Song of Songs,[1] as an emblem for the Israelite people[2] and for the coming Messiah[3]—and of Jesus Christ in the New Testament.[4] In Western Culture, William Shakespeare ascribed emblematic meanings to flowers, especially in Hamlet, Prince of Denmark." // has me wondering what could be done with this, perhaps RNG // as if reverse crystal ball, if futuristic sensors added much moreso Little bublcam places life in spherical perspective http://phys.org/news/2013-11-bublcam-life-spherical-perspective.html ASCII Flow Diagram Tool website http://www.asciiflow.com/#Draw Codebases: Millions of lines of code (via digg.com) http://dailyinfographic.com/wp-content/uploads/2013/10/1276_lines_of_code2.… Cipher Mysteries (via zero) The latest news, views, research and reviews on uncracked historical ciphers… http://www.ciphermysteries.com/2010/07/18/a-beautiful-infinity Language of Flowers http://en.wikipedia.org/wiki/Language_of_flowers "The language of flowers, sometimes called floriography, is a means of cryptological communication through the use or arrangement of flowers. Meaning has been attributed to flowers for thousands of years, and some form of floriography has been practiced in traditional cultures throughout Europe, Asia, and the Middle East. Plants and flowers are used as symbols in the Hebrew Bible—particularly of love and lovers in the Song of Songs,[1] as an emblem for the Israelite people[2] and for the coming Messiah[3]—and of Jesus Christ in the New Testament.[4] In Western Culture, William Shakespeare ascribed emblematic meanings to flowers, especially in Hamlet, Prince of Denmark." // has me wondering what could be done with this, perhaps RNG // as if reverse crystal ball, if futuristic sensors added much moreso Little bublcam places life in spherical perspective http://phys.org/news/2013-11-bublcam-life-spherical-perspective.html ASCII Flow Diagram Tool website http://www.asciiflow.com/#Draw ☥ ☭ ☪

1 0

[liberationtech] Setting up your own app store with F-Droid
by Nathan of Guardian 06 Nov '13

06 Nov '13

Useful HOWTO and new tools package by Hans for anyone who needs to distribute their own Android software, outside of Google Play, using the excellent F-Droid.org project. Clarification from below: While the US and Google no longer restrict access from Iran, the Google Play service is still unfortunately filtered and blocked there, and is increasingly facing app-specific filtering in other parts of the world (Viber downloads for Saudi Arabia, etc.) Ultimately, this is about a need to decentralize app distribution, while doing everything we can to ensure software security and verification for end-users. More from Hans... "The Google Play Store is not available in all parts of the world, the US restricts its use in certain countries like Iran, and many countries block access to the Play Store, like China. Also, the Google Play Store tracks it users actions, reporting back to Google what apps have been installed and also run on the phone. Because of the NSA leaks, we’re seeing that governments are actively tapping into the raw data streams of Google, Yahoo, and others. So that means that the information that the Google Play Store sends back to Google is also intercepted by the NSA and other country’s agencies like it, and they in turn also share that information with other governments. Lastly, the Google Play Store is not free software, unlike the core of Android itself. It is proprietary software that Google entirely controls. F-Droid is a wonderful, free app store for Android. It is modeled after Debian or other GNU/Linux distros in that it has its own package repositories (repos) and build servers for all the apps that are part of the official OS. Like Debian and Ubuntu, you can also setup your own repos for anyone to use. Any free software can be added to the official F-Droid repos, where they are built and signed by the F-Droid server. This can be annoying because it means that your apps in F-Droid are signed by a different key than your apps in the Google Play Store. If you host your own F-Droid repo, then people can use F-Droid to install your own builds signed by your own signing key. This is a quick HOWTO for how to setup such a repository on a Debian or Ubuntu box." https://guardianproject.info/2013/11/05/setting-up-your-own-app-store-with-… -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu.

1 0

[tor-talk] Tor Weekly News — November 6th, 2013
by dope457 06 Nov '13

06 Nov '13

======================================================================== Tor Weekly News November 6th, 2013 ======================================================================== Welcome to the nineteenth issue of Tor Weekly News, the weekly newsletter that covers what is happening in the up-to-date Tor community. Tails 0.21 is out ----------------- The Tails developers anounced the 34th release [1] of the live system based on Debian and Tor that preserves the privacy and anonymity of its users. The new version fixes two holes that gave too much power to the POSIX user running the desktop: Tor control port cannot be directly accessed anymore to disallow configuration changes and IP address retrieval, and the persistence settings now requires privileged access. On top of these specific changes, the release include security fixes [2] from the Firefox 17.0.10esr release and for a few other Debian packages. More visible improvements include the ability to persist printer settings, support for running from more SD card reader types, and a panel launcher for the password manager. For the curious, more details can be found in the full changelog [3]. As with every releases: be sure to upgrade! [1] https://tails.boum.org/news/version_0.21/ [2] https://tails.boum.org/security/Numerous_security_holes_in_0.20.1/ [3] https://git-tails.immerda.ch/tails/plain/debian/changelog New Tor Browser Bundles based on Firefox 17.0.10esr --------------------------------------------------- Erinn Clark released new versions of the Tor Browser Bundle [4] on November 1st. The previously “beta” bundles have moved to the “release candidate” stage and are almost identical to the stable ones, except for the version of the tor daemon. A couple of days later, David Fifield also released updated “pluggable transport“ bundles [5]. The new bundles include all security fixes from Firefox 17.0.10esr [6], and updated versions of libpng, NoScript and HTTPS Everywhere. It also contains a handful of improvements and fixes to the Tor Browser patches. Users of older version of the Tor Browser bundles should already have been reminded to upgrade by the notification system. Don't forget about it! This should be the last bundles based on the 17 branch of Firefox as it is going to be superseded by the 24 branch as the new long-term supported version in 6 weeks. Major progress has already been made by Mike Perry and Pearl Crescent to update the Tor Browser changes and review the new code base [7]. [4] https://blog.torproject.org/blog/new-tor-browser-bundles-firefox-17010esr [5] https://blog.torproject.org/blog/pluggable-transports-bundles-2417-rc-1-pt1… [6] https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html#fire… [7] https://trac.torproject.org/projects/tor/query?keywords=~ff24-esr Monthly status reports for October 2013 --------------------------------------- The wave of regular monthly reports from Tor project members for the month of October has begun early this time to reach the tor-reports mailing-list: Damian Johnson [8], Linus Nordberg [9], Karsten Loesing [10], Philipp Winter [11], Ximin Luo [12], Lunar [13], Kelley Misata [14], Matt Pagan [15], Sherief Alaa [16], Nick Mathewson [17], Pearl Crescent [18], George Kadianakis [19], Colin Childs [20], Arlo Breault [21], and Sukhbir Singh [22]. [8] https://lists.torproject.org/pipermail/tor-reports/2013-October/000367.html [9] https://lists.torproject.org/pipermail/tor-reports/2013-October/000369.html [10] https://lists.torproject.org/pipermail/tor-reports/2013-October/000370.html [11] https://lists.torproject.org/pipermail/tor-reports/2013-November/000371.html [12] https://lists.torproject.org/pipermail/tor-reports/2013-November/000372.html [13] https://lists.torproject.org/pipermail/tor-reports/2013-November/000373.html [14] https://lists.torproject.org/pipermail/tor-reports/2013-November/000374.html [15] https://lists.torproject.org/pipermail/tor-reports/2013-November/000375.html [16] https://lists.torproject.org/pipermail/tor-reports/2013-November/000376.html [17] https://lists.torproject.org/pipermail/tor-reports/2013-November/000377.html [18] https://lists.torproject.org/pipermail/tor-reports/2013-November/000378.html [19] https://lists.torproject.org/pipermail/tor-reports/2013-November/000379.html [20] https://lists.torproject.org/pipermail/tor-reports/2013-November/000380.html [21] https://lists.torproject.org/pipermail/tor-reports/2013-November/000381.html [22] https://lists.torproject.org/pipermail/tor-reports/2013-November/000382.html Tor Help Desk Roundup --------------------- One person asked why the lock icon on the Tor Project's website was not outlined in green. Sites that use HTTPS can purchase different types of SSL certificates. Some certificate issuers offer certificates that supply ownership information, such as the physical address of the website operator, for a higher price. Sites that use these certificates get the lock icon by their URL outlined in green. The Tor Project adds protection to the validity of our SSL certificate a different way, by supplying our SSL certificate fingerprint on our FAQ page [23]. You can double check that fingerprint on any of the Tor Project's mirror pages as well [24]. One person wanted to known why a website they were visiting over Firefox was telling them that they were not using Tor, even though Vidalia told them that Tor was running. By default, the Tor Browser Bundle does not anonymize all the traffic on your computer. Only the traffic you send through the Tor Browser Bundle will be anonymized. If you have Firefox and the Tor Browser open at the same time, the traffic you send through Firefox will not be anonymous. Using Firefox and Tor Browser Bundle at the same time is not a great idea because the two interfaces are almost identical, and it is easy to get the two browsers mixed up, even if you know what you are doing. [23] https://www.torproject.org/docs/faq.html.en#SSLcertfingerprint [24] https://torproject.org/getinvolved/mirrors.html.en Miscellaneous news ------------------ The third beta release of TorBirdy has been released [25] as version 0.1.2. Among several other fixes and improvements it restores proper usage of Tor when used with Thunderbird 24. Be sure to upgrade [26]! [25] https://blog.torproject.org/blog/torbirdy-012-our-third-beta-release [26] https://www.torproject.org/dist/torbirdy/torbirdy-0.1.2.xpi starlight reported [27] on running a Tor relays with the daemon compiled with the AddressSanitizer [28] memory error detector available since GCC 4.8 [27] https://lists.torproject.org/pipermail/tor-relays/2013-October/003187.html [28] https://code.google.com/p/address-sanitizer/ Isis Lovecruft has sent two proposals [29] for improvements to BridgeDB. One is finished and addresses the switch to a “Distributed Database System and RDBMS”. The second is still in draft stage and “specifies a system for social distribution of the centrally-stored bridges within BridgeDB”. [29] https://lists.torproject.org/pipermail/tor-dev/2013-November/005713.html Karsten Loesing announced [30] the availability of a new tech report he wrote with Steven J. Murdoch, and Rob Jansen: “Evaluation of a libutp- based Tor Datagram Implementation” [31]. Be sure to have a look if you are interested in one of the “promising approach to overcome Tor’s performance-related problems”. [30] https://lists.torproject.org/pipermail/tor-dev/2013-October/005700.html [31] https://research.torproject.org/techreports/libutp-2013-10-30.pdf SiNA Rabbani has been asking [32] for comments on two documents he wrote about how use cases and design of a “point-and-click” hidden service blogging tool, as part of the Cute Otter project [33]. [32] https://lists.torproject.org/pipermail/tor-dev/2013-October/005703.html [33] https://trac.torproject.org/projects/tor/attachment/wiki/org/sponsors/Otter… David Goulet released third rc of Torsocks 2.0.0 [34] with a lot of fixes and improvements. Available to download from GitHub [35] and also as Debian package from the experimental distribution [36]. [34] https://lists.torproject.org/pipermail/tor-dev/2013-November/005728.html [35] https://github.com/dgoulet/torsocks/archive/v2.0.0-rc3.tar.gz [36] http://packages.debian.org/experimental/torsocks Christian is working on a new round of improvements for Globe [37], a web application to learn about relays and bridges of the Tor network. The project seems close to be mature enough to replace Atlas [38] according to some. [37] https://lists.torproject.org/pipermail/tor-dev/2013-November/005725.html [38] https://lists.torproject.org/pipermail/tor-dev/2013-November/005735.html A discussion on the tor-relays mailing list prompted Roger Dingledine to ask about changing the current default exit policy [39] of the tor daemon. The current “restricted exit node” policy has been in place since 2003. As this has surprised some operators, switching the default policy to “middle node” is under consideration. [39] https://lists.torproject.org/pipermail/tor-relays/2013-November/003240.html Upcoming events --------------- Nov 05-07 | 20th ACM Conference on Computer and Communications Security | Berlin, Germany | http://www.sigsac.org/ccs/CCS2013/ | Dec 27-30 | Tor @ 30th Chaos Communication Congress | Hamburg, Germany | https://events.ccc.de/congress/2013/ This issue of Tor Weekly News has been assembled by Lunar, dope457, Matt Pagan, and Philipp Winter. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [40], write down your name and subscribe to the team mailing list [41] if you want to get involved! [40] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [41] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

1 0

[Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
by Matt Corallo 06 Nov '13

06 Nov '13

Recently, there has been a reasonable amount of discussion about the continued fragility of the public Bitcoin network on IRC and elsewhere (1). To this extent, I'm organizing a system of peering between nodes in the network by creating a system of high-speed relay nodes for miners and merchants/exchanges. This system will a) act as a fallback in the case that the public Bitcoin network encounters issues and b) decrease block propagation times between miners. It is NOT designed to in any way replace or decrease the need for the public Bitcoin P2P network. It is NOT any kind of attempt at centralization, and I still encourage interested parties to establish their own private peering agreements with large miners as needed. Currently the network consists of one specially-designed relay node, but I hope to bring more online in the coming days. This network is open to everyone via a few public relay nodes, but also will have nodes which are made available only to large miners and merchants/exchanges to mitigate the ability of malicious parties to DoS the network. To peer with the public relay nodes, simply select the closest region out of us-west (West Coast US), us-east (East Coast US), eu (Western Europe), au (Australia), or jpy (Japan) and add public.REGION.relay.mattcorallo.com to your addnode list. Note that since all of the relay nodes will relay between each other, you gain no latency advantage by peering with more than the closest node to you (and currently all the regions map to one node, so there they're redundant anyway). For each relay node, you can connect to either port 8334 or 8335. Connecting on port 8334 will relay only blocks, and port 8335 will relay both blocks and transactions. The relay nodes will request any transactions which appear in your invs no matter which port you connect to. Relay node details: * The relay nodes do some data verification to prevent DoS, but in order to keep relay fast, they do not fully verify the data they are relaying, thus YOU SHOULD NEVER mine a block building on top of a relayed block without fully checking it with your own bitcoin validator (as you would any other block relayed from the P2P network). * The relay nodes do not follow the standard inv-getdata-tx/block flow, but instead relay transactions/blocks immediately after they have done their cursory verification. They do keep some track of whether or not your nodes claim to have seen the transactions/blocks before relaying, but you may see transactions/blocks being sent which you already have and have not requested, if this is a problem for you due to bandwith issues, you should reconsider your bandwith constraints and/or are peering with too many nodes. * The relay nodes will all relay among themselves very quickly, so there is no advantage to peering with as many relay nodes as you can find, in fact, the increased incoming bandwidth during block relay spikes may result in higher latency for your nodes. * The relay nodes are NOT designed to ensure that you never miss data, and may fail to relay some transactions. Additionally, because the relay nodes do not respond to standard getdata requests, if you miss a relay and then reconnect, that data will not be sent again by the relay nodes. The relay nodes are NOT a replacement for having peers on the standard P2P network, they are only there to augment the existing P2P network. If you are a merchant/exchange/large miner/other important node operator and wish to gain access to additional domain names which map to relay nodes with fewer peers, please fill out the form at https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8… You can find the source for the relay nodes at https://github.com/TheBlueMatt/RelayNode If you have any comments/concerns/suggestions, please do not hesitate to email bitcoin-peering(a)mattcorallo.com Thanks, Matt (1) There has been extended discussion on #bitcoin-wizards as well as #bitcoin-dev of the very small number of active, listening nodes. Additionally, because many of those nodes are versions prior to 0.8.4, it seems very likely that maliciously creating network splits or at least drastically reducing the number of peers for most nodes would not be particularly challenging in the current network. Also, http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041… noted that they were able to single-handledly decrease the network-wide orphan rate by around 50% by improving network peering. Finally, you've all seen the recent discussion on malicious mining algorithms. Though those are not entirely prevented by reducing block propagation times, they can be significantly limited compared to the current, rather disjoint, network. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

1 0

[Bitcoin-development] we can all relax now
by kjj 06 Nov '13

06 Nov '13

One of the things that really gets me going is when someone devises a model, tests it against itself, and then pretends that they've learned something about the real world. Naturally, the Selfish Mining paper is exactly this sort of nonsense. Their model is one with no latency, and one where the attacker has total visibility across the network. An iterated FSM is not a suitable simulation of the bitcoin system. The bitcoin network does not have states, and to the extent that you can pretend that we do, you can't simulate transitions between them with static probabilities. The authors understand this deep down inside, even though they didn't work out the implications. They handwave the issue by assuming a total sybil attack, and in true academic spirit, they don't realize that the condition necessary for the attack is far, far worse than the attack itself. Greg said he'd like to run some simulations, and I'm thinking about it too. Unfortunately, he is busy all week, and I'm lazy (and also busy for most of tomorrow). If neither of us get to it first, I'm willing to pitch in 1 BTC as a bounty for building a general bitcoin network simulator framework. The simulator should be able to account for latency between nodes, and ideally within a node. It needs to be able to simulate an attacker that owns varying fractions of the network, and make decisions based only on what the attacker actually knows. It needs to be able to simulate this "attack" and should be generic enough to be easily modified for other crazy schemes. (Bounty offer is serious, but expires in one year [based on the earliest timestamp that my mail server puts on this email], and /may/ be subject to change if the price on any reputable exchange breaks 1000 USD per BTC in that period.) Basically, the lack of a decent network simulator is what allowed this paper to get press. If the author had been able to see the importance of the stuff he was ignoring, we wouldn't be wasting so much time correcting him (and sadly the reporters that have no way to check his claims). https://bitcointalk.org/index.php?topic=324413.msg3495663#msg3495663 ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

1 0

Re: [Cryptography] randomness +- entropy
by Jerry Leichter 05 Nov '13

05 Nov '13

On Nov 4, 2013, at 2:21 PM, John Denker wrote: > Some people have been throwing around the word "entropy" > rather carelessly. > > Entropy means something very special. Well, yes, and in its technical definitions - either in thermodynamics where it arose or information theory where it was imported because of a similarity in formalisms - it plays virtually no role in cryptographic discussion. In cryptography, especially when discussing random number generators, the word has a loosy-goosy meaning that's somehow tied to lack of predictability - but in an unspecified way. When people make it a regular habit to "guess" the entropy of various processes and then go on to build systems based on guesses, you know the word has lost any formal meaning it ever had. While the distinctions you draw are valid and important, I'm afraid "entropy" no longer has the capability to distinguish them. > For a great many cryptological purposes, a high-quality > PSEUDO-random distribution is good enough, even though its > entropy density is very low. Note the contrast: > > TRNG entropy density = 1 - epsilon > PRNG entropy density = epsilon I don't know what this means. > As another way of emphasizing the distinction: a PRNG places > orders-of-magnitude harsher demands on the strength of the > cryptological primitives it uses. I don't know what *this* means either. I drew a distinction in an earlier post - a distinction you can find in many papers on cryptographic primitives - between random values (unpredictable to the attackers being considered) and nonces (never repeated in a given cryptographic context, but there are no assumptions about unpredictability). Where a random n-bit value is specified, I can think of no paper that does not assume what we call "n bits of entropy" - though a better way to say it is "a value chosen uniformly at random from the set of n-bit strings". Sometimes the value is supposed to be chosen uniformly at random from some other set - e.g., from Z/p, i.e., between 0 and p-1. Trying to state this in terms of entropy is a losing game - and in fact it isn't actually trivial, given a random *bit* source, to produce such a distribution. People have gotten it wrong in the past. (The obvious technique of choosing a k with 2^k > p, choosing a "random" k-bit value, and the n reducing it mod p, if described in terms of "entropy", looks fine - I have k bits of entropy, which is more than enough to cover the choice I need to make. But the output is biased.) > This can be quantified > in terms of classical cryptologic ideas such as unicity > distance, but for present purposes I prefer the "entropy > density" language. "Unicity distance" is a nice but different concept - and one with little bearing on cryptography today. (If I draw a cipher E at random from some a collection of functions - e.g., by choosing a key - then the unicity distance is the unicity distance is just the number of pairs (x, E(x)) that specify E uniquely within the set. I suppose you can stretch this to talk about how many samples from the "random" generator are needed to specify *it* uniquely - i.e., be able to determine all past and future states - but I've seen the term used that way.) A broader - hence more useful - classical term (which may have been introduced by Shannon) is "equivocation". I don't recall the formal definition, but it attempts to capture the uncertainty an attacker has about the next plaintext, given all the information he already has. If I know a message was encrypted using a one-time pad, my uncertainty about the first character is not absolute - it's much more likely to be "t" than "z". T o provide information-theoretic security, a one-time-pad must contain "enough randomness" to keep my a priori and a postiori equivocation equal. This *is* something that can be given in terms of the entropies of the message and one-time-pad sources, but the deracinated notion of "entropy" one sees in most discussions is way too weak to say anything useful here.) > The rubber meets the road here: Consider the contrast: > > PRNG: I am quite sure that on startup the machine needs to > have on board a crypographically strong, well-seeded PRNG. > This needs to be up and running very, very early in the > boot-up process. Some things that need the PRNG cannot > wait. > > TRNG: At the moment I have no firm opinions as to how much > actual entropy the machine needs on start-up. I look > forward to having a discussion on this topic, with use-case > scenarios et cetera. A BBS generator is "indistinguishable" from a true random number generator. What's missing from that statement - and from the distinction you're drawing above - is a specification of the attack model. The BBS generator has inherent limitations that are given in its proof of correctness: The attacker has polynomially bounded resources (in fact, "attacker" literally means a polynomially-bounded probabilistic TM), which in turn implies that it only has access to a polynomially-bounded number of outputs. These are generally fine. The proof doesn't bother to state (though it's implicit) the obvious: That the attacker doesn't have access to the internal state of the generator. This isn't an "entropy" assumption - the internal state must, to the attacker, appear to have been chosen uniformly at random from all possible internal states, and is not available to the attacker. If you want to use "entropy-talk", all the entropy in a BBS generator is there, at the start, in the choice of the initial state. And yet there's a profound difference between the output of a BBS generator and the output of, say, a linear congruential PRNG starting with exactly the same state. One is pr edictable given a few successive samples; the other is secure given any polynomially-bounded number of them. "Entropy" simply cannot capture this distinction. And it's in fact exactly the distinction - in the transition from Shannon's classic notions of information-based security to modern computability-based ones - that make it possible to say anything useful at all about encryption algorithms other than one-time-pads. While we have no proofs like those for BBS for PRNG's built on practical cryptographic primitives, we generally assume that they have similar properties. (More correctly, we can prove some properties given assumptions about others. But those are the same assumptions we make about the actual encryption and hashing and signature algorithms we use. If they fail, the whole system falls down regardless of the source of "random" values.) To summarize: The distinction between cryptographic PRNG's and "true" RNG's has to do with the attack model. The attacker considered in the former is polynomially bounded (OK) and doesn't receive as input some special piece that we label "internal state" (this one can be violated). The attacker against a "true" RNG is ... what? Formalizing that is equivalent to formalizing randomness - which no one has managed to do. (In fact, modern developments of probability theory don't even try - random distributions are simply among the axioms. Even more, if you believe John Conway, the "Free Will" Theorem he and he and Simon Kochen proved show that "quantum unpredictability" is *stronger* than randomness!) In practical cryptography, this translates into "whatever I can imagine". In my other thread on plausible attacks, I tried to focus on limiting the attacker to, well, plausible operations in a particular real-world setting. If you *don't* do that, you can make no progress at all. A hardware generator - even Turbid - is vulnerable if I include as plausible an attacker who's infiltrated every supplier of electronic components in the world and has slipped a small transmitter into everything built, including every diode, resistor - hell, maybe every piece of wire! I have no problem with designing strong, practical random number generators. I'd love to see them deployed more widely. But clever designs of low-level primitives, as important as they are, are not a substitute for *system* designs; in fact, they can blind us to the necessary system properties. If a cryptographic primitive needs some unpredictable input, we need to go further and ask (a) how much? (b) unpredictable under what attack model? Only then can we begin to answer the *system* design question of "what's a suitable generator for such inputs?" If we can, for a reasonable cost (measured in any appropriate way), get our hands on a generator whose attack model assumes way more attacker resources than attacks on multiple uses of those values - great, let's make use of it. Too much discussion of "random number generators" is the equivalent of "I'm not sure AES is strong enough, so I'll do a ROT-13 encoding first - it can't hurt". And it can't - until you run into Tony Hoare's comment to the effect that "You can make a system so simple that you can see at a glance that it's correct, or so complex that you can't see at a glance that it's *not* correct." -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

2 1

key challenge results
by coderman 05 Nov '13

05 Nov '13

vast majority of players (63*) were able to encrypt to my key even though the email address did not match. (no address would, nor could you query a key server for it) this is a much better result than i expected, as some "friendly" clients have trouble encrypting without an email match. the onion reference a ruse, misdirection. hidden services not required to encrypt ;) same for invalid creation date, however, i'd love to know if anyone had a client complain on create date. as for the rest, i did enjoy the quotation discussion tangent! best regards, --- *unofficial tally: 63 successful players 3 failed attempts 1 anon recipient (extra credit :) clients (unverified) including: GnuPG, BCPG, OpenPGP.js, Why do you need to know? on platforms spanning Linux, BSD, Windows, OSX.

1 0

[Cryptography] Embedded device key generation problems due to bad PRNGs
by Bill Frantz 05 Nov '13

05 Nov '13

<https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic…> describes net scans for bad RSA keys on the web performed by Zakir Durumeric, Eric Wustrow, Alex Halderman, and Nadia Heninger. Among their conclusions: We manually verified that 59,000 duplicate keys were repeated due to entropy problems, representing 1% of all certificates, or 2.6% of self-signed certificates. We also found that 585,000 certificates, or 4.6% of all devices used the default certificates pre-installed on embedded devices. More surprisingly, we discovered that entropy problems can allow a remote attacker with no special access to factor a significant fraction of the RSA keys in use on the Internet. We were able to factor 0.4% of the RSA keys in our SSL scan. We did this by computing the greatest common divisor (GCD) of all pairs of moduli from RSA public keys on the Internet. However, there’s no need to panic as this problem mainly affects various kinds of embedded devices such as routers and VPN devices, not full-blown web servers. The list of vulnerable devices that we have already identified includes more than thirty different manufacturers, including almost all of the biggest names in the computer hardware industry. The kinds of products that we identified include firewalls, routers, VPN devices, remote server administration devices, printers, projectors, and VOIP phones. This is a problem, but it’s not something that average users need to worry about just yet. However, embedded device manufacturers have a lot of work to do, and some system administrators should be concerned. This is a wake-up call to the security community, and a reminder to all of how security vulnerabilities can sometimes be hiding in plain sight. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Airline peanut bag: "Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345 Englewood Ave www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032 _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [Cryptography] randomness +- entropy
by Theodore Ts'o 05 Nov '13

05 Nov '13

On Mon, Nov 04, 2013 at 12:21:00PM -0700, John Denker wrote: > > FWIW note that current Linux distros make no attempt to > provide a reservoir of true-randomly distributed bits for > use at the next startup. There are some efforts toward > storing a seed for the kernel PRNG, but the stored seed is > itself pseudo-randomly generated, and the kernel correctly > attributes zero entropy to it. One of the reasons why we don't attempt to extract "true random bits" and save them across a reboot is that even we had such bits that were secure even if the underlying crypto primitives were compromised to a fare-thee-well, once you write them to the file on the hard drive and the OS gets shut down, there's no guarantee that an adversary might not be able to read the bits while the OS is shut down. Even if you don't do something truly stupid (such as leaving your laptop unattended in a hotel room while visiting China), the risk of having your "true random bits" stolen is probably higher than the cryptographic primitives getting compromised. That's probably one of the reasons why people tend to not necessarily worry about the difference between a CSRNG and a TRNG in practice. For example, these are the people who believe that we should just replace Linux's /dev/random with a Fortuna RNG which doesn't even pretend to try to track entropy estimates, and which fundamentally assumes that the underlying crypto algorithms are secure, or at least, not the weakest link to worry about. (Again, realistically, the chances that your OS kernel has some 0-day vulnerability that the NSA's Tailored Access Operations folks have purchased from some black hat is probably a bigger risk than there being a cryptographic weakness in AES or SHA that is exploitable given the how we are using the encryption or crypto hash in Yarrow, Fortuna or Linux's /dev/random.) I still think it's worth it to have a /dev/random where we attempt to make an estimate of the entropy that we've collected and then later dispensed. But I recognize that from a engineering perspective, the distinction is not going to be that important for many people who are interested in practical security issues. Regards, - Ted _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0