- cypherpunks - lists.cpunks.org

Malware Keylogger
by Yush Bhardwaj 08 Aug '13

08 Aug '13

Guys I was trying to setup a pendrive as malware which works for all OS (Windows/Linux/Mac). I know how to do it for windows but I am still searching to get my setup done for mac and linux. Any her knows anything about it * * * * * * *Yush Bhardwaj*

2 1

Re: [cryptography] a Cypherpunks comeback
by Bill Stewart 08 Aug '13

08 Aug '13

>On Mon, Jul 22, 2013 at 3:41 AM, Adam Back <adam(a)cypherspace.org> wrote: > > Could you please get another domain name, that name is just ridiculous. Absolutely. I mean, has anybody actually used JFETs in recent years? :-)

6 8

[cryptography] fwd: Paillier Crypto
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from dan(a)geer.org ----- Date: Mon, 05 Aug 2013 14:43:28 -0400 From: dan(a)geer.org To: cryptography(a)randombit.net Subject: [cryptography] fwd: Paillier Crypto > http://9ac345a5509a.github.io/p2p-paillier/ > > This is a form of Homomorphic Encryption that might actually scale, > given the right cloud backend. It verges on the spookiness of > Quantum. > > Support logic that might shed light on the true performance of > Paillier. > > http://plaintext.crypto.lo.gy/article/658/encounter --dan _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 4

Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from Gregory Maxwell <gmaxwell(a)gmail.com> ----- Date: Tue, 6 Aug 2013 15:39:29 -0700 From: Gregory Maxwell <gmaxwell(a)gmail.com> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on. Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz <ruiz(a)iit.edu> wrote: > Hi folks, > > Thank you very much for your great feedback on the previous version. The > next version is now up at http://passlok.com, which redirects to > https://passlok.site44.com > This may come in handy now that there are problems with Tor, since PassLok > allows you to go to any computer to do encrypted mail, because there is > nothing to install. This is what PassLok was designed to do. > > The other unforeseen endorsement came from the recent Black Hat conference. > Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel > encouraged everyone to base their public key cryptosystems on elliptic > curves rather than RSA. Here's a link on this: > http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms… Wait. You are using vague popular press FUD about RSA to promote a website hosted JS encryption tool? Really? Your code generates random values like this: sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y || a.clientY || a.offsetY || 0], 2, "mouse") sjcl.random.addEntropy((new Date).valueOf(), 2, "loadtime") try { var s = new Uint32Array(32); crypto.getRandomValues(s); sjcl.random.addEntropy(s, 1024, "crypto['getRandomValues']") } catch (t) {} Meaning that if it's used someplace where crypto.getRandomValues() doesn't exist, it has only pure snake-oil-extract randomness. Really???? If the randomness is poor, the nonce used in ECDSA will be predictable and the private key will be recoverable. This isn't to say I've audited any of it, I just grepped for a couple likely mistakes. Part of the JS code has been whitespace compressed, I consider it unauditable. > up to a whopping > 200,000 iterations for lousy keys. Since keys made in version 1.2 are no > longer compatible, this prompts upping the version to 1.3. So, not implemented in slow-as-dirt JS 200,000 iterations should take a random desktop cpu about 100ms or so. This is hardly wopping. It's not far from the minimum I'd start with, for all keys not just weak ones. Generally user provided keys are a security disaster and should be avoided wherever it's possible, strengthening or no. Humans are horrific entropy sources and really can't self assess how bad they are. -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [liberationtech] Anonymity Smackdown: NSA vs. Tor
by Eugen Leitl 07 Aug '13

07 Aug '13

----- Forwarded message from Roger Dingledine <arma(a)mit.edu> ----- Date: Wed, 7 Aug 2013 03:05:35 -0400 From: Roger Dingledine <arma(a)mit.edu> To: liberationtech <liberationtech(a)mailman.stanford.edu> Subject: Re: [liberationtech] Anonymity Smackdown: NSA vs. Tor User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Tue, Aug 06, 2013 at 10:43:39PM -0500, Kyle Maxwell wrote: > The key, obviously, is the primary assertion that the NSA runs "lots" > of Tor nodes. I've seen this assertion before, and while it's > certainly a reasonable assumption, I don't know if anybody outside the > NSA actually has hard evidence for that. I remember having this discussion with Bruce Schneier long ago, when he was about to add the phrase "of *course* NSA runs Tor relays" to a blog post. Consider two scenarios. In scenario one, NSA doesn't run any Tor relays, but they have done deals with AT&T and other networks to be able to passively monitor those networks -- including the (honest, well-intentioned) Tor relays that run on those networks. They're able to monitor some fraction of the Tor network capacity -- whether that's 1% or 10% or 30% is a fine question, and depends on both Internet topology and also what deals they've done. In scenario two, they do that plus also run some relays. They have to deal with all the red tape of deploying and operating real-world things on the Internet, and the risk that they'll do it wrong, somebody will notice, etc. And the benefit is maybe a few percent increase in what they can watch. Why would they choose scenario two? Scenario one seems like it would be working out pretty well for them. And if it's not, their resources would be better spent fixing that, since it leads to better surveillance of everything else they care about too. See https://lists.torproject.org/pipermail/tor-talk/2013-July/028851.html for a related discussion. Oh, and this argument should also lead you to ask "ok, but what about <smaller country that hasn't yet been reported to have a huge Internet surveillance program>? Shouldn't they run relays?" Maybe they should. Maybe we should hope they all do, which could make the network more diverse assuming they don't share well with each other. > Assuming that assertion holds, the architectural criticisms start to > matter more: 3 hops, 1024 bit RSA keys, etc. Somebody should tell Robert about the recent (Tor 0.2.4.x) shift to much stronger circuit handshakes and link encryption: https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… And for the "Multiple apps share the same underlying Tor egress" concern, he should learn about the stream isolation features added in Tor 0.2.3.x: https://gitweb.torproject.org/tor.git/blob/refs/tags/tor-0.2.4.15-rc:/Chang… All of this said, I don't want anybody to conclude that Tor is perfect. Many of the attacks from my 25c3 "security and anonymity vulnerabilities in Tor" talk remain hard research questions: https://media.torproject.org/video/ --Roger -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Former NSA Boss Calls Snowden's Supporters Internet Shut-ins; Equates Transparency Activists With Al-Qaeda
by Tony Arcieri 07 Aug '13

07 Aug '13

Suddenly the al-qaeda.net domain is seeming more appropriate. Apparently we're terrorists because we like Snowden! https://www.techdirt.com/articles/20130806/12154724080/former-nsa-director-… -- Tony Arcieri

1 0

[tor-dev] Damian's Status Report - July 2013
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Damian Johnson <atagar(a)torproject.org> ----- Date: Sat, 3 Aug 2013 16:16:31 -0700 From: Damian Johnson <atagar(a)torproject.org> To: tor-dev(a)lists.torproject.org, tor-reports(a)lists.torproject.org Subject: [tor-dev] Damian's Status Report - July 2013 Reply-To: tor-dev(a)lists.torproject.org Hi all. This month was mostly spent on non-tor work including a server migration, bad service outage at work, and a full week of cleaning my apartment. Still, plenty of spiffy news in stem land... ====================================================================== Remote Descriptor Fetching ====================================================================== Major feature for this month was the addition of a module to remotely fetch tor descriptors... https://stem.torproject.org/api/descriptor/remote.html https://lists.torproject.org/pipermail/tor-dev/2013-July/005156.html This works much like tor itself does, downloading descriptor content from directory authorities and mirrors. With it we can now easily script against the present state of the tor network without piggybacking on a live tor instance. Curious what you can use it for? See our present monitors for some ideas... https://lists.torproject.org/pipermail/tor-dev/2013-July/005209.html https://gitweb.torproject.org/atagar/tor-utils.git/tree This also included a little work with Nick on the spec and tor side... * Dropped the unimplemented microdescriptor query from the spec. (#9271) * Noting the max queryable fingerprints/hashes in spec. (#9282) * We're getting a high failure rate on the downloads we make. A little more investigation is needed on my part to help narrow this down. (#9379) ====================================================================== Other news includes... * Revised the appearance of stem's frontpage. The blue buttons were pretty jarring, so switched to something that matches the rest of the page... http://www.atagar.com/transfer/stem_frontpage/before.png http://www.atagar.com/transfer/stem_frontpage/after.png * Added Slackware to our download page. Many thanks to Markus for adding us to SlackBuilds! http://slackbuilds.org/repository/14.0/python/stem/ * Worked with Sreenatha to port Tor Weather to stem. Unfortunately Weather does not presently have an active maintainer so I'm not sure how we will proceed on this front. (#8264) https://lists.torproject.org/pipermail/tor-dev/2013-July/005111.html * The Munich dev meeting has attracted quite a few potential volunteers. After discussing prospective projects with seros I tidied up our volunteer page. Changes included... * Added Christian's Globe project https://lists.torproject.org/pipermail/tor-commits/2013-August/060124.html * Dropped Thandy https://lists.torproject.org/pipermail/tor-commits/2013-July/059830.html * Merged TorStatus into the entry for Atlas https://lists.torproject.org/pipermail/tor-commits/2013-July/060003.html * General page corrections https://lists.torproject.org/pipermail/tor-commits/2013-August/060125.html * Our automated Jenkins test runs ran into another regression in tor that caused it to segfault. (#9298) * STREAM events mishandled IPv6 addresses. (caught and patched by soult, #9181) * Thread with Pierre about TorPylle which turned into a discussion with Nick regarding future language direction for the tor codebase. I'm looking forward to seeing where it goes! https://lists.torproject.org/pipermail/tor-dev/2013-July/005161.html * We just finished with midterms for Google Summer of Code. Chang unfortunately did not pass, but the other projects are going well. * Sorted out travel arrangements for the GSoC mentor summit. Nick and I will be going, and Moritz is presently on the waitlist. * Code reviewed ra's rttprober. He provided some great feedback for which I still owe him a reply. https://lists.torproject.org/pipermail/tor-dev/2013-July/005183.html Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- 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: Cypherpunks
by John Young 06 Aug '13

06 Aug '13

Opposition, disgust, revulsion, ridicule toward al-qaeda is perfectly cypherpunkian. Never, ever unanimous nor what's acceptable without merciless, obnoxious, off-topic digression argument. "Fuck that to death." - A Sage "Cypherpunks" -- the name, the adventure, the rise and fall, and multiple rebirths and splits and plagiarisms -- has been subjected to as much irrational ridicule and exploitation as hyper-plagiarized "al-qaeda." "Cryptography" list is a bastard of a bastard of a bastard of cypherpunks, each iteration trying to act snooty about villanous cryptography and failing repeatedly to hide its cypherpunkian malice. There are thousands of vile and sappy posts in the cpunk archives as with the "fucked to death and still going" internet. Crud begets crud. Delete the crud and there's nothing left of the shit-hole except the gargantuan cesspools on Wayback and Wikipedia and Tor "hidden services" and blacknet and undernet and intel.net and virulent cheating, lying and fucking users and each other. Extra good shit:, big data crud is growing exponentially, a golden bowl of explosive fertilizer likely leading to global cyberwar over who runs the cess. Never ask for permission, never give it. Cross-sub everybody and spy them secretly.

5 5

[tor-talk] Tortilla
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Jason Geffner <jason(a)crowdstrike.com> ----- Date: Tue, 6 Aug 2013 14:12:33 -0500 From: Jason Geffner <jason(a)crowdstrike.com> To: tor-talk(a)lists.torproject.org Cc: cameron(a)crowdstrike.com Subject: [tor-talk] Tortilla Organization: CrowdStrike, Inc. X-Mailer: Microsoft Outlook 15.0 Reply-To: tor-talk(a)lists.torproject.org I'd like to announce the availability of Tortilla, a free open-source tool that allows users to securely, anonymously, and transparently route all TCP/IP and DNS traffic through Tor. Though the Tor client natively supports transparent proxying on Linux-based systems, Tortilla allows Tor users to use Windows for transparent proxying. Unlike other similar solutions, Tortilla does not rely on API hooks (and as such does not allow malware to circumvent the Tor tunnel) and does not require extra hardware, a VPN, or an extra Tor gateway virtual machine. The whitepaper for Tortilla which describes the design goals, architecture, and usage instructions is available at https://media.blackhat.com/us-13/US-13-Geffner-Tor...-All-The-Things-WP.pdf The source code is available at https://github.com/CrowdStrike/Tortilla A pre-built distribution (compatible with 32-bit and 64-bit versions of Windows XP through Windows 8) is available at http://www.crowdstrike.com/community-tools Tortilla is still in beta, but I'd be pleased to answer any questions you may have about it. Please note that Tortilla is produced independently from the Tor(r) anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else. Sincerely, Jason Geffner Sr. Security Researcher, CrowdStrike -- 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

Re: [tor-relays] VPS Hardware Specification & Advice
by Eugen Leitl 06 Aug '13

06 Aug '13

----- Forwarded message from Tor Pids <torpids(a)yahoo.com> ----- Date: Tue, 06 Aug 2013 20:40:11 +0200 From: Tor Pids <torpids(a)yahoo.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] VPS Hardware Specification & Advice Reply-To: tor-relays(a)lists.torproject.org Hi, i just saw this post on the web archive and felt I can contribute something here so I finally registered. Maybe this reply will not be correctly recognized to the thread, sorry. The VPS specs you posted should be more than enough - but the price is too expensive! I currently run about 20 Tor relays on cheap VPS all around the world: http://globe.rndm.de/#/search/query=torpids Basically I just care for the bandwidth/included traffic when choosing a VPS. 256MB RAM is enough, disk space doesn't matter at all. Tor doesn't scale that well with CPU cores so 1 core is ok. For only 1 or 2 of my VPS the CPU is the bottleneck (at about 20-30MBit/s), but most are fast enough. Most cheap VPS are based on the OpenVZ virtualization which limits you to their old kernel and sometimes they limit the number of tcp connections (see "cat /proc/user_beancounters"). KVM or Xen virtualisation is better because you have more control on the VM. Most VPS providers add up the incoming and outgoing bandwidth, meaning that you might be able to just send about 500GB with your 1TB plan. For example with a VPS from www.jiffybox.de for 15€ per month it is possible to push more than 1TB PER DAY(!) (and not per month as with the 18€ plan you mentioned). OVH just released a server for £2,99 per month with unlimited 100MBit/s as well: https://www.ovh.co.uk/dedicated_servers/kimsufi.xml Other typical offers are like 10TB for 10$ or 20MBit/s unlimited for 3€. Good places to find cheap VPS deals: http://www.lowendbox.com/ and http://lowendtalk.com/categories/offers http://www.wjunction.com/46-vps http://www.webhostingtalk.com/forumdisplay.php?f=104 Best, Torpids _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- 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