- cypherpunks - lists.cpunks.org

Re: The Compromised Internet
by John Young 25 Sep '13

25 Sep '13

Yes, along those lines. Free of the totally seductively entrapping internet and monomanical PK promiscuity. The slew of innovations to milk the internet and crypto are way stations toward surpassing vulns of both used in concert. Both mutually delude. Each might lead to better alone, paired with different and less familiar means. At 04:29 PM 9/25/2013, you wrote: >Free and Open 4G radios/base stations are actually quite exciting >for this reason. The thing which actually prevents mesh networks >from working is mathematical: past a certain network size, path >finding becomes too computationally expensive, so wifi based mesh >networks can only cover a certain radius before they stop working. >With the 4G spectrum, however, the distances between hops vastly >increases, meaning that city-wide mesh networks can grow and remain >performant. This allows for free communication and file transfer >without centralized authorities. Obviously there are still threats, >but there is a lot of freedom gained from network autonomy.

1 0

Re: [cryptography] The Compromised Internet
by John Young 25 Sep '13

25 Sep '13

At 04:36 PM 9/25/2013, you wrote: > What threat are you trying to prevent that isn't already solved > by the use of cryptography alone? Transceiver vulnerabilities of the Internet, seemingly inherently insecure by design. So looking for possibilities of moving encrypted goods by other means not betrayed by faulty shipment and addled by ubiquity and familiarity. Not that that is original by any stretch, wizards are jawing about a new internet, secure by design. May take a while, so workarounds of the present piece of carrion might be useful. Not to overlook a new-fangled Snowden loosening the controls of comsec technology beyond his and our PK-packet-tech era comprehension. So beyond mathematically-enthroned encryption what lies awaiting disclosure. Oldies might suffice if dutifully studied and elaborted. Thus the reference to NSA's backroom of pre-internet-PK comsec tech which could be in the forefront, cutting/bleeding edge.

1 0

Re: [guardian-dev] APK signing keys are vulnerable WAS: pgp, nsa, rsa
by Eugen Leitl 25 Sep '13

25 Sep '13

----- Forwarded message from Hans-Christoph Steiner <hans(a)guardianproject.info> ----- Date: Wed, 25 Sep 2013 16:19:58 -0400 From: Hans-Christoph Steiner <hans(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Re: [guardian-dev] APK signing keys are vulnerable WAS: pgp, nsa, rsa Organization: The Guardian Project User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Also, we should document how to generate a good signing key. Pd0x just recommended this in #guardianproject: keytool -genkey -v -keystore test.keystore -alias testkey -keyalg RSA -keysize 8192 -sigalg SHA256withRSA -dname "cn=Test,ou=Test,c=CA" -validity 10000' .hc On 09/23/2013 03:15 PM, Natanael wrote: > How are you planning on doing it? Will you let the old app notify the user > about having to install a new app, maybe pointing to Google Play or > offering a direct download? After verifying that the import worked, you can > also offer to open the app details in Android for the old app so quick > uninstallation is easy. Have you written down the details anywhere yet? I'd > like to see how you're planning on doing it. > > Den 23 sep 2013 20:44 skrev "Abel Luck" <abel(a)guardianproject.info>: >> >> Yup, we just outlined this process in IRC :) >> >> Anyone have a snippet of Java that lets an app check another app's >> signing key? >> >> ~abel >> >> >> Natanael: >>> I can only see one option that is plausible - update the old app, signed >>> with the old key, to be able to export it's data. You can't install a > new >>> app in the place of the old one and just keep data, Android will require >>> that you uninstall the old app before you install the new one if their >>> package names are identical but signing keys differ. >>> >>> To improve security for the data transfer to some degree, we could use >>> Intents to let the new app request the data from the old app, and > ideally >>> the old app would verify which key the new app is signed with, and > prompt >>> the user for authorization. Then the user would only need to install the >>> new app, open it and select "Import from the old app", click OK, and > then >>> uninstall the old app. >>> Den 23 sep 2013 19:47 skrev "Abel Luck" <abel(a)guardianproject.info>: >>> >>>> Daniel McCarney: >>>>>> Wow, that is bad news indeed. It would be awesome to have >>>> androidobservatory.org also display full info about the signing keys, >>>> like the algorithm used, the bitness, generation date, etc. so we can >>>> easily check which keys are vulnerable. >>>>> >>>>> Working on rolling that functionality out. I had to rewrite the app >>>> import >>>>> pipeline so that I could store that information. I have the data >>>> collected but >>>>> it isn't user facing yet. I can tell you that looking at the ~6,000 >>>> unique >>>>> certificates in the observatory data about 75% are RSA 1024. >>>>> >>>>> As far as I'm aware it isn't possible to learn the key generation date >>>> from the >>>>> certificate data in the PKCS7 structure stored in the META-INF > directory >>>> of an >>>>> APK. >>>>> >>>>>> I figure if the NSA can break 1024 bit RSA, its only a matter of time >>>> before China also has that capability. China are experts at industrial >>>> espionage, and they certainly know how to make chips. It is very >>>> conceivable that they could acquire the NSA's RSA cracking chip design > and >>>> then build it domestically. Then I imagine that China would also be >>>> willing to sell those chips to allies, or perhaps even the highest > bidder. >>>>> >>>>> Yeah, the current NIST[1] advice on key sizes is very clear that 1024 >>>> bit RSA >>>>> should be deprecated (though evidently NIST might not be an unbiased >>>> source of >>>>> information...). >>>>> >>>>>> We'll have to make sure our signing key is not 1024 bit, and if so, >>>> work on a migration plan. The easiest way to start is to sign all new > apps >>>> with a new key. >>>>> >>>>> The pubkey in the cert used for the core Guardian Properties > (ChatSecure, >>>>> Obscuracam, etc) is definitely 1024 RSA. So is the pubkey in the cert >>>> used for >>>>> Orweb. It would definitely be a good idea to start talking about >>>> migration >>>>> plan, (and using a strong keysize in a new cert for all new > properties) >>>>> >>>>> - Dan >>>>> >>>> >>>> Hm, this seems quite important. Is there any established docs on how to >>>> perform a key migration without data loss? >>>> >>>> Also, I think we should make a blog post advisory out of this. >>>> >>>> ~abel >>>> >>>> _______________________________________________ >>>> Guardian-dev mailing list >>>> >>>> Post: Guardian-dev(a)lists.mayfirst.org >>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >>>> >>>> To Unsubscribe >>>> Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org >>>> Or visit: >>>> > https://lists.mayfirst.org/mailman/options/guardian-dev/natanael.l%40gmail.… >>>> >>>> You are subscribed as: natanael.l(a)gmail.com > > > > _______________________________________________ > Guardian-dev mailing list > > Post: Guardian-dev(a)lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org > Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproj… > > You are subscribed as: hans(a)guardianproject.info > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

DARK WALLET: A RADICAL WAY TO BITCOIN
by Eugen Leitl 25 Sep '13

25 Sep '13

"radical", huh. http://www.newyorker.com/online/blogs/currency/2013/09/dark-wallet-bitcoin.… DARK WALLET: A RADICAL WAY TO BITCOIN POSTED BY MICHAEL DEL CASTILLO Cody Wilson is a twenty-five-year-old former law student at the University of Texas at Austin. He is also the inventor of the Liberator, a gun made almost entirely from plastic pieces created with a 3-D printer; he also uploaded to the Internet a blueprint that anyone could use to print such a gun. Wilson, who espouses libertarian views, created the blueprint to make a point: information should be free. Not everyone agreed with him. In May, after Wilson successfully fired the gun at a range near Austin and posted the design online, the State Department requested that those files be removed from the Web site of his nonprofit, Defense Distributed. Wilson complied—but not before the files had been downloaded two hundred thousand times, igniting a debate about whether there should be limits to the free flow of information over the Internet, and over the role of the government in enforcing those restrictions. Wilson lives in “a utopian world in which contraband will be only a notional concept, because enforcement will require policing ideas and blueprints, not simply goods,” Jacob Silverman wrote in a piece about Wilson and the Liberator in May. A native of Cabot, Arkansas—a small suburb of Little Rock—Wilson said that the State Department’s action persuaded him to drop out of law school and pursue revolutionary activities full-time. In fact, he had been planning his next endeavor for a while. When Indiegogo, a crowdfunding site, booted Defense Distributed’s campaign in August, 2012, for violating its terms of service—Indiegogo said the project related to the sale of firearms; Wilson said it was for the creation of information—Wilson began to raise money by asking people to support him using a currency called Bitcoin: encrypted, difficult-to-trace bits of code that function like cash and can be exchanged over the Internet without a bank or a PayPal account. Wilson said that he eventually raised two hundred bitcoins for the Liberator—the equivalent of twenty-seven thousand dollars, according to the current exchange rate. His efforts attracted the attention of a twenty-five-year-old Brit named Amir Taaki, who e-mailed him with an invitation to speak at the Bitcoin 2012 Conference, in London. He accepted. Wilson and Taaki met in person for the first time in January of 2013, when Taaki took Wilson to visit a workspace for hackers is Bratislava, Slovakia, and to anarchist squats in London. They reconnected in Berlin that July and began hashing out a plan to use the as of yet unregulated, untaxed, nearly untraceable currency in a way that would, like the Liberator, undermine the ability of governments to regulate the activities of their citizens. In the Bitcoin world, where banks no longer serve as intermediaries between people and their money, bank accounts have been replaced by online “wallets” that people can use to virtually store and send bitcoins. Wilson and Taaki’s project, tentatively known as Dark Wallet, is a simple wallet designed to be easier to use for people who aren’t tech-savvy; they hope that in turn accelerates the currency’s rate of adoption around the world. The wallet will be open-source and free to use. Eventually, Wilson and Taaki hope to create a vast stable of Bitcoin-related tools. The goal, for Wilson, is similar to what he tried to do with the Liberator: use technology to remove government intervention from his life, and from the lives of like-minded people. Unlike many current Bitcoin wallets, which can be difficult to download and cumbersome to use, Wilson and Taaki are designing Dark Wallet, they told me, as an easy-to-install plug-in that sits discreetly on users’ Chrome or Firefox browsers. Made for Windows, Mac, and Linux computers, Dark Wallet would move most of the energy-sucking process of insuring there’s only one of each bitcoin in circulation, and that they aren’t spent in two places at the same time, to separate servers. Wilson still lives in Austin, working remotely on Dark Wallet with Taaki, who lives in an anarchist compound called Calafou, outside of Barcelona, and writes most of the code behind the wallet. Taaki and Vitalik Buterin, the co-founder of Bitcoin Magazine, a periodical covering the currency, are part of a Calafou-based organization called unSystem, which came up with the idea for the wallet; they’re working with a team of developers from around the world. Wilson, who will manage the development team behind Dark Wallet, making sure they meet their targets on time, is also producing a video and other material for a crowdfunding campaign to raise money for the project. Dark Wallet should be ready sometime in January or February of 2014, Taaki said, though he’s not committing to anything. “It’ll launch when it’s ready,” he said. And the details of an upcoming crowdfunding campaign have still yet to be solidified, though Taaki and Wilson expect it to launch sometime in October. The person or group that, in 2008, created Bitcoin—that is, released the protocol that defined what Bitcoin would be—called itself Satoshi Nakamoto. The online comments that Satoshi Nakamoto made before disappearing completely, in 2012, indicate that the creator of Bitcoin, like Wilson, was deeply mistrustful of economic institutions and designed the currency to be intentionally subversive. Bitcoin is created, or “mined,” as it’s called, by powerful computers that race to solve complex math problems and are rewarded for their work with the encrypted code that is a bitcoin. Today there are 11.7 million of the coins in existence, worth an estimated $1.6 billion, though their value fluctuates dramatically. Nakamoto set the number of coins entering circulation to halve every four years until 2140, when they will plateau at twenty-one million coins and never be produced again. Because no one can arbitrarily decide to print more bitcoins, and because no banks intermediate the storage and spending of the currency, the value of a bitcoin is determined by market demand. Wilson finds this very attractive. But where a currency exists, capitalism will inevitably find it. In recent months, Bitcoin has caught the attention of entrepreneurs, many funded by venture-capital firms, who have begun building Bitcoin-related start-ups. The companies include exchanges where people can trade bitcoins, along with services that let people store and spend the currency in places ranging from Amazon-style online markets to brick-and-mortar bars and restaurants. The mainstream entrepreneurs who are interested in Bitcoin have found a haven in a nonprofit called the Bitcoin Foundation. Writing about Bitcoin in April, Maria Bustillos described its executives as a “rational and sober group of adult administrators” who stand in contrast with the image of Bitcoin users as “wild-eyed kids camping out in half-deserted lofts.” Members of the foundation met in August with several federal agencies, including the Federal Reserve, the F.B.I., and the Secret Service. On the surface, the meeting was an educational exercise, meant to explain how Bitcoin works, but many observers assume it was a step toward regulating the currency. The foundation, which celebrates its first anniversary this month, calls itself an advocacy group “dedicated to serving the business, technology, government relations, and public affairs needs of the Bitcoin community.” One goal, according to Jon Matonis, its executive director of the Bitcoin Foundation, is to educate both public and private interests—including the government—about how the currency operates. (“The Foundation is not pro-regulation as some have claimed, but it is pro-education,” Matonis has written, adding that he supports “bitcoin education for legislative and regulatory entities” and that “lobbying on behalf of Bitcoin is not necessarily anti-market.”) Wilson, not surprisingly, sees working with the government as a betrayal of Bitcoin’s fundamental purpose. “The public faces of Bitcoin are acting as counter-revolutionaries,” he told me. “They’re actively working to try to diffuse it, and to pollute it.” He was referring, he said, not only to the Bitcoin Foundation but to venture capitalists and entrepreneurs in New York and Silicon Valley who increasingly embrace the currency as a way to profit, but don’t share his revolutionary aims. (Matonis said he is aware of Wilson’s concerns. “I don’t see my role as advancing crony capitalism,” he said.) Wilson believes Bitcoin should remain the backbone of a separate economy that undermines the government’s ability to collect taxes and to control the value of currency—not be subsumed into the mainstream economy. “The state is basically allowed because we have all chosen to use these certain institutions to channel our activity and commerce,” he told me. “But when we are enabled, through alternative means and technologies, to channel our commerce as we will, channel our production as we will, the state simply disappears.” Not everyone agrees, of course, that society would benefit from the disappearance of governments. Wilson used the Liberator to make the point that the government shouldn’t regulate the flow of information; he wants to use Bitcoin to help build an economy outside of the government’s reach. But his ideology, taken to its logical conclusion, would also leave services like roads, libraries, fire fighting, and policing in the hands of the private sector—whose interests may not be aligned, Wilson’s critics argue, with those of the public at large. Wilson knows that he could see blowback for his stance against the foundation: as a self-described “crypto-anarchist,” perhaps he shouldn’t be so concerned with who is or isn’t determining the currency’s future. And if the U.S. government attempts to regulate the currency, which seems likely, Wilson will also find himself once again in direct opposition to the government. Wilson and the suit-and-tie-wearing people at the Bitcoin Foundation share a common interest in bringing Bitcoin to as many people as possible. The foundation seems willing to play nicely with the establishment, and has been open to hearing about the interests of old-school players like venture capitalists and government regulators. Wilson, however, who was only recently firing an illicit gun into the desert, isn’t looking only for a new currency but for another way to liberate himself—and others—from government oversight. Michael del Castillo is the technology and innovation reporter at Upstart Business Journal, a member of American City Business Journals, which is a sister publication to Condé Nast. A graduate of Columbia University, he is also the cofounder of Literary Manhattan, a nonprofit dedicated to promoting Manhattan’s literary community and creating new ways to appreciate literature. Illustration by Grafilu.

2 1

[tor-talk] Tor Weekly News — September 25th, 2013
by Eugen Leitl 25 Sep '13

25 Sep '13

----- Forwarded message from dope457 <dope457(a)riseup.net> ----- Date: Wed, 25 Sep 2013 14:15:43 +0200 From: dope457 <dope457(a)riseup.net> To: tor-talk(a)lists.torproject.org, tor-news(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — September 25th, 2013 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News September 25th, 2013 ======================================================================== Welcome to the thirteenth issue of Tor Weekly News, the weekly newsletter that covers what's happening in the well-heeled Tor community. Reimbursement of exit operators ------------------------------- In July 2012, Roger Dingledine wrote a post on the Tor blog [1] in which he raised the prospect of offering funding to organizations running fast Tor exit nodes. In so doing, Roger wrote, “we will improve the network's diversity as well as being able to handle more users.” He also announced that donors were already interested in financing such a scheme. Then, in April this year, Moritz Bartl stated [2] that torservers.net was looking to move away from establishing additional exit nodes, in favor of providing support of various kinds to partner organizations running their own exits. These plans, and the discussion they provoked, are now about to bear fruit in the form of a financial reimbursement scheme directed at torservers.net's partner organizations. Moritz wrote again on the the tor-relays list [3] to announce that reimbursements are scheduled to begin at the end of this month, drawn from a one-time donation by the U.S. Government's Broadcasting Board of Governors. The ensuing debate focused both on the technical aspects of reimbursement — that is, how best to determine the division of funds based on information harvested from the network metrics [4] — and the question of the security issues that could potentially arise from such a scheme [5]. Moritz specified that currently the only organizations to qualify for reimbursements are those that he personally knows: “so, if you’re interested in becoming a partner, start social interaction with me”, he wrote. Questions or comments regarding these proposals are welcome on the tor-relays list, and further announcements and discussion about the reimbursement system will be published on its dedicated mailing lists [6]. [1] https://blog.torproject.org/blog/turning-funding-more-exit-relays [2] https://lists.torproject.org/pipermail/tor-relays/2013-April/001996.html [3] https://lists.torproject.org/pipermail/tor-relays/2013-September/002824.html [4] https://lists.torproject.org/pipermail/tor-relays/2013-September/002825.html [5] https://lists.torproject.org/pipermail/tor-relays/2013-September/002831.html [6] https://lists.torproject.org/pipermail/tor-relays/2013-May/002138.html Tails 0.20.1 is out ------------------- Tails saw its 33rd release on September 19th [7]. The most visible change might be the upgrade of tor to version 0.2.4.17-rc, which should result in faster and more reliable access to the network after the sudden bump in Tor clients [8]. Among other minor bugfixes and improvements, persistence volumes are now properly unmounted on shutdown. This should prevent data loss in some situations, and avoid a sometimes lengthy pause upon activation. It also fixes several important security issues [9]. It is recommended that all users upgrade as soon as possible [10]. [7] https://tails.boum.org/news/version_0.20.1/ [8] https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients [9] https://tails.boum.org/security/Numerous_security_holes_in_0.20/ [10] https://tails.boum.org/news/version_0.20.1/ New Tor Browser Bundles released -------------------------------- A new set of stable and beta Tor Browser Bundles was released [11] on September 20th. The Tor Browser is now based on Firefox 17.0.9esr and fixes several important security issues [12]. Queries for the default search engine, Startpage, are no longer subject to its invasive “family filter” [13]. The beta branch also include an updated version of HTTPS Everywhere that no longer causes a storm of requests to clients1.google.com, an issue reported by many users after the last release [14]. Once again, it is recommended that all users upgrade as soon as possible. [11] https://blog.torproject.org/blog/new-tor-browser-bundles-firefox-1709esr [12] https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html#fire… [13] https://bugs.torproject.org/8839 [14] https://bugs.torproject.org/9713 Tor mini-hackathon at GNU 30th Anniversary Celebration ------------------------------------------------------ Nick Mathewson sent an invitation [15] encouraging everyone to attend the GNU 30th Anniversary Celebration [16] on September 28th and 29th at MIT, Cambridge, MA, USA. Part of the event is a hackathon, and Tor is featured alongside a few other projects. If you want to spend some of the weekend helping the Tor community, sign up on the webpage [17] and come along! [15] https://lists.torproject.org/pipermail/tor-talk/2013-September/030154.html [16] https://gnu.org/gnu30/celebration [17] https://crm.fsf.org/civicrm/event/register?id=10 Clock skew: false alarm ----------------------- Small offsets in system time offer an attractive opportunity for fingerprinting Tor clients. In order to eliminate unnecessary exposure, Nick Mathewson has been working on proposal 222 [18]. Unfortunately, this process introduced a bug into the tor daemon which became apparent after the directory authority named “turtles” was upgraded. The result was that relays started to warn their operators of an implausible clock skew [19]. This was, of course, a false alarm. The issue was quickly worked around, and fixed properly a few hours later [20]. [18] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/pro… [19] https://lists.torproject.org/pipermail/tor-relays/2013-September/002888.html [20] https://bugs.torproject.org/9798 Tor Help Desk Roundup --------------------- One user contacted the help desk for assistance running torbrowser, an application not affiliated with the Tor Project that attempts to mimic the Tor Browser Bundle. The torbrowser application violates the Tor Project’s trademark, and the Tor Project encourages users to avoid it. Multiple Tor Project developers have contacted SourceForge, which hosts this application’s website, attempting to get the project removed. Andrew Lewman has said that lawyers have now been engaged [21]. A number of University students continued to contact the help desk to report difficulties circumventing their University’s Cyberoam firewall. These students report being unable to access the Tor network even when using the Pluggable Transports Browser with obfs3 bridges. One person reported success circumventing the firewall when using an obfsproxy bridge on port 443. This issue is ongoing, but a bug report has been filed [22]. [21] https://lists.torproject.org/pipermail/tor-talk/2013-August/029614.html [22] https://bugs.torproject.org/projects/tor/ticket/9601 Miscellaneous news ------------------ Jacob Appelbaum inquired with VUPEN about the Tor Project having the right of first refusal for Tor Browser bugs, in order to protect users [23]. [23] http://storify.com/fredericjacobs/discussion-between-tor-s-ioerror-and-vupe… The proposed Tor page on Stack Exchange has now reached 100% commitment, and will soon be launching as a live beta. Thanks to everyone who signed up! [24]. [24] http://area51.stackexchange.com/proposals/56447/tor sajolida reported on the latest Tails “low-hanging fruits session”. The date and a tentative agenda for the next online contributors meeting have also been set [25,26]. [25] https://mailman.boum.org/pipermail/tails-dev/2013-September/003703.html [26] https://mailman.boum.org/pipermail/tails-dev/2013-September/003696.html As GSoC entered its final phase, Kostas Jakeliunas reported on the searchable metrics archive [27], Johannes Fürmann on EvilGenius [28], and Cristian-Matei Toader on Tor capabilities [29]. [27] https://lists.torproject.org/pipermail/tor-dev/2013-September/005483.html [28] https://lists.torproject.org/pipermail/tor-dev/2013-September/005484.html [29] https://lists.torproject.org/pipermail/tor-dev/2013-September/005490.html How can we provide Tor users an easy way to verify the signatures on Tor software? Sherief Alaa raised this question on the tor-dev mailing list when asking for comments on plans to write a “small” GUI tool [30]. [30] https://lists.torproject.org/pipermail/tor-dev/2013-September/005491.html Upcoming events --------------- Sep 28-29 | Tor mini-hackathon at GNU 30th Anniversary Celebration | MIT, Cambridge, Massachusetts | https://gnu.org/gnu30/celebration | Sep 29 | Colin at the Winnipeg Cryptoparty | Winnipeg, Manitoba, Canada | http://wiki.skullspace.ca/index.php/CryptoParty | Sep 29-01 | Tor at OpenITP Circumvention Tech Summit IV | Berlin, Germany | https://www.openitp.org/openitp/circumvention-tech-summit.html | Sep 30 | Congress on Privacy & Surveillance | Lausanne, Switzerland | http://ic.epfl.ch/privacy-surveillance This issue of Tor Weekly News has been assembled by harmony, Lunar, dope457, Matt Pagan, and Jacob Appelbaum. 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 [31], write down your name and subscribe to the team mailing list [32] if you want to get involved! [31] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [32] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[Cryptography] Hardware Trojan Protection
by Eugen Leitl 25 Sep '13

25 Sep '13

----- Forwarded message from Bill Frantz <frantz(a)pwpconsult.com> ----- Date: Tue, 24 Sep 2013 13:36:13 -0700 From: Bill Frantz <frantz(a)pwpconsult.com> To: cryptography(a)metzdowd.com Subject: [Cryptography] Hardware Trojan Protection X-Mailer: Mailsmith 2.3.1 (422) On 9/22/13 at 6:07 PM, leichter(a)lrw.com (Jerry Leichter) wrote in another thread: > Still, it raises the question: If you can't trust your > microprocessor chips, what do you do? One possible answer: Build > yourself a processor out of MSI chips. We used to do that, not so > long ago, and got respectable performance (if not, perhaps, on > anything like today's scale). An MSI chip doesn't have enough > intrinsic computation to provide much of a hook for an attack. Oh, > sure, the hardware could be spiked - but to do *what*? Any given > type of MSI chip could go into many different points of many > different circuit topologies, and won't see enough of the data to > do much anyway. There may be some interface issues: This stuff > might not be fast enough to deal with modern memory chips. (How > would you attack a memory chip? Certainly possible if you're make > a targeted attack - you can slip in a small processor in the design > to do all kinds of nasty things. But commercial of the shelf > memory chips are built right up to the edge of what we can make, so > you can't change a > ll that much.) > > Some stuff is probably just impossible with this level of > technology. I doubt you can build a Gig-E Ethernet interface > without large-scale integration. You can certainly do the original > 10 Mb/sec - after all, people did! I have no idea if you could get > to 100 Mb/sec. > > Do people still make bit-slice chips? Are they at a low-enough > level to not be a plausible attack vector? > > You could certainly build a respectable mail server this way - > though it's probably not doing 2048-bit RSA at a usable speed. > > We've been talking about crypto (math) and coding (software). > Frankly, I, personally, have no need to worry about someone > attacking my hardware, and that's probably true of most people. > But it's *not* true of everyone. So thinking about how to build > "harder to attack" hardware is probably worth the effort. You might get a reasonable level of protection implementing the core of the crypto operations in a hardware security module (HSM) using Field Programmable Gate Arrays (FPGA) or Complex Programmable Logic Device (CPLD). There is an open source set of tools for programming these beasts based on Python called MyHDL <www.myhdl.org>. The EFF DES cracker may have some useful ideas too. The largest of these devices are also pressing the current chip limits. There isn't a lot of extra space for Trojans. In addition, knowing what to look at is somewhat difficult if pin assignments etc are changed from chip to chip at random. As with any system, there are tool chain issues. Open source helps, but there is always the Key Thompson attack. The best solution I can think of is to audit the output. Look very carefully at the output of the tool chain, and at the final piece that loads the configuration data into the device. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[DIYbio] Re: Downloading JoVE videos?
by Eugen Leitl 25 Sep '13

25 Sep '13

----- Forwarded message from code elusive <code.elusive(a)gmail.com> ----- Date: Tue, 24 Sep 2013 10:38:01 -0700 (PDT) From: code elusive <code.elusive(a)gmail.com> To: diybio(a)googlegroups.com Subject: [DIYbio] Re: Downloading JoVE videos? Reply-To: diybio(a)googlegroups.com hello :) A method to extract the full JoVE video files, using Firefox, is described below. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Extraction of full JoVE video files 1. In Firefox, open a new tab (my FF version is 23.0.1) 2. Press Ctr+Shift+K to open the Web console window (Or go from Firefox>Web developer>Web console) 3. On the web console, the following buttons must be pressed (if they are not, press them): "Net" and "Logging" 4. Paste the url of the webpage you're interested in and start playing the short video segment. >From the lines that have appeared on the web console, we want the video file links, which most probably include a .mov or .mp4 extension. 5. Once the short video segment has ended, filter the lines using the"filter output"box of the web console (next to the "clear" button) and search for .mov or .mp4. The lines with the link start as GET "http://ecsource.jove.com/CDNSource/.. " 6. Right click the appropriate line, select "copy link location" and either paste in a new tab, or download with your favorite download manager. that's it :) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Of course it is possible that an even easier method exists. I hope the explanation is clear. Let me know if I can clarify anything. For those that are interested in the video files from the links that Patrik posted, the links are: http://ecsource.jove.com/CDNSource/3740_Mahoney_Perfusion_010512_P_Web.mov http://ecsource.jove.com/CDNSource/3940_Bueter_050112_F_Web.mov http://ecsource.jove.com/CDNSource/1138_Cowan_F2.mp4 have a nice evening :) -- -- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio(a)googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe(a)googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/diybio?hl=en Learn more at www.diybio.org --- You received this message because you are subscribed to the Google Groups "DIYbio" group. To unsubscribe from this group and stop receiving emails from it, send an email to diybio+unsubscribe(a)googlegroups.com. To post to this group, send email to diybio(a)googlegroups.com. Visit this group at http://groups.google.com/group/diybio. To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/52ddb906-43b2-45a3-a223-b66a8485e3…. For more options, visit https://groups.google.com/groups/opt_out. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [p2p-hackers] BitWeav: open P2P micropublishing
by Eugen Leitl 25 Sep '13

25 Sep '13

----- Forwarded message from Liam Edwards-Playne <liamzebedee(a)yahoo.com.au> ----- Date: Wed, 25 Sep 2013 12:13:48 +1000 From: Liam Edwards-Playne <liamzebedee(a)yahoo.com.au> To: p2p-hackers(a)lists.zooko.com Subject: Re: [p2p-hackers] BitWeav: open P2P micropublishing User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Reply-To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> A good point about the SHA2-256 + RIPEMD-160 usage that I hadn't considered. I'll change the design to use a single truncated SHA2-256 hash. As for length extension attacks, I don't believe I should be concerned, should I? The transfer of messages within the network is dependent on a defined protocol, so any extra bytes would just be interpreted as a malformed message. Out of interest, could you elaborate on the potential weaknesses in the pairing? As for a decentralised identity, it's an interesting problem, but I'll be focusing on the micropublishing idea first. With my last project, I delved into too many areas, trying to decentralise DNS, creating an improved Kademlia DHT, providing a framework for P2P mutable documents. Ultimately I built nothing (but learnt a lot). Nonetheless I think technology develops too quickly to define any sort of single specification for an online identity. The best we have are public keys certified by webs of trust. Le 25/09/13 08:16, Sean Lynch a écrit : > I don't think Bitcoin's SHA2-256 + RIPEMD-160 usage is based on > sound crypto. It's not terrible but it's also a little bit silly > since a collision in SHA2-256 will be a collision in the pair, > which means all you're doing is shortening the hash while avoiding > the length extension attack. There are also potential weaknesses in > the pair that may not exist in either one due to the fact that the > pairing has not been well studied. You could accomplish the same > end with less CPU and less code by using a truncated SHA-512 hash. > > Otherwise, I tend to agree with your goals and approach, though I > think it may be more impactful to simply bring the decentralized > identity aspect of it to the web. The fact that I have no portable > identity with which to comment on or post arbitrary content around > the web is very annoying. At best, the current system could be > described as federated, but even that's not entirely true since few > sites actually support OpenID and fewer users know what their > OpenID URL is. > > > On Mon, Sep 23, 2013 at 9:48 PM, Liam Edwards-Playne > <liamzebedee(a)yahoo.com.au <mailto:liamzebedee@yahoo.com.au>> wrote: > > I've been working on a new open micropublishing network that's > entirely peer-to-peer, relying on a publish-subscribe overlay to > facilitate scalable distribution of messages on hashtags, profiles > and threads. > > You can peruse its design in this document: > http://bitweav.org/whitepaper.pdf > > Its main features: > - first of its kind to support publish/subscribe to topics > (profiles, hashtags, threads) > - doesn't use rendez-vous nodes for topics (meaning only nodes > who are subscribed to a topic will help distribute messages on it) > - message threading and replies. multilingual support. > - more scalable approach to message dissemination using rings, > rather than gossip-based flooding (see ch. 7 of whitepaper) > > I'd appreciate any constructive criticism / discussion and if > anyone would like to help I would greatly appreciate it. I'm > currently developing the frontend graphical client, afterwhich I > will progress to implementing the backend daemon. > > Cheers, > Liam Edwards-Playne. > _______________________________________________ > p2p-hackers mailing list > p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers(a)lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

<nettime> "Internet Freedom" and Post-Snowden Global Internet Governance
by Eugen Leitl 25 Sep '13

25 Sep '13

----- Forwarded message from michael gurstein <gurstein(a)gmail.com> ----- Date: Tue, 24 Sep 2013 15:37:36 -0700 From: michael gurstein <gurstein(a)gmail.com> To: Nettime-L <nettime-l(a)kein.org> Subject: <nettime> "Internet Freedom" and Post-Snowden Global Internet Governance Reply-To: a moderated mailing list for net criticism <nettime-l(a)mail.kein.org> With links http://gurstein.wordpress.com/2013/09/24/internet-freedom-and-post-snowden-g lobal-internet-governance/ http://tinyurl.com/n3onw87 "Internet Freedom" and Post-Snowden Global Internet Governance: Michael Gurstein The big story for the 2012 Internet Governance Forum in Baku was the almost overwhelming (and overpowering) emphasis placed by the US government delegation and its corporate allies (primarily Google) and its associates in (primarily US based) Civil Society on what was termed "Internet Freedom" and Multistakeholderism as its primary governance modality. The campaign was very well orchestrated and coordinated (through the US delegation led by a US Ambassador and the head of the NTIA Lawrence Strickling) who insisted that any "Internet governance" position which included any form of "government involvement" would necessarily imply or result in government's "takeover" or "control" of the Internet. Further, it was vociferously asserted that any deviation from this path was by definition an infringement of "Internet Freedom" and part of a slippery slope leading to full-on government suppression of "free speech" on the Internet. Those who pointed out that there already was quite considerable involvement of various governments in various aspects of Internet management were effectively shouted down as being sympathizers with the autocrats and enemies of "freedom" in such states as China, Russia and Saudi Arabia. The overwhelming response was that Internet "governance" was optimal as it was (or at least the corporate, (inter) governmental, and technical mechanisms governing its evolution were optimal); and that the only possible position for "lovers of the Internet" was to support the existing status quo with respect to Internet ("non") governance. Precisely what might be meant by "Internet Freedom" apart from rather fuzzy libertarian notions of keeping "the dead hand of government" as far as possible from the Internet as a hub of innovation and enterprise, was never made very clear beyond the level of slogan and exhortation. Rather it was loudly proclaimed that any form of formal governance of the Internet would be the greatest sin that could be perpetrated against the Internet as a burgeoning global infrastructure. In choosing among the various ways in which "Freedom" might be characterized this lobbying steamroller made quite clear that they were referring to Freedom "from"-government interference, government oversight, government regulation of anything to do with the Internet. And this theme and its ITU focused counterparts were equally evident at the ITU policy meeting held in Dubai some few months later (the WCIT). When some few small voices suggested that this full court press in support of "Freedom from" might also mean for example a freedom from the means for countries, particularly Less Developed Countries to introduce some form of taxation on the currently small but rapidly growing flow of Internet based revenues from already impoverished economies to already stupendously wealth private (and primarily US based) Internet corporations; or that there might be something wrong with the current way in which the basic "naming system" of the Internet via ICANN might be structured (as a sub-contractor to the US Department of Commerce); or that some issues such as privacy might require mechanisms for policy development and global enforcement, these comments were met with derision and howls that the authors of such positions were secret sympathizers of communications censors (ComSymps) of those on the other side of the emerging Internet cold war - i.e. the Russia's, China's, Saudi Arabia's of the world. But that was then and this is now and as startling revelation after revelation tumbles from the thumb drives of Mr. Edward Snowden the import if not the intent of (one hopes) certain of those Internet Freedom warriors (speculating on precisely who knew what, when, and how in this context makes for an interesting exercise) becomes clear. While so loudly advocating for Freedom "from" (whatever.), the Internet Freedom (IF) coalition was in fact, providing the diplomatic cover and lobbying campaign to ensure that no outcome of Internet governance would interfere with what would appear to be the overall US strategy of Freedom "to" - surveille, subvert, suborn and overall embed and maintain (as the NSA so aptly put it)-"total information dominance" of the Internet and all of its various manifestations now and presumably forever, in the service of US "security" and US interests. Such "security" it is clear from the Snowden documents means not only security against terrorism but also it seems (as enabled by the NSA's surveillance machine) security against potentially independent comment (and ultimately action) by both opposing and allied states; against fair competition since one side has access to all its information and the information from the other side as well; and quite startlingly the security of having the means to listen in on and ultimately control independent action, comment, commerce, and thought itself not only among "foreigners" (i.e. everyone else) but also even among those (in theory) protected by that most oft cited of documents the US constitution. That this "Freedom from" campaign has now been fully revealed for what it was (providing the ideological justification for an on-going coup d'etat against the republic of the Internet), leaves the matters of Internet Governance (where this all started) completely up in the air. But once having been revealed that we are no longer in Kansas and that the wicked witches of the North, South, East and West will be relentless in their pursuit of control including through the use of their boundless financial and technical resources; a response of some sort however reluctantly and with what trepidations seems to be in the cards as per the recent speech to the UN General Assembly by President Rousseff of Brazil. And so we have the upcoming 8th session of the Internet Governance Forum in Bali with many of the main protagonists having been more or less completely discredited (it might be fun if the same coalition were to try for another round of "Internet Freedom" confabulations but one can't imagine that even those folks have been sufficiently well trained to carry that one off with a straight face). So, what will be discussed at the IGF apart from the usual empty rhetoric about capacity building for LDC's and legitimate campaigns against online skullduggery of the spam, kiddieporn, phishing variety. Perhaps I could make a modest suggestion for the discussion. Perhaps we could discuss "Internet Freedom" but Internet Freedom in a post-Snowden world and without the hypocrisy and sanctimony of the previous discussions. Perhaps we could discuss Internet Freedom as Freedom from undue and unaccountable surveillance. Internet Freedom as true Freedom of Expression where the forces of repression whether in Langley or in Moscow or Shanghai are made transparent and accountable; where Internet Freedom is anchored in the rule of law-not the, shall we say, rather "flexible" law of the world's single superpower but a rule of law to which all are expected to adhere and where mechanisms are in place to ensure that, to the degree possible, all are responsive and accountable; where Internet Freedom is not just for some but where it's responsibilities and most importantly its protections are available for all of us - "foreigners" or no and where all have some degree of input into how those laws are constructed and administered; where Internet Freedom does not mean that actions on and through the Internet will be subverted and directed simply to further enrich the already obscenely enriched but rather to ensure that the benefits including financial benefits accruing from the Internet serve to reduce global inequalities. I look for those who a year ago, were so eager to rally forces in support of Internet Freedom to rally again to this somewhat battered standard but now one that is rather less naive and rather more reflective of the underlying reality of this technology enabled world in which we live. # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Dissentr: A High-Latency Overlay Mix Network
by Eugen Leitl 25 Sep '13

25 Sep '13

https://github.com/ShaneWilton/dissentr Note: This project was created as part of a 36-hour hackathon - and primarily as a proof of concept. While the ideas may be sound, and the prototype may work as designed, the protocols involved in this specific project have not been peer-reviewed, and so I cannot recommend that the network be used for anything requiring serious privacy. Dissentr A High-Latency Overlay Mix Network Essentially, Dissentr is a security-minded network, inspired by Tor, with a few important characteristics which serve to differentiate it. High-Latency Tor is a low-latency network. This makes it ideal for real time activities like web browsing, but as a result, opens it up to attacks involving large-scale traffic analysis methods known as end-to-end correlation. In these attacks, an adversary with the ability to analyze massive amounts of traffic in a short period of time is able to match up traffic entering the network with the corresponding traffic which will inevitably soon exit it. Dissentr manages to protect against these sorts of attacks by being engineered as a high-latency network. Assuming any given node has not been compromised, that node will intentionally hold off on forwarding its traffic to the next node in the network until it is able to forward a large amount of data in bulk, rendering the aforementioned end-to-end correlation far less feasible. For an excellent discussion on this attack, and possible countermeasures, see Practical Traffic Analysis: Extending and Resisting Statistical Disclosure. Cascades Much like any mix network, Dissentr models its network as a graph of nodes, each responsible for handling the relay of traffic as it moves along some path through the network. Where Dissentr differs from a network such as Tor is in how this path is constructed. In Dissentr, the network is constructed out of cascades (A term I first heard described by Ian Goldberg, but I've been unable to pin down an original source for): essentially directed, acyclic sub-graphs, in which a node defines a set of "trusted" nodes, through which they are willing to relay traffic through. Dissentr simplifies this model by only allowing for nodes of out-degree 1, at this time. This construction brings about a number of useful results: In the event that a node is known to be compromised, individual nodes are allowed the ability to either remove themselves from a cascade, or bypass untrusted nodes entirely, without the necessity of a trusted third-party. The network is protected from "supernode invasions," in which an attacker floods the network with compromised nodes, in the hopes of either endangering the network's health, or placing the security of users passing through their nodes at risk of traffic interception, and subsequent analysis. This can be guaranteed because cascades are constructed by virtue of a measure of trust between node-operators, and so long as there exists some non-zero subset of trusted operators, they retain the ability to form a cascade of their own, effectively shutting out the efforts of such an attacker. Use-Cases As mentioned previously, the high-latency nature of the network causes a shift in the sorts of activities best facilitated by its use, however, there do exist some unique opportunities which I have neither seen implemented in the context of a mix network, nor discussed in the literature. A personal favourite idea revolves around creating a platform for political blogging, which, assuming a noisy enough network, would offer political dissidents the ability to freely write about issues of corruption or government abuse, without many of the risks associated with using a lower-latency network like Tor. If it takes a week for a blog post to appear in circulation after the author posts it to the network, it becomes magnitudes more difficult for any assailant to trace the authorship of that blog post - especially if that author never visited the website which hosts their content in the first place! It also becomes a fairly trivial exercise to adapt the network to act as a mixing service for digital currency such as Bitcoin. Furthermore, by breaking the network into a number of smaller, disjoint networks for that purpose, one is be able to counter many of the current attacks which target existing mixing services. Cryptosystem I again emphasize that the cryptosystem in place is the result of a rather rushed 48-hour hackathon - in a production system, I would recommend implementing a peer-reviewed cryptosystem, such as the very lightweight Sphinx, or, pending their coming proof of security, the recently proposed Ibis. That being said, Dissentr works as follows: Every node in the network maintains an RSA-keypair, with the public key being exposed to every node in a given cascade. When a client wishes to send a message M through the network, they choose some cascade C. For each node in the cascade, beginning with the exit node, and continuing through to the entrance node, the client generates an AES CFB128 key, which it uses to encrypt M. The key is then encrypted using that node's public RSA key. M, now encrypted with AES CFB128 for every node in the cascade, is then passed to the entrance node along with the encrypted AES keys. The entrance node then uses its private RSA key to decrypt the AES key, so that it can subsequently decrypt M, yielding yet another cipher text. This process is repeated for every node in the cascade, until the final node decrypts M to a plaintext, which it then handles accordingly. Building and Running it If, after all of my warnings, you still want to see it in action, it's dead-easy to get setup. All you'll need is Erlang installed (Tested on R16B02), along with Elixir. From there, you'll want to invoke the following from within Dissentr's directory, on every machine you want to host a node: iex --sname {Any name, different per machine} --cookie {Any string, common between all machines} -S mix This will stick you into a REPL, loaded with Dissentr's namespaces and dependencies. Sorry, there's no interface yet. From there, if you're using more than one machine, you'll want to link them all together, by running the following on every machine you want to host a node on. Since Erlang node connections are transitive, you won't have to do this for every pair of nodes.: :net_adm.ping(binary_to_atom(hostname)) The hostname in question can be found in the iex prompt. Most likely it will be something@domain. Now, just spawn a few nodes to create a network. I've got some temporary methods in place for making this easy, using some hardcoded keys stored in example_data/ for testing. Ideally, each node will be hosted on a different machine, but for testing purposes it doesn't matter. Within your prompt, execute the following: Dissentr.Cascade.add_node(:node1, nil, 1) Dissentr.Cascade.add_node(:node2, :node1, 2) Dissentr.Cascade.add_node(:node3, :node2, 3) Dissentr.Cascade.add_node(:node4, :node3, 4) Dissentr.Cascade.add_node(:node5, :node4, 5) Finally, to send an encrypted message, run the following, substituting the node and message as desired: Dissentr.Cascade.mix(:node3, "Something, something, NSA") If all went well, you should see a debug statement print out the plaintext message, on the machine which is hosting :node1

4 5