[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin [EMAIL PROTECTED] - From: Kerry Bonin [EMAIL PROTECTED] Date: Mon, 31 Oct 2005 07:25:20 -0800 To: Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Frank, In my experience w/ pretty hardcore authentication and security domains, it is pretty much impossible to guarantee that a remote node connecting over an untrusted network is running trusted code. For every clever way to try and detect a compromised client, there are even more clever ways to subvert the detection process. The simplest model - simply reverse engineer the network traffic via packet capture, and write a client that looks identical from the network traffic. One example of a common client validation approach is requesting a strong checksum of some random range of the client or its dataset, but this is pretty trivial to circumvent once you have a complete copy of the client and have reverse engineered its checksum algorithm. In my experience, if you really care about what your node are doing, then NEVER trust ANY node - validate every bit of every packet. If you are trying to catch compromised nodes, there are clever ways to do that - build heuristic models that examine what nodes are doing, and forward captures to admin nodes for human analysis for heuristic refinement and analysis of what your attackers are up to. While it is in theory impossible to allow users to do anything and still catch a user doing something they're not supposed to, it may be possible to specify terms in your EULA that define constraints users would not typically violate, and respond with penalties that are not too strong for the corner cases where a user triggers a false positive by crossing the line. An example of this in the file sharing domain would be temporary bans on nodes that initiated too many searches in some time frame, suggesting spidering. On the other hand, clever counter-heuristics and large numbers of zombies can defeat most heuristics - see SPAM for many examples... Kerry Frank Moore wrote: Matthew Kaufman wrote: I think what you're asking here is is it possible to design a p2p network such that the peers must be running the official code that does the right thing, instead of running some subverted code that does something 'wrong'? Matthew, Very eloquently put. Yes, this is exactly what I was asking. We supply the client as well as the server and we just need to make sure that any client that joins the network is our client and not a 'rogue'. The one exception is that you *can* in some cases design the network such that peers that don't behave properly are shunned or dropped by the rest of the network, assuming that such behavior is detectable. For instance, in a distributed file store, you could store test data and see if it sticks around... If it doesn't, that peer is cheating. We have a way (we think) of authenticating the stream put out by a peer, so we can catch a 'rogue' client this way, but it seems more logical to prevent someone from logging into the network in the first place. Thanks for your help, Frank. ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
On Sat, Oct 29, 2005 at 08:42:35PM -0400, Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. Actually, an RFID can be ridiculously reliable. It will also depend on how much harassment a traveler will be exposed to, when travelling. Being barred from entry will definitely prove sufficient deterrment. The only question is, what could (believably) damage the RFID? Microwaving it will blow up the chip, and cause a scorched spot. Severing the antenna would be enough for the chip to become mute. Violetwanding or treating with a Tesla generator should destroy all electronics quite reliably -- you always have to check, of course. Also, the ID is quite expensive, and a frequent traveller will wind up with a considerable expense, and hassle. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Multiple passports?
On Sun, Oct 30, 2005 at 03:05:25AM +, Justin wrote: If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? Here in Germany the current ID (sans smartcard/rfid/biometics) will be valid until expiry date. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants start
On Sat, Oct 29, 2005 at 08:42:35PM -0400, Tyler Durden wrote: One thing to think about with respect to the RFID passports... Um, uh...surely once in a while the RFID tag is going to get corrupted or something...right? I'd bet it ends up happening all the time. In those cases they probably have to fall back upon the traditional passport usage and inspection. Actually, an RFID can be ridiculously reliable. It will also depend on how much harassment a traveler will be exposed to, when travelling. Being barred from entry will definitely prove sufficient deterrment. The only question is, what could (believably) damage the RFID? Microwaving it will blow up the chip, and cause a scorched spot. Severing the antenna would be enough for the chip to become mute. Violetwanding or treating with a Tesla generator should destroy all electronics quite reliably -- you always have to check, of course. Also, the ID is quite expensive, and a frequent traveller will wind up with a considerable expense, and hassle. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: Multiple passports?
On Sun, Oct 30, 2005 at 03:05:25AM +, Justin wrote: If I apply for a new one now, and then apply for a another one once the gov starts RFID-enabling them, will the first one be invalidated? Or can I have two passports, the one without RFID to use, and the one with RFID to play with? Here in Germany the current ID (sans smartcard/rfid/biometics) will be valid until expiry date. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv]]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Fri, 28 Oct 2005 17:49:06 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Edward Hasbrouck [EMAIL PROTECTED] Date: October 28, 2005 11:07:28 AM EDT To: [EMAIL PROTECTED] Subject: Re: [IP] more on U.S. passports to receive RFID implants starting in October 2006 [priv] From: Lin, Herb [EMAIL PROTECTED] *Front* cover? Does that mean that if I hold the passport the wrong way, the skimmer will have a free ride? FWIW: (1) The sample RFID passports that Frank Moss passed around at CFP, which looked like http://travel.state.gov/passport/eppt/eppt_2501.html, had the RFID chip (which was barely detectable by feel) in the *back* cover. The visible data page was/is, as with current passports, in the *front* cover. This is not compliant with the ICAO specifications, which recommend having the chip in the same page as the visible data, to make it more difficult to separate them. I can only guess that it was hard to laminate the visible data without damaging the chip, if it was in the same page. But it's interesting in light of the importance supposedly being placed on compliance with ICAO standards. (2) Moss had 2 sample RFID passports, 1 with and 1 without the shielding. He cliamed it was a layer in the entire outer cover (front and back), but it wasn't detectable by feel. I have more threat scenarios for the latest flavor of RFID passport at: http://hasbrouck.org/blog/archives/000869.html Edward Hasbrouck [EMAIL PROTECTED] http://hasbrouck.org +1-415-824-0214 - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: RE: [p2p-hackers] P2P Authentication]
- Forwarded message from Matthew Kaufman [EMAIL PROTECTED] - From: Matthew Kaufman [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 19:28:53 -0700 To: 'Peer-to-peer development.' [EMAIL PROTECTED] Subject: RE: [p2p-hackers] P2P Authentication X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Alen Peacock: Personally, I'm put off by the centralization. I'm not really concerned about the library size or complexity of PKI,. In fact, my experience indicates that implementing centralized CAs is a good deal less complex than trying to distribute identity verification throughout the system with no centralization. Agreed... Hierarchical PKI with a single root is distinctly easier than multiple roots, random chains of trust, or reputation models, which is why we've started with the simplest design for the default PKI that ships with the amicima MFP and MFPNet libraries. Completely decentralized p2p applications have the advantage of being especially resilient to DoS and other attacks on centrality. Introducing centralized components negates this advantage. It negates some advantages, not all. In the case of using CAs in a p2p app, the entire network can be disabled by attacking the CAs. As has already been pointed out, the network still runs, but new clients can't be authenticated. However, it is possible to make that unlikely... For instance, if enough trusted entities already have the ability to sign keys, you can reduce the odds that an attacker can successfully disable ALL of the CAs. Adding additional roots to the PKI, especially if they are public roots that are unlikely to be disabled, also helps... It doesn't seem likely that the world will shut down the existing secure web PKI in order to take your P2P app off the air. p2p networks pose an interesting challenge because you have to design for the fact that malicious or misbehaving clients *will* be present. This is actually true of the entire Internet and isn't unique to p2p networks at all. All protocol implementations and higher level applications that run on them must be designed to deal with malicious or misbehaving clients will be present... See buffer overflows of mail servers and http servers, for instance. Since there is no single entity or known group of entities controlling the nodes (as in typical distributed applications), there is no way to enforce adherence to protocols other than with the protocols themselves. This isn't about p2p networks at all, but about open-source distribution, it seems. Lots of totally proprietary p2p and client-server applications have been shipped where a single entity controls the implementation... Skype comes to mind as an example in the P2P space. These have the temporary advantage of unpublished protocols and implementations, but this won't stop a dedicated attacker for long, which brings us back to the original point, that everything attached to the Internet needs to assume that malicious and misbehaving things will try to mess things up. Whether or not that really matters is another point... There's numerous ways one could build a highly incorrect Gnutella peer, for instance, and yet it doesn't seem to have become commonplace. This may sound idealistic and naive, perhaps justly so, but the further away from protocols that require centralized architectures we get, the better (IMHO, of course). Well, that's why we're all here on the P2P hackers list, I suppose, because we believe that decentralization is good, but it doesn't really change the most basic of the design parameters at all. Matthew Kaufman [EMAIL PROTECTED] www.amicima.com ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, Oct 27, 2005 at 11:28:42PM -0400, R.A. Hettinga wrote: The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that needs killing thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Thu, Oct 27, 2005 at 11:28:42PM -0400, R.A. Hettinga wrote: The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that needs killing thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Wed, Oct 26, 2005 at 08:41:48PM -0500, Shawn K. Quinn wrote: 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? Telling is useless. Are you in a sufficient position of power to make them stop using it? I doubt it, because that person will be backed both by your and her boss. Almost always. It's never about merit, and not even money, but about predeployed base and interoperability. In today's world, you minimize the surprise on the opposite party's end if you stick with Redmondware. (Businessfolk hate surprises, especially complicated, technical, boring surprises). 2) OpenOffice can read Excel spreadsheets, and I would assume it can save the changes back to them as well. OpenOffice Co usually supports a subset of Word and Excel formats. If you want to randomly annoy your coworkers, use OpenOffice to process the documents in MS Office formats before passing them on, without telling what you're doing. Much hilarity will ensue. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: EFF is looking for Tor DMCA test case volunteers]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Wed, 26 Oct 2005 16:55:36 -0400 To: [EMAIL PROTECTED] Subject: EFF is looking for Tor DMCA test case volunteers User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] Fred asked me to forward this to the list. If you have legal questions (and probably most questions about this count as legal questions), you should contact Fred and Kevin directly (fred at eff.org and bankston at eff.org). Fred also reminds us that any correspondence you have with me or others here would be discoverable, so that's an added incentive to go to them directly. Please look through this checklist, and decide if you match the profile they're looking for. I'd like to encourage you to contact them even if there are a few points you don't match so well -- I'd rather have a big pile of pretty-good volunteers than have everybody hold off because they are not perfectly suited -- then Fred and Kevin can make their own decisions from there. Thanks, --Roger If record label and movie studio representatives continue sending infringement notices to Tor node operators and their upstream ISPs, it will become increasingly important to set a clear legal precedent establishing that merely running a node does not create copyright liability for either node operators or their bandwidth providers. In order to establish such a precedent, it will be necessary to bring or defend a test case. EFF is actively seeking clients willing to be the test case. Picking the right client is half the battle in any test case. Accordingly, we cannot promise that we will be able to defend any and all Tor node operators. There are several factors that are relevant in finding the right test case client. Here are some of them: 1. You must have received a complaint from a copyright owner about operating a Tor node. Complaints from your ISP about running a proxy do not count, even if they mention copyright infringement as the reason for their objection -- that's a contractual fight between you and your bandwidth provider. We are looking for node operators who have either received copyright complaints directly, or forwarded to them from their ISPs. 2. You should not be an infringer yourself, or be engaged in any other kind of unlawful activity. In litigation, the copyright owners will want to examine every hard drive and email message in your possession or control, looking for evidence that you are running Tor because you want to encourage people to infringe copyright. So if you are a big file-sharer, warez trader, or are involved in any other unlawful activities (even if unrelated to Tor), you are probably not the right person. 3. You should have a legitimate reason to run Tor. If you are the client for the test case, you will be deposed under oath and asked why you run Tor. You should be able to truthfully respond in a way that does not suggest that you are doing it to encourage any illegal activity, including copyright infringement. For example, running it because you value free speech is a legitimate reason. Same if you are running it for research purposes. Any documentary evidence from your past (e.g., emails, papers presented, etc) should not contradict your story. Most Tor node operators will qualify under this criteria, but if you wrote a bunch of emails and bulletin board posts describing how great Tor will be for the coming copyright revolution, you are probably not the ideal client. 4. You should be willing to see the case through. Litigation takes time -- often several years. The process will occasionally involve some inconvenience, including depositions and allowing the other side to go through most documents in your possession or control (including email, hard drives, etc). EFF will provide the legal services for free. But there is some risk of personal liability for damages, perhaps amounting to several thousand dollars, if we lose. We will do everything to minimize the risk, but cannot eliminate it altogether. 5. You should be located in the United States. Your Tor server should also be located in the United States. 6. You should have an upstream bandwidth provider who will stand by you. It would be less than ideal if your upstream ISP terminates your account before we ever get to court. Fred - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin [EMAIL PROTECTED] - From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... Kerry [EMAIL PROTECTED] wrote: And if they do, then why reinvent the wheel? Traditional public key signing works well for these cases. ... Traditional public key signing doesn't work well if you want to eliminate the central authority / trusted third party. If you like keeping those around, then yes, absolutely, traditional PKI works swimmingly. Where is the evidence of this bit about traditional PKI working? As far as I've observed, traditional PKI works barely for small, highly centralized, hierarchical organizations and not at all for anything else. Am I missing some case studies of PKI actually working as intended? Regards, Zooko ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] EFF: Court Issues Surveillance Smack-Down to Justice Department]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Wed, 26 Oct 2005 19:28:46 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] EFF: Court Issues Surveillance Smack-Down to Justice Department X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: EFF Press [EMAIL PROTECTED] Date: October 26, 2005 7:00:22 PM EDT To: [EMAIL PROTECTED] Subject: [E-B] EFF: Court Issues Surveillance Smack-Down to Justice Department Reply-To: [EMAIL PROTECTED] Electronic Frontier Foundation Media Release For Immediate Release: Wednesday, October 26, 2005 Contact: Kevin Bankston Staff Attorney Electronic Frontier Foundation [EMAIL PROTECTED] +1 415 436-9333 x126 Kurt Opsahl Staff Attorney Electronic Frontier Foundation [EMAIL PROTECTED] +1 415 436 9333 x106 Court Issues Surveillance Smack-Down to Justice Department No Cell Phone Location Tracking Without Probable Cause New York - Agreeing with a brief submitted by EFF, a federal judge forcefully rejected the government's request to track the location of a mobile phone user without a warrant. Strongly reaffirming an earlier decision, Federal Magistrate James Orenstein in New York comprehensively smacked down every argument made by the government in an extensive, fifty-seven page opinion issued this week. Judge Orenstein decided, as EFF has urged, that tracking cell phone users in real time required a showing of probable cause that a crime was being committed.Judge Orenstein's opinion was decisive, and referred to government arguments variously as unsupported, misleading, contrived, and a Hail Mary. This is a true victory for privacy in the digital age, where nearly any mobile communications device you use might be converted into a tracking device, said EFF Staff Attorney Kevin Bankston. Combined with a similar decision this month from a federal court in Texas, I think we're seeing a trend--judges are starting to realize that when it comes to surveillance issues, the DOJ has been pulling the wool over their eyes for far too long. Earlier this month, a magistrate judge in Texas, following the lead of Orenstein's original decision, published his own decision denying a government application for a cell phone tracking order. That ruling, along with Judge Orenstein's two decisions, revealed that the DOJ has routinely been securing court orders for real-time cell phone tracking without probable cause and without any law authorizing the surveillance. The Justice Department's abuse of the law here is probably just the tip of the iceberg, said EFF Staff Attorney Kurt Opsahl. The routine transformation of your mobile phone into a tracking device, without any legal authority, raises an obvious and very troubling question: what other new surveillance powers has the government been creating out of whole cloth and how long have they been getting away with it? The government is expected to appeal both decisions and EFF intends to participate as a friend of the court in each case. You can read the full text of Judge Orenstein's new opinion, and the similar Texas opinion, at www.eff.org/legal/cases/USA_v_PenRegister. For this release: http://www.eff.org/news/archives/2005_10.php#004090 About EFF The Electronic Frontier Foundation is the leading civil liberties organization working to protect rights in the digital world. Founded in 1990, EFF actively encourages and challenges industry and government to support free expression and privacy online. EFF is a member-supported organization and maintains one of the most linked-to websites in the world at http://www.eff.org/ -end- ___ presslist mailing list https://falcon.eff.org/mailman/listinfo/presslist - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Wed, Oct 26, 2005 at 08:41:48PM -0500, Shawn K. Quinn wrote: 1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? Telling is useless. Are you in a sufficient position of power to make them stop using it? I doubt it, because that person will be backed both by your and her boss. Almost always. It's never about merit, and not even money, but about predeployed base and interoperability. In today's world, you minimize the surprise on the opposite party's end if you stick with Redmondware. (Businessfolk hate surprises, especially complicated, technical, boring surprises). 2) OpenOffice can read Excel spreadsheets, and I would assume it can save the changes back to them as well. OpenOffice Co usually supports a subset of Word and Excel formats. If you want to randomly annoy your coworkers, use OpenOffice to process the documents in MS Office formats before passing them on, without telling what you're doing. Much hilarity will ensue. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
/. [Snooping Through Walls with Microwaves]
Link: http://slashdot.org/article.pl?sid=05/10/26/0424211 Posted by: ScuttleMonkey, on 2005-10-26 10:26:00 denis-The-menace writes According to an article from newscientist, scientists have devised a system to [1]use microwave energy for surveillance. If people are speaking inside the room, any flimsy surface, such as clothing, will be vibrating. This modulates the radio beam reflected from the surface. Although the radio reflection that passes back through the wall is extremely faint, the kind of electronic extraction and signal cleaning tricks used by NASA to decode signals in space can be used to extract speech. Although, I doubt it would work in [2]this room References 1. http://www.newscientist.com.nyud.net:8090/article.ns?id=dn8208 2. http://www.imagireal.com.nyud.net:8090/gallery/foiled - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Wiretapping innocent people on the Internet]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Tue, 25 Oct 2005 14:08:43 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] Wiretapping innocent people on the Internet X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] To: Declan McCullagh declan@well.com, [EMAIL PROTECTED] Subject: Re: [Politech] Wiretapping innocent people on the Internet In-reply-to: [EMAIL PROTECTED] Date: Tue, 25 Oct 2005 10:20:16 -0700 From: John Gilmore [EMAIL PROTECTED] The NYT covered this story, on the front page, too. But somehow it was all about Colleges Protest Call to Upgrade Online Systems. It wasn't about the government automating the bugging of every student, professor, and staff person by typing a few commands from the basement of the FBI building. The nasty word wiretap didn't appear til the eighth paragraph, below the fold, and when it did appear, it was buried in mid-sentence, right next to criminals, terrorists and spies. (They never wiretap citizens, innocent bystanders, or suspects, and everyone wiretapped is of course guilty-as-charged, though they haven't been charged with any crime yet.) There's no shortage of bias in the New York Times, but this is a particularly blatant example. Now why is it in the interest of the Times to build wiretapping into the hardware of the Internet? The story also claimed that Because the government would have to win court orders before undertaking surveillance, the universities are not raising civil liberties issues. I think there's a civil liberties issue when the US Government wants to wire the country like the Stasi wired East Germany for indiscriminate bugging. And there's no winning of these court orders; they happen in secret, without the participation or knowledge of the target of the wiretap. The university cannot appear in court to argue about whether the order should be issued (and very few challenge them after issuance). In most cases the judge is *required* to issue the secret wiretap order every time the Feds merely say we need the info. To get 99% of such orders, they don't need a warrant, nor probable cause to believe that a crime has been committed. What used to be tough wiretap standards have been whittled away inch by inch by decades of aggressive pushing on the part of the FBI, DEA, CIA, NSA, and DoJ. In August, one judge woke up and published a decision that said, despite his previously regular issuance of secret orders to track the location of peoples' cellphones in real time, without probable cause or any suspicion of criminal activity, he was concerned about whether this routine secret practice was actually legal. (See http://www.eff.org/news/archives/2005_09.php#004002). Bravo for that one judge who found his conscience. The government argues that under the same conditions (no warrant, no reason to suspect you in particular), they can monitor about 40% of the bits you send over the Internet, in real time, including where you are, who you're talking with, what protocols you're using, and every URL, email address, IM name, or other addressing and signaling information. (I argue that they don't have this authority, but I never get to show up in court at these discussions with the judge.) Not only is this information supposedly legal for the government to get about every citizen, it's perfect for automated software tracking of who's-talking-to-who, all the time. The NSA term for it is traffic analysis, and most of it works even if your communications are encrypted. I understand why the authoritarian brass would want routine wiretaps of the innocent; as Orson Welles said, Only in a police state is the job of a policeman easy. They've lost sight of their goal (keeping people safe and free), yet redoubled their efforts. Why this would be in the interest of the citizens (or the FCC, or the NY Times) is the puzzle. John Gilmore (speaking for myself) - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [Politech] U.S. passports to receive RFID implants starting in October 2006 [priv]]
- Forwarded message from Declan McCullagh declan@well.com - From: Declan McCullagh declan@well.com Date: Tue, 25 Oct 2005 13:23:23 -0700 To: politech@politechbot.com Subject: [Politech] U.S. passports to receive RFID implants starting in October 2006 [priv] User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) Text of regulations: http://edocket.access.gpo.gov/2005/05-21284.htm --- http://news.com.com/Passports+to+get+RFID+chip+implants/2100-7348_3-5913644.html?tag=nefd.top Passports to get RFID chip implants October 25, 2005, 12:12 PM PDT All U.S. passports will be implanted with remotely-readable computer chips starting in October 2006, the Bush administration has announced. Sweeping new State Department regulations issued Tuesday say that passports issued after that time will have tiny radio frequency ID (RFID) chips that can transmit personal information including the name, nationality, sex, date of birth, place of birth and digitized photograph of the passport holder. Eventually, the government contemplates adding additional digitized data such as fingerprints or iris scans. Over the last year, opposition to the idea of implanting RFID chips in passports has grown amidst worries that identity thieves could snatch personal information out of the air simply by aiming a high-powered antenna at a person or a vehicle carrying a passport. Out of the 2,335 comments on the plan that were received by the State Department this year, 98.5 percent were negative. The objections mostly focused on security and privacy concerns. [...remainder snipped...] ___ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Publicizing Hidden Services]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Sun, 23 Oct 2005 23:41:20 -0400 To: [EMAIL PROTECTED] Subject: Re: Publicizing Hidden Services User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] On Sun, Oct 23, 2005 at 11:17:56PM -0400, [EMAIL PROTECTED] wrote: On Sun, Oct 23, 2005 at 10:37:54PM -0300, [EMAIL PROTECTED] wrote 2.3K bytes in 57 lines about: : It would probably work (publishing of hidden services I mean) if it was a : voluntary thing. Like having a central place for people to leave a link and : general desc. would be nice... http://4ha7nlx3shi5gcty.onion/ And the more canonical one is http://6sxoyfb3h2nvok2d.onion/tor/ which is linked from http://tor.eff.org/cvs/tor/doc/tor-hidden-service.html but could also be helpfully linked from overview.html and documentation.html (which was why this thread started). I've just linked them more loudly from both of these places. Let me know if you think that helps. I couldn't actually access the one phobos provided. Which leads to the more important point -- we need to work on speed and reliability of hidden services before we try to make them more popular. That's on the todo list, but it's pretty far down the list at this point, at least until somebody with funding decides that this is important to them. --Roger - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Access for the uncomputed]
Patrick, how is this going? It looks like Tor can replace the more ambitious part of your project, but step one is still a hard task to get right too. :) It looks like it's GPL, which is good. But it looks like it breaks stylesheets of the pages it downloads (e.g. tor.eff.org), which is bad. What about SSL to the proxy page? Does it have a back-end that can http-proxy to privoxy, and/or socks4a-proxy to Tor? Is this still in development, or should I take the Copyright 2003 to be a bad sign? :) Thanks, --Roger -- Public Key ID 0x4A6880B2 Key Fingerprint: 7867 E238 1608 1A20 89C4 BA6C 8FC3 C6EB 4A68 80B2 http://warhn.org/pcoleman/pubkey.txt -- Public Key ID 0x4A6880B2 Key Fingerprint: 7867 E238 1608 1A20 89C4 BA6C 8FC3 C6EB 4A68 80B2 http://warhn.org/pcoleman/pubkey.txt -- Public Key ID 0x4A6880B2 Key Fingerprint: 7867 E238 1608 1A20 89C4 BA6C 8FC3 C6EB 4A68 80B2 http://warhn.org/pcoleman/pubkey.txt - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Skype security evaluation]]
- Forwarded message from Damien Miller [EMAIL PROTECTED] - From: Damien Miller [EMAIL PROTECTED] Date: Mon, 24 Oct 2005 12:39:42 +1000 (EST) To: cryptography@metzdowd.com Cc: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Skype security evaluation] On Sun, 23 Oct 2005, Joseph Ashwood wrote: - Original Message - Subject: [Tom Berson Skype Security Evaluation] Tom Berson's conclusion is incorrect. One needs only to take a look at the publicly available information. I couldn't find an immediate reference directly from the Skype website, but it uses 1024-bit RSA keys, the coverage of breaking of 1024-bit RSA has been substantial. The end, the security is flawed. Of course I told them this now years ago, when I told them that 1024-bit RSA should be retired in favor of larger keys, and several other people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype roll its own entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Skype security evaluation]
- Forwarded message from Steven M. Bellovin [EMAIL PROTECTED] - From: Steven M. Bellovin [EMAIL PROTECTED] Date: Sun, 23 Oct 2005 09:48:37 -0400 To: cryptography@metzdowd.com Subject: Skype security evaluation X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 Skype has released an external security evaluation of its product; you can find it at http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf (Skype was also clueful enough to publish the PGP signature of the report, an excellent touch -- see http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf.sig) The author of the report, Tom Berson, has been in this business for many years; I have a great deal of respect for him. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Skype security evaluation]
- Forwarded message from Steven M. Bellovin [EMAIL PROTECTED] - From: Steven M. Bellovin [EMAIL PROTECTED] Date: Sun, 23 Oct 2005 09:48:37 -0400 To: cryptography@metzdowd.com Subject: Skype security evaluation X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 Skype has released an external security evaluation of its product; you can find it at http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf (Skype was also clueful enough to publish the PGP signature of the report, an excellent touch -- see http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf.sig) The author of the report, Tom Berson, has been in this business for many years; I have a great deal of respect for him. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: nym paper preprint]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Sat, 22 Oct 2005 10:20:40 + (UTC) To: [EMAIL PROTECTED] Subject: nym paper preprint Reply-To: [EMAIL PROTECTED] I've finished a first draft of an academic paper on nym: http://www.lunkwill.org/cv/nym.pdf Abstract: nym is a straightforward application of blind signatures to create a pseudonymity system with extremely low barriers to adoption. Clients use an entirely browser-based application to pseudonymously obtain a blinded token which can be anonymously exchanged for an ordinary TLS client certificate. In the appendix, we give the complete Javascript application and the necessary patch to use client certificates in place of IP addresses in the popular web application MediaWiki. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] CALEA and Colleges]
a new muffler?' ___ EPIC_IDOF mailing list [EMAIL PROTECTED] https://mailman.epic.org/cgi-bin/mailman/listinfo/epic_idof - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] more on Colleges protest netwoprk upgrades to allow easier surveillance]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Sat, 22 Oct 2005 16:36:43 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] more on Colleges protest netwoprk upgrades to allow easier surveillance X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: finin [EMAIL PROTECTED] Date: October 22, 2005 3:22:57 PM EDT To: Dave Farber [EMAIL PROTECTED] Subject: Colleges protest netwoprk upgrades to allow easier surveillance According to this story, the only complaint from colleges is the cost. In addition to ultimate concerns about privacy, are there also technical issues that might come up, like adding to latency or congestion? Many universities are engaged in building and testing innovative high speed computation and communication applications and testbeds that span the Internet. Would a required re-architecting of campus networks cause problems for this kind of research? I'm not expert enough in these areas to have a well informed opinion. Tim -- Colleges Protest Call to Upgrade Online Systems By Sam Dillon and Stephen Labaton, NYT, October 23, 2005 http://www.nytimes.com/2005/10/23/technology/23college.html? pagewanted=all The federal government, vastly extending the reach of an 11-year-old law, is requiring hundreds of universities, online communications companies and cities to overhaul their Internet computer networks to make it easier for law enforcement authorities to monitor e-mail and other online communications. The action, which the government says is intended to help catch terrorists and other criminals, has unleashed protests and the threat of lawsuits from universities, which argue that it will cost them at least $7 billion while doing little to apprehend lawbreakers. Because the government would have to win court orders before undertaking surveillance, the universities are not raising civil liberties issues. The order, issued by the Federal Communications Commission in August and first published in the Federal Register last week, extends the provisions of a 1994 wiretap law not only to universities, but also to libraries, airports providing wireless service and commercial Internet access providers. It also applies to municipalities that provide Internet access to residents, be they rural towns or cities like Philadelphia and San Francisco, which have plans to build their own Net access networks. So far, however, universities have been most vocal in their opposition. ... The universities do not question the government's right to use wiretaps to monitor terrorism or criminal suspects on college campuses, Mr. Hartle said, only the order's rapid timetable for compliance and extraordinary cost. ... But the federal law would apply a high-tech approach, enabling law enforcement to monitor communications at campuses from remote locations at the turn of a switch. It would require universities to re-engineer their networks so that every Net access point would send all communications not directly onto the Internet, but first to a network operations center where the data packets could be stitched together into a single package for delivery to law enforcement, university officials said. ... Law enforcement has only infrequently requested to monitor Internet communications anywhere, much less on university campuses or libraries, according to the Center for Democracy and Technology. In 2003, only 12 of the 1,442 state and federal wiretap orders were issued for computer communications, and the F.B.I. never argued that it had difficulty executing any of those 12 wiretaps, the center said. We keep asking the F.B.I., What is the problem you're trying to solve? Mr. Dempsey said. And they have never showed any problem with any university or any for-profit Internet access provider. The F.B.I. must demonstrate precisely why it wants to impose such an enormously disruptive and expensive burden. ... -- Tim Finin, Computer Science Electrical Engineering, Univ of Maryland Baltimore County, 1000 Hilltop Cir, Baltimore MD 21250. [EMAIL PROTECTED] http://ebiquity.umbc.edu 410-455-3522 fax:-3969 http://umbc.edu/~finin - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: SSL fro hidden services]
- Forwarded message from loki tiwaz [EMAIL PROTECTED] - From: loki tiwaz [EMAIL PROTECTED] Date: Thu, 20 Oct 2005 22:57:24 + To: [EMAIL PROTECTED] Subject: Re: SSL fro hidden services Reply-To: [EMAIL PROTECTED] hi, That said, the certificate naming scheme may be way off, since there's no concept of a valid certificate (I doubt verisign will want to sign one for 786237261871621.onion :) i am considering running an onion-based CA which could be used... i simply need to make a script which allows a user to sign a certificate signing request and produce a signed server key. the server key only needs to have its onion address as content, nothing more is required, and a link to import the CA key into the browser so that it can be trusted automatically by the browser. However, assuming the user installs your self-signed cert, it *should* work the same unless there's something I'm missing.) Of course, you're really just protecting content from being sniffed between the user and the entry node (usually, the same machine, but not always), and the exit node and the hidden service (presumably, you control both). This is my understanding of it -- if someone has a better one please step on me without hesitation :) yes, this is the case, and it is a valid reason to use ssl. in my opinion, since tor already uses multi-layered encryption anyway, one more layer at the core is not going to create that much of an extra load on the server, and it means that there is no way the traffic can be sniffed at any point - for example a trojan could sniff localhost traffic. also, using onion routing defeats the one way in which SSL can be attacked, by man-in-the-middle intermediaries on the network pathway, which of course cannot be known within the tor network. Also, it should be noted that tor exit nodes could potentially be modified to become men-in-the-middle, although this would not be possible without compromising the key of the server being contacted - another aspect of the advantage of using tor. onion addresses are impossible to remember though - which brings me to another idea - of a name resolution system within the tor network so simpler names can be used. this would require a second directory system, i don't know if it is practical or not, but i thought i should put the idea out there because i2p has name resolution systems, and benig able to type in oniondomainname.onion rather than u15syoa125au.onion would be nice. it would increase the rate of take-up of hidden services, both use and hosting. onion domains could be propagated throughout the onion network, so that every tor node can translate a name into an onion hashed address. there would also need to be a system to prevent name spoofing... how to ensure there is no collisions of names would be tricky - very likely it would require a set of authoritative name servers similar to how there is authoritative onion directory servers. ah dammit, i am always ideas ideas ideas and so little action... prioritising goals is something i find difficult... i think i should make this idea a priority, however, which means joining the dev effort and, at the very least, defining a protocol, if not implementing code... well, anyway, i have put the idea out now. i think that the idea is a good one. tor is coming of age now and ideally tor should aim to provide all of the features one would expect in an internet layer, but with the guiding principle of protecting anonymity always ascendant. an onion-based CA would work much better if the name-resolution system were in place, so i think it should be the priority. loki _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: SSL fro hidden services]
- Forwarded message from Dan Mahoney, System Admin [EMAIL PROTECTED] - From: Dan Mahoney, System Admin [EMAIL PROTECTED] Date: Thu, 20 Oct 2005 19:18:08 -0400 (EDT) To: [EMAIL PROTECTED] Subject: Re: SSL fro hidden services Reply-To: [EMAIL PROTECTED] On Thu, 20 Oct 2005, loki tiwaz wrote: hi, That said, the certificate naming scheme may be way off, since there's no concept of a valid certificate (I doubt verisign will want to sign one for 786237261871621.onion :) i am considering running an onion-based CA which could be used... i simply need to make a script which allows a user to sign a certificate signing request and produce a signed server key. the server key only needs to have its onion address as content, nothing more is required, and a link to import the CA key into the browser so that it can be trusted automatically by the browser. However, assuming the user installs your self-signed cert, it *should* work the same unless there's something I'm missing.) Of course, you're really just protecting content from being sniffed between the user and the entry node (usually, the same machine, but not always), and the exit node and the hidden service (presumably, you control both). This is my understanding of it -- if someone has a better one please step on me without hesitation :) yes, this is the case, and it is a valid reason to use ssl. in my opinion, since tor already uses multi-layered encryption anyway, one more layer at the core is not going to create that much of an extra load on the server, and it means that there is no way the traffic can be sniffed at any point - for example a trojan could sniff localhost traffic. also, using onion routing defeats the one way in which SSL can be attacked, by man-in-the-middle intermediaries on the network pathway, which of course cannot be known within the tor network. Also, it should be noted that tor exit nodes could potentially be modified to become men-in-the-middle, although this would not be possible without compromising the key of the server being contacted - another aspect of the advantage of using tor. onion addresses are impossible to remember though - which brings me to another idea - of a name resolution system within the tor network so simpler names can be used. this would require a second directory system, i don't know if it is practical or not, but i thought i should put the idea out there because i2p has name resolution systems, and benig able to type in oniondomainname.onion rather than u15syoa125au.onion would be nice. it would increase the rate of take-up of hidden services, both use and hosting. The other thing that could be interesting of course is an onion-only search engine, which could either compliment or reduce the need for vanity names. Still, I don't see why the directory servers can't maintain this info. It would have to (for the most part) be first-come first-served, and I suppose some sort of uptime monitoring should also play a part (i.e. if you don't use it for say 6 months, you lose it). Shame there's not a whole lot of clients that make use of SRV records, as an onion specifier in there could prove remarkably useful in some way. -- If you aren't going to try something, then we might as well just be friends. We can't have that now, can we? -SK Dan Mahoney, December 9, 1998 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: nym-0.4 released (now includes Javascript)]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Fri, 21 Oct 2005 09:22:34 + (UTC) To: [EMAIL PROTECTED] Subject: nym-0.4 released (now includes Javascript) Reply-To: [EMAIL PROTECTED] The most notable feature in this release of nym is that you can now use nym entirely from your web browser: http://www.lunkwill.org/src/nym/javascript/jsnymclient.html Until someone figures out how to create client certificate requests in Javascript, the CA will have to do so instead (or, you could generate the request on a separate machine and paste it in with a trivial hack). This means the CA will know your certificate's private key; this is bad if you want to make sure you can never be impersonated. It's actually good if you want deniability, since you can always claim that the CA chose to impersonate you. There are other miscellaneous bugfixes which break compatibility with earlier versions. Sources (including the javascript client) are available here, as always: http://www.lunkwill.org/src/nym/ -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: nym-0.3 released]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Thu, 13 Oct 2005 01:17:09 + (UTC) To: [EMAIL PROTECTED] Subject: nym-0.3 released Reply-To: [EMAIL PROTECTED] Hacking MediaWiki to map client certificates to IP addresses turns out to be quite trivial. nym-0.3 includes the 17 line patch, as well as the security fix proposed by cyphrpunk. The live demo at erg.no-ip.org now includes a live, patched MediaWiki called NymWiki. http://lunkwill.org/src/nym/nym-0.3.tar.gz http://www.lunkwill.org/src/nym/Readme http://www.lunkwill.org/src/nym/CHANGELOG If you want to be able to edit wikipedia through tor, I suggest you try out the code and email me, so that we can make a case that there's actual demand for inclusion of the patches. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Interoperating with p2p traffic]
- Forwarded message from Brian C [EMAIL PROTECTED] - From: Brian C [EMAIL PROTECTED] Date: Wed, 12 Oct 2005 18:26:58 -0700 To: [EMAIL PROTECTED] Subject: Re: Interoperating with p2p traffic User-Agent: Thunderbird 1.4 (Macintosh/20050908) Reply-To: [EMAIL PROTECTED] Hi, Matt Thorne wrote: That isn't a bad Idea, and possibly something that They (with help ofcourse :-) could build into their P2P software. Probably not a bad thing for them to lookinto just for their own use, not because We ask them to, but becuase that would really mess with the heads of the people at (Insert 4 letter accronym here). question: how do the people who feel posesive towards tor think about this idea? -=Matt=- On 10/12/05, *Arrakistor* wrote What if we designated some type of tor family specifically for p2p content, and coordinated with the software developers? If an anonymizing service based on Tor were integrated into some p2p project or if a fork of Tor were to devote itself to serving p2p, then that should only be encouraged by the current Tor community if 1. It didn't take away any current tor servers or tor resources. 2. It used another name and was clearly its own standalone effort. The reason for 1 is obvious. If the point is to make Tor more usable, then we shouldn't support a migration of its resources elsewhere. The reason for 2 should also be obvious. Tor is a neutral technology that allows privacy. Some people use their privacy for uses we want to support; others for uses we wish they wouldn't engage in. But, if something were called Tor and were devoted to p2p traffic then it would taint the whole Tor project. Don't get me wrong. p2p also has legitimate uses. But in the current climate anything remotely associated with file-sharing is assumed to be illegal. Let's not let that shadow be cast upon Tor. It has enough reputational problems already. Also, Tor is open source. If someone wants to take the code and change it to use their own farm of servers exclusively for p2p traffic then there's nothing the Tor community can do to stop them. I'm not suggesting we should try to stop them. Rather, I'm suggesting we insist that if someone does do that, then they should not call it Tor or anything confusingly similar. Brian - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] reply from Tropos on 1 more on Limits on wireless le ave U.S. at risk]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Tue, 18 Oct 2005 11:07:11 -0500 To: ip@v2.listbox.com Subject: [IP] reply from Tropos on 1 more on Limits on wireless le ave U.S. at risk Reply-To: [EMAIL PROTECTED] X-Mailer: EPOC Email Version 2.10 ___ Forward Header ___ Subject:RE: [IP] more on Limits on wireless leave U.S. at risk Author: [EMAIL PROTECTED] Date: 18th October 2005 6:09:16 am Dave, Tropos has shipped a couple of hundred of our Tropos 5210 mesh routers into MS and LA in the days following the storm, and had a few hundred installed in the stricken area previously. These are high-power (36 dBm), high rx sensitivity (-100 dBm), outdoor-constructed 802.11b/g access points with embedded mesh routers so they can backhaul wirelessly amongst each other to a source of Internet connectivity. Each has a 1,000 ft plus range to an outdoor Wi-Fi device, emergency vehicle with external antenna or building with a window-mounted CPE. So, a couple of hundred nodes represents 10-15 sq mi or so of contiguous coverage in typical configuration. Every 10 nodes or so are fed with a Motorola Canopy WiMAX link, typically shot from the roof of an MCI PoP, or from city backhaul locations. These devices, at these densities, are non line of sight so can be installed by city workers with bucket trucks on street lamps, with power taken from street-light photo cells. They will self-configure, find their backhaul, optimize throughput and route around problems. They can be battery and solar-powered due to their low wattage (28 watts or so). Last I have heard, we were in 25 or so FEMA and Red Cross shelters in NO, Biloxi, Lamar-Dixon and Baton Rouge. We are around the NO airport and on a couple of cruise ships off the gulf that are housing FEMA workers. We had 200 nodes previously installed in high-crime areas of NO doing video surveillance. As the power has been restored to the street lights, these nodes have come back up on their own and are performing their functions again. We are now in the process of expanding that network as a force multiplier for the police. Data applications as well as Vonage phones and Skype are active on the networks. The CIO of NO is actually in DC today testifying about the benefits of Wi-Fi mesh. Hope that helps. You can see more on our technology at www.tropos.com Ron Sege President and CEO Tropos Networks 555 Del Rey Ave Sunnyvale, CA 94085 www.tropos.com 408-331-6810 office 650-861-7564 cell 617-407-5000 international cell 408-331-6530 fax The leading supplier of products for building true metro-scale Wi-Fi mesh networks. -Original Message- From: David P. Reed [mailto:[EMAIL PROTECTED] Sent: Monday, October 17, 2005 5:09 PM To: [EMAIL PROTECTED] Cc: Ip Ip; [EMAIL PROTECTED] Subject: Re: [IP] more on Limits on wireless leave U.S. at risk Gerry Faulhaber wrote: Reed claims firms were offering WiMax and WiFi mesh networks for first responders in the wake of Katrina and Rita. He also mentions the role of municipal WiFi in this effort. Coulda happened, but it seems wildly unlikely. Is there any proof of this? I'm a bit skeptical about Reed Hundt's broad claims, too. However, I do know that Tropos and others who have such technology were attempting to demonstrate the value of their systems post-Katrina, so there almost certainly was some deployment, given the value to the companies of the opportunity to show their stuff. I've cc'ed Ron Sege of Tropos, who may have more direct knowledge and data. - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: questions about hidden service hashes, and experiences running hidden services]
- Forwarded message from Mike Perry [EMAIL PROTECTED] - From: Mike Perry [EMAIL PROTECTED] Date: Sun, 16 Oct 2005 01:28:24 -0500 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: questions about hidden service hashes, and experiences running hidden services User-Agent: Mutt/1.4.1i Reply-To: [EMAIL PROTECTED] Thus spake loki tiwaz ([EMAIL PROTECTED]): now, to the question which concerns me. I read in the tor spec that the hidden service address is an SHA1 hash of the server public key. I'm not sure if anyone here is aware of this (but i seriously doubt it) - SHA1 is now no longer secure. If the public key were equal or shorter than the length of the hash, this would mean that the hidden service .onion address could be cracked and the public key discovered, and the public key would then be able to be searched in the directory and the ip address revealed. I apologise if this is a question that has already been covered, my reading of the specs was not deep although i looked some ways, i couldn't discern whether the possibility of inverting the hash and identifying the IP through the directory was a possibility, so i thought i'd ask the list and see if anyone can answer this question. I realise that if the data used to generate a hash with an insecure function is longer than the hash produced that there is no issue. I just want to be sure about the security of the hidden services before i go announcing the address any further than here without knowing if giving this address is going to compromise my IP address - cos that would defeat the purpose of doing it at all. A couple of points. First, unless I've fallen behind, SHA1 is only broken to the point where you can generate two different arbitrary datum and have them result to the same hash. This is not the same as being able to undo SHA, or to even determine an arbitary collision to a fixed hash. Unless I've missed something. Second, even if this were the case, the hidden service is supposedly only listed with the introduction points that the service connected to through Tor. Assuming Tor remains unbroken, these Intro Points cannot reveal the hidden service IP, and the public key of the hidden service is not secret information anyway. Here are some slides that illustrate the process of connecting to a hidden service: http://www.freehaven.net/~arma/wth3.pdf The one thing I would advise against is running your hidden service on the same IP as your Tor server (or at least do not announce this fact). This can leave you vulnerable to an intersection attack, where the attacker keeps track of uptime of your hidden service and compares it to uptime stats of the various tor servers. You only have 300-some nodes to hide among. Incidentally, I would like to know exactly which directory server listing hidden services are published in. I don't see any of them in http://belegost.seul.org/ for example.. -- Mike Perry Mad Computer Scientist fscked.org evil labs - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] READ more on Location tracking -- for people, products, places -- is fast coming into its own / It's 11 o'clock. Do you know where your _______ is?]
; the intermediary _does not have to know anyone's location at all_.) (2) The client says I'm in New York City; the server says, OK, here is a map of all of New York City, and the locations of all your friends who told me that they were in New York City. The client then picks out the region of the map that's relevant and displays the locations of friends who appear to be nearby. (3) The client says I'm on the Upper West Side in New York; the server says, OK, here is a map of the Upper Wide Side, and the locations of all your friends in that neighborhood; the client again displays the subset that it finds relevant. (4) The client says I'm on the east side of Broadway between 93rd and 94th; the server says Your friend Josephine is on Broadway between 94th and 95th; your friend Sam is on Amsterdam Avenue between 92nd and 93rd; your friend Kate is headed west from Central Park; your friend Jim just walked out of the building across the street, take a look!. If people developing these applications are willing to go a little more coarse-grained than what they have the _ability_ to do, privacy will be better protected. Second, there's the question of how long information is retained. If it's retained as long as possible, it's a greater temptation for subpoenas, and a virtual certainty that these subpoenas will eventually become routine -- for law enforcement, divorce, child custody, employment and worker's compensation litigation, and probably other things we haven't thought of yet. Not to mention the traditional risks that it will be stolen, or that some successor-in-interest, in dire financial straits, will decide to sell it off to the highest bidder. It takes an effort to overcome the temptation to keep things forever, but a data-retention policy would do a lot to protect privacy here. -- Seth David Schoen [EMAIL PROTECTED] | This is a new focus for the security http://www.loyalty.org/~schoen/ | community. The actual user of the PC http://vitanuova.loyalty.org/ | [...] is the enemy. | -- David Aucsmith, IDF 1999 - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: cost to install surveillance cameras in public places]
- Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Date: Thu, 13 Oct 2005 03:37:01 -0400 (EDT) To: kragen-tol@canonical.org Subject: cost to install surveillance cameras in public places Suppose you wanted to plant a hidden camera for some long period of time and capture photos of all that went past. You'd like to never again have to enter the place where it's hidden, and only visit it rarely; you'd like it to be small; and you'd like it to last a long time. For example, the book The Social Life of Small Urban Spaces was based on a few years of research in this vein using Super 8 cameras for time-lapse photography. It appears to me that this equipment should now be incredibly cheap. USB webcams that capture 100-kB 640x480 JPEGs are on the order of $10. I think 4-port USB hubs (again, on the order of $10) contain all the hardware necessary to act as USB host controllers; one could imagine integrating the USB hub hardware with a small single-board computer with SD/MMC and Bluetooth interfaces, for a total cost on the order of $50 plus up to 4 cameras and their USB cables, and an MMC card ($50-$110). This device would presently be limited in smallness only by the size of its power supply, USB ports, and multi-chip integration, so it could be concealed in many places. You could probably run it on 200mW when running (for less than a second) and 1mW when idle. You could drop by periodically with an inconspicuous Bluetooth device, such as a cellphone or laptop, to download the pictures (say, 4 cameras * 100kB/shot/camera * 4 shots / minute * 60 minutes/hour * 24 hours/day = 2.3GB/day; but one shot per minute is only 144MB/day). Anyone snooping over Bluetooth at the time could tell that a lot of data was being sent over Bluetooth (1megabit/sec? not sure; but at that speed you'd have to spend 2300 seconds in the vicinity.) Alternatively, you could use a directional antenna from hundreds of meters away (the Bluesniper folks managed to do 1km.) An adaptive surveillance algorithm could shoot four times per minute until the data card was full, followed by twice a minute (replacing every other old shot, starting with the oldest) until the data card was all full at twice a minute, then once per minute (thinning out old shots to once a minute) until it was full again, etc. Supposing that USB 12Mbps transfers were the limiting factor, you'd need about 67ms of on time per shot, or (according to my 200mW estimate above) 13.4 mJ. My laptop's Li-ion battery supposedly holds around 46Wh, or 165kJ (abridged info below): $ cat /proc/acpi/battery/BAT1/state present rate:1227 mA remaining capacity: 2579 mAh present voltage: 11300 mV $ cat /proc/acpi/battery/BAT1/info design capacity: 4500 mAh last full capacity: 4067 mAh design voltage: 10800 mV model number:XM2018P02 battery type:Li-ION 11.3V * 4.067Ah = 46Wh. On that basis, my laptop's battery could power 12 000 000 invasions of privacy by this system --- saving that many camera shots to an MMC card. It might only be able to power 4 000 000 invasions of privacy if it had to transmit them all over Bluetooth. Still, that's nearly six months in the four-shots-with-four-cameras-per-minute maxi configuration described above, where you'd have to come download up your photos at least once a day, and at one camera shooting once per minute, it would last 8 years. (I'm assuming that the webcams power up instantly. This may be unreasonable.) Obviously you could do a similar job with audio surveillance, but ironically, this may consume more storage and power; minimally comprehensible speech is 10kbps under the best of conditions, so you'd need at least 108MB/day, and probably several times that to get anything useful. You'd need some very-low-power constantly-on device to buffer the audio so you wouldn't have to run the CPU all the time. A similar system, but without the cameras or other transducers, could serve as a maildrop or backup server (for data with high value per byte, obviously). We can anticipate that the power and monetary cost of data storage and transmission will decrease considerably more before Moore's Law runs out. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
/. [Future Cell Phone Knows You By Your Walk]
Link: http://slashdot.org/article.pl?sid=05/10/15/0640206 Posted by: Zonk, on 2005-10-15 12:39:00 jangobongo writes Researchers at the [1]VTT Technical Research Centre of Finland have come up with a unique way to secure your cell phone if it should get lost or stolen: 'Gait code'. Motion sensors in the phone would [2]monitor the walking pattern (or gait) of whoever is in possession of the phone, and if the 'gait' doesn't match a pre-established biometric the phone would require a password to operate. The prototype cell phone correctly identified when it was being carried by someone other than its owner 98% of the time. The research team [3]points out (powerpoint document) that this method could also work for PDAs, laptops, USB tokens, smart cards, wallets, suitcases, and guns. References 1. http://www.vtt.fi/indexe.htm 2. http://www.newscientist.com/article.ns?id=dn8161 3. http://www.vtt.fi/vtt/uutta/2005/img/wsbr/tiedoteeng.doc - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Location tracking -- a bill of rights?]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Thu, 13 Oct 2005 19:21:22 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] Location tracking -- a bill of rights? X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Brian Smithson [EMAIL PROTECTED] Date: October 13, 2005 4:55:01 PM EDT To: [EMAIL PROTECTED] Subject: Location tracking -- a bill of rights? [OK for IP if it's OK with you] Dave, I think Dennis' post about dodgeball gives a real life example of what I think should be the basic Bill of Rights for tracking devices. This is kind of rough, as I am making it up as I write. And pardon my wishful thinking :-). I. I should be informed of the existence of any tracking mechanism. This would include those which are integral to a product like in a cellphone, those which are deliberate add-ons like if dodgeball is an app I'm installing on my phone, and those which are embedded for some purpose unrelated to my own purpose like an RFID inventory- tracking tag in a sweater that I'm buying. Many people don't know that their phone can be used to track their location. Many more won't know that their *sweater* could be used to track their location. II. I should be able to turn the tracking function on and off. Of course, this may render the item useless, like a cellphone which can't communicate with its network. RFID companies won't like this one because RFIDs usually have no external controls and cost is a major factor in RFID adoption, so maybe it will be sufficient in some cases to simply be able to turn the function off (permanently). After I've bought the sweater, inventory tracking is no longer needed. III. I should be able to give explicit permission for trackers to track me for specific purposes. This would be like GLBA privacy laws, only let's try to make them actually work :-). So the cellphone carrier could track me, but only for the purpose of making the phone work unless I give them permission to do something else with that information. IV. I should be able to give permission through intermediaries. For example, I might want to give my cellphone carrier permission to give my tracking information to a third party for a particular purpose. This could have multiple levels, such as if (through a third party service, let's say dodgeball) I gave permission to Bob and Carol but denied it to Ted and Alice. V. I should own my tracking information. Those who facilitate tracking would have a license to the tracking data. I should be able to control how long it is retained by revoking that license. VI. Tracking facilitators are common carriers. Let's say I have a Verizon phone. If I want Verizon to make my tracking data available to another party, such a request should not be unreasonably refused. In other words, if I want Verizon to make my tracking data available to dodgeball, for example, they should not be able to refuse and insist that I use their social networking service instead. VII. I should be able to access records of who has been tracking me, when, and how. This may not be easy all the way to a personal level, but we should try. I can think of cases when I would want to know that on March 19th, Joe Blow at the phone company looked at my location records for the month of February. Or I might just want to know who location-enabled-spammed me when I had not given anyone permission to do that. VIII, IX, and X. I know there should be 10 rights, but I couldn't think of them. -- - Brian Smithson [EMAIL PROTECTED] - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: cypherpunks@minder.net closing on 11/1
On Thu, Oct 13, 2005 at 04:49:00PM -0400, Brian Minder wrote: The minder.net CDR node will be shutting down on November 1, 2005. This includes the cypherpunks-moderated list. Please adjust your subscriptions accordingly. Thanks Brian. I'm suggesting [EMAIL PROTECTED] as an alternative node to subscribe to. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: cypherpunks@minder.net closing on 11/1
On Thu, Oct 13, 2005 at 04:49:00PM -0400, Brian Minder wrote: The minder.net CDR node will be shutting down on November 1, 2005. This includes the cypherpunks-moderated list. Please adjust your subscriptions accordingly. Thanks Brian. I'm suggesting [EMAIL PROTECTED] as an alternative node to subscribe to. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Software from Low-Cost Traffic Analysis of Tor]
- Forwarded message from Steven J. Murdoch [EMAIL PROTECTED] - From: Steven J. Murdoch [EMAIL PROTECTED] Date: Tue, 11 Oct 2005 23:26:10 +0100 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Software from Low-Cost Traffic Analysis of Tor User-Agent: Mutt/1.4.1i Reply-To: [EMAIL PROTECTED] Some of you might have read the paper Low-Cost Traffic analysis of Tor[1], by myself and George Danezis. I have now released the code I used to run these experiments, in case it will help any future research. For more information, and to download the code, see: http://www.cl.cam.ac.uk/users/sjm217/projects/anon/#torta If you have any comments, suggestions or questions, please let me know. Thanks, Steven Murdoch. [1] http://www.cl.cam.ac.uk/users/sjm217/papers/oakland05torta.pdf -- w: http://www.cl.cam.ac.uk/users/sjm217/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [ANNOUNCE] OpenSSL version 0.9.8a and 0.9.7h released]
- Forwarded message from Mark J Cox [EMAIL PROTECTED] - From: Mark J Cox [EMAIL PROTECTED] Date: Tue, 11 Oct 2005 12:20:20 +0100 (BST) To: openssl-announce@openssl.org, openssl-users@openssl.org, openssl-dev@openssl.org Subject: [ANNOUNCE] OpenSSL version 0.9.8a and 0.9.7h released Reply-To: openssl-dev@openssl.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8a and 0.9.7h released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8a of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release and incorporates changes and bugfixes to the toolkit. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We also release 0.9.7h, which contains the same security bugfix as 0.9.8a and a few small bugfixes compared to 0.9.7g. These updates contain a fix for CAN-2005-2969, a potential SSL 2.0 rollback reported by Yutaka Oiwa. For more details of the security issue being fixed in this release please see http://www.openssl.org/news/secadv_20051011.txt We consider OpenSSL 0.9.8a to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ For those who want or have to stay with the 0.9.7 series of OpenSSL, we strongly recommend that you upgrade to OpenSSL 0.9.7h as soon as possible. It's available in the same location as 0.9.8a. The distribution file names are: * openssl-0.9.8a.tar.gz MD5 checksum: 1d16c727c10185e4d694f87f5e424ee1 SHA1 checksum: 2aaba0f728179370fb3e86b43209205bc6c06a3a * openssl-0.9.7h.tar.gz MD5 checksum: 8dc90a113eb8925795071fbe52b2932c SHA1 checksum: 9fe535fce89af967b29c4727dedd25f2b4cc2f0d The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf M?ller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz J?nickeBodo M?ller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUBQ0uaXu6tTP1JpWPZAQKXyAP/V6xGTooFL52d9Ep0qd0DDaZCSHlukk48 DWljg3EY9QF9BfzLVB1BDbLNuHAyYpeAEjvte4kwHV1vWvAoiabV+XMx8kuoRTxi O+8NLOeOc1hilC0hLDYfM+XPq5k9dPiOfQvYpnqiwnr/TnwSBh11D+EEcoZlQToE a6qRMTC3mAM= =bwJD -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
/. [You Need Not Be Paranoid To Fear RFID]
Link: http://slashdot.org/article.pl?sid=05/10/10/0643235 Posted by: Zonk, on 2005-10-10 10:32:00 An anonymous reader writes A story at the Boston Globe [1]covers extensive privacy abuses involving RFID. From the article: Why is this so scary? Because so many of us pay for our purchases with credit or debit cards, which contain our names, addresses, and other sensitive information. Now imagine a store with RFID chips embedded in every product. At checkout time, the digital code in each item is associated with our credit card data. From now on, that particular pair of shoes or carton of cigarettes is associated with you. Even if you throw them away, the RFID chips will survive. Indeed, Albrecht and McIntyre learned that the phone company BellSouth Corp. had applied for a patent on a system for scanning RFID tags in trash, and using the data to study the shopping patterns of individual consumers. I think they may be going a little overboard with their stance, but it's always interesting to talk about. References 1. http://www.boston.com/business/globe/articles/2005/10/10/you_need_not_be_paranoid_to_fear_rfid?mode=PF - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [p2p-hackers] Workshop on Dependable and Sustainable Peer-to-Peer Systems]
- Forwarded message from Sam Joseph [EMAIL PROTECTED] - From: Sam Joseph [EMAIL PROTECTED] Date: Tue, 11 Oct 2005 03:53:51 +0900 To: Peer-to-peer development. [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [p2p-hackers] Workshop on Dependable and Sustainable Peer-to-Peer Systems Organization: NeuroGrid http://www.neurogrid.net/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Reply-To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] [CALL FOR PAPERS] The First International Workshop on Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) is the first workshop which focuses on dependability and sustainability of P2P systems, with respect to their designs, operations, applications and social impacts. Peer-to-Peer (P2P) can be a promising technology on which we can depend lives of ours and our children, upon which we can build sustainable societies. Designs of P2P systems are characterized by their usage of overlay networks such that there is symmetry in the roles among participants. This implies distribution of authorities, not only preventing introduction of single points of failure, but also assuring a level of autonomy which allows many of us to spontaneously start, maintain, or recover from failures of, such systems. Although difficulties exist, such as uncertainty in the trust among participants, one needs to be aware that such difficulties are, in many parts, due to our own human nature; depending on P2P is, in fact and literally, depending on ourselves and our friends, which seem to be the only ones we can trust anyway, when it comes to our own survival. The goal of this workshop is to share experiences, insights and new ideas, and set forth research agendas and suggestive future directions by collaborations among researchers with different disciplines and with similar interests toward dependability and sustainability. The following is a non-exhaustive list of relevant topics: ** Designs and operations of dependable and sustainable P2P systems - Self-organization and emergence - Attack-resistance - Fault tolerance - Sustainable operations - Sustainable mutual trust - Sustainable reciprocal relationships ** Applications and social impacts of dependable and sustainable P2P systems - Sustainable economy - Sustainable governance - Sustainable lifestyles - Rescue activities - Post-catastrophic recovery - Tackling environmental problems The program of the workshop will be a combination of invited talks, paper presentations and discussions. [SUBMISSION INSTRUCTIONS] The workshop invites your contributions of previously unpublished papers, which will be selected based on their originality, technical merit and topical relevance. Papers will also be selected by the likelihood that they will lead to interesting and fruitful discussions at the workshop. Your contributions should be formatted acoording to the IEEE Computer Society Press Proceedings Author Guidelines: 10-point Times, single-spaced, two-column format (see http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm for detail). Each of your contributions should not exceed 8 pages. See the workshop web site (http://das-p2p.wide.ad.jp/) for the submission procedure. [PUBLICATION] Proceedings of the workshop will be published by IEEE Computer Society Press. [IMPORTANT DATES] Paper submission due: December 4th, 2005 Notification of acceptance: January 15th, 2006 Camera-ready copies due: February 1st, 2006 Author registration due: February 1st, 2006 Workshop: April 20th-22nd, 2006 (exact date is to be decided) [REGISTRATION] Workshop registration will be handled by the ARES 2006 organization along with the main conference registration. [ORGANIZING COMMITTEE] Program co-chairs: Yusuke Doi Communication Platform Laboratory, Corporate RD Center, TOSHIBA Corporation 1 Komukai-Toshiba-Cho, Saiwai-Ku, Kawasaki Kanagawa 212-8582 Japan Youki Kadobayashi Graduate School of Information Science Nara Institute of Science and Technology Takayama 8916-5, Ikoma Nara 630-0192 Japan Kenji Saito (main contact) Graduate School of Media and Governance Keio University 5322 Endo, Fujisawa Kanagawa 252-8520 Japan [EMAIL PROTECTED] [PROGRAM COMMITTEE] See the workshop web site (http://das-p2p.wide.ad.jp/). - ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Tor 0.1.1.8-alpha is out]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Fri, 7 Oct 2005 18:26:23 -0400 To: [EMAIL PROTECTED] Subject: Tor 0.1.1.8-alpha is out User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] This is the eighth development snapshot for the 0.1.1.x series. The main changes are that clients now use the new directory protocol, that servers that are tight on resources stop advertising their DirPort, and that we use OpenSSL's AES if it's available. http://tor.eff.org/download.html Changes in version 0.1.1.8-alpha - 2005-10-07 o New features (major): - Clients don't download or use the directory anymore. Now they download and use network-statuses from the trusted dirservers, and fetch individual server descriptors as needed from mirrors. See dir-spec.txt for all the gory details. - Be more conservative about whether to advertise our DirPort. The main change is to not advertise if we're running at capacity and either a) we could hibernate or b) our capacity is low and we're using a default DirPort. - Use OpenSSL's AES when OpenSSL has version 0.9.7 or later. o New features (minor): - Try to be smart about when to retry network-status and server-descriptor fetches. Still needs some tuning. - Stop parsing, storing, or using running-routers output (but mirrors still cache and serve it). - Consider a threshold of versioning dirservers (dirservers who have an opinion about which Tor versions are still recommended) before deciding whether to warn the user that he's obsolete. - Dirservers can now reject/invalidate by key and IP, with the config options AuthDirInvalid and AuthDirReject. This is useful since currently we automatically list servers as running and usable even if we know they're jerks. - Provide dire warnings to any users who set DirServer; move it out of torrc.sample and into torrc.complete. - Add MyFamily to torrc.sample in the server section. - Add nicknames to the DirServer line, so we can refer to them without requiring all our users to memorize their IP addresses. - When we get an EOF or a timeout on a directory connection, note how many bytes of serverdesc we are dropping. This will help us determine whether it is smart to parse incomplete serverdesc responses. - Add a new function to change pseudonyms -- that is, to stop using any currently-dirty circuits for new streams, so we don't link new actions to old actions. Currently it's only called on HUP (or SIGNAL RELOAD). - On sighup, if UseHelperNodes changed to 1, use new circuits. - Start using RAND_bytes rather than RAND_pseudo_bytes from OpenSSL. Also, reseed our entropy every hour, not just at startup. And entropy in 512-bit chunks, not 160-bit chunks. o Fixes on 0.1.1.7-alpha: - Nobody ever implemented EVENT_ADDRMAP for control protocol version 0, so don't let version 0 controllers ask for it. - If you requested something with too many newlines via the v1 controller protocol, you could crash tor. - Fix a number of memory leaks, including some pretty serious ones. - Re-enable DirPort testing again, so Tor servers will be willing to advertise their DirPort if it's reachable. - On TLS handshake, only check the other router's nickname against its expected nickname if is_named is set. o Fixes forward-ported from 0.1.0.15: - Don't crash when we don't have any spare file descriptors and we try to spawn a dns or cpu worker. - Make the numbers in read-history and write-history into uint64s, so they don't overflow and publish negatives in the descriptor. o Fixes on 0.1.0.x: - For the OS X package's modified privoxy config file, comment out the logfile line so we don't log everything passed through privoxy. - We were whining about using socks4 or socks5-with-local-lookup even when it's an IP in the virtual range we designed exactly for this case. - We were leaking some memory every time the client changes IPs. - Never call free() on tor_malloc()d memory. This will help us use dmalloc to detect memory leaks. - Check for named servers when looking them up by nickname; warn when we'recalling a non-named server by its nickname; don't warn twice about the same name. - Try to list MyFamily elements by key, not by nickname, and warn if we've not heard of the server. - Make windows platform detection (uname equivalent) smarter. - It turns out sparc64 doesn't like unaligned access either. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
[EMAIL PROTECTED]: Wikipedia proposal]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Fri, 7 Oct 2005 07:57:11 + (UTC) To: [EMAIL PROTECTED] Subject: Wikipedia proposal Reply-To: [EMAIL PROTECTED] I just posted this to wikitech-l: There has been a lot of discussion lately on the or-talk list about how to let tor and other anonymizing proxy users edit wikipedia without allowing vandals free rein. Several straightforward approaches have been proposed, such as holding edits in escrow pending approval by a trusted user, and requiring anonymizing network users to login before posting. The latter idea in particular could easily be abused, since abusers can create a new account for each edit. Roger Dingledine, tor's author, suggested creating a pseudonym service using a cryptographic construction called blind signatures: http://www.rsasecurity.com/rsalabs/node.asp?id=2339 Basically, Alice can generate a token, mathematically blind it (obscuring its value), have it signed, then unblind the signature. Anyone can verify that the signature on the token is valid, but nobody, including the signer, can link the blinded value Alice had signed with her unblinded token. I implemented such a scheme which works as follows: * Alice creates and blinds a token, then submits it to a token server for signing. Optionally, the token server may have a list of IPs banned from wikipedia, and refuse to sign Alice's token if her IP is on the list. * The token server signs the blinded token, then records what IP address Alice used so that she can't obtain multiple tokens per IP address. Later, this will allow us to block Alice's IP address if she misbehaves, just as Wikipedia admins currently do, except that now it'll work even when she connects via tor. Token rationing could also be done based on other (more or less) scarce resources, including email addresses, captchas, CPU-intensive tasks or even money, just as I'm sure has been proposed for the vanilla wikipedia. The advantage of blind signatures is that tokens can be recorded and blocked without revealing the potentially sensitive underlying resource (such as a personal email address or IP address). * Alice can now turn on tor and present her token to wp, without revealing her actual IP address. This token takes the place of the IP address record currently stored along with article edits, and can be blacklisted just the same way that IPs are banned. * However, I implemented an intermediary step which has several advantages. Instead of presenting her token to wp, Alice generates an essentially empty client certificate and presents it via the tor network to a certificate authority (CA) for signing, along with the signed token. The CA records that the token has been spent (preventing her from receiving multiple certs per token), then signs her cert just as Verisign would sign a server SSL certificate. Since she connects via tor, the CA doesn't learn her real IP address. * Alice installs the client certificate in her browser, then connects to a special wp server running an SSL server that demands valid client certificates from our CA. That configuration takes only 4 lines in my apache-ssl server's httpd.conf. Apache automatically sets environment variables which identify the client certificate, and which can be used in place of the REMOTE_ADDR variable currently used to record users' incoming IP addresses when marking page edits. Blocking a client cert would then be just as easy as blocking an IP address. All of Alice's edits will be marked with that identifier unless she obtains a new IP address (or other scarce resource) and repeats the process to obtain another certificate. Later, features can optionally be added which will allow her to have separate identifiers for each edit (protecting her in case, say, her repressive government confiscates her computer in order to find out if she wrote a particular article they disagree with). I have already released code to implement this system, with the exception of the wp-specific code. I sent the proposal to both the or-talk lists and the cryptography list at metzdowd.com on Monday. Next I'd like your comments, before I dive into the mediawiki code (or find someone willing to help with this part). Once the feature is complete, we can set up a live test wiki for people to bang on, before we consider implementation on the live wp servers. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [extropy-chat] Worldwide SOS system]
- Forwarded message from David Lubkin [EMAIL PROTECTED] - From: David Lubkin [EMAIL PROTECTED] Date: Thu, 06 Oct 2005 13:53:10 -0400 To: ExI chat list [EMAIL PROTECTED] Subject: Re: [extropy-chat] Worldwide SOS system X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Reply-To: ExI chat list [EMAIL PROTECTED] Kevin Freels wrote: This is a nice, productive thread, but one thing in missing - infrastructure. When my father was building mini-RPVs in our living room in the 1970's for the Israelis, he was also figuring out how to use them. Low-cost was inherent in his concept. He could turn a profit selling them for a few thousand each. They were essentially light-weight wooden planes powered by lawn mower engines, and could heft a 75 kg payload. As the ideas morphed into Pentagon procurement, the vehicle requirements became gold-plated, and the price tag went up 200x or more. I haven't looked at the specifics of the current generation of drones to see how useful the add-on requirements are, but there's clearly great value in having many thousands of throw-away drones. The simplest warfare use is to carry 75 kg of explosives, fly around until you spot something more valuable, and then crash into it. The sticky point for your enemy is that a SAM or AAM to shoot it down could itself cost more than the drone. There are also civilian uses that fold into our thread. There are many search and rescue scenarios where it is too dangerous to send a flight crew out, where one could instead load a drone with 75 kg of emergency supplies. Perhaps we could take the comm ideas and add an assistance component, a la a network of long-duration blimps that serve as airborne hangers for a drone fleet. Just add uniforms, jerky movement, and Lady Penelope, and we have an international rescue operation. -- David Lubkin. ___ extropy-chat mailing list [EMAIL PROTECTED] http://lists.extropy.org/mailman/listinfo/extropy-chat - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Low-Cost Traffic Analysis of Tor]
- Forwarded message from Eugene Y. Vasserman [EMAIL PROTECTED] - From: Eugene Y. Vasserman [EMAIL PROTECTED] Date: Fri, 07 Oct 2005 15:07:23 -0500 To: [EMAIL PROTECTED] Subject: Re: Low-Cost Traffic Analysis of Tor Organization: University of Minnesota User-Agent: Thunderbird 1.4 (Windows/20050908) Reply-To: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi, Probabilistic guarantee is a timeliness guarantee - delivery is still guaranteed, but the time within which this delivery is made is not guaranteed. (We could provide a weaker guarantee - say, this will be delivered before the TCP session times out. However, a complex guarantee policy might introduce an unacceptable performance hit.) The point is that round-robin scheduling (as Tor does now) is too easy to predict. What I suggest does not require changing anything expect the mixing strategy (which right now is round-robin - no mixing at all). I still haven't had a chance to look at the mixing code to see if this could be done with low-enough overhead as to not be noticeable by end-users. I don't want to make the argument on the performance/penalty tradeoff yet because I'm hoping there won't be any significant performance hit. I suspect it's possible, and can only be determined through testing. I'll report on my progress, if and when when there is some. Thanks, Eugene Thus spake Paul Syverson: Hi Andrei, Who is this from? Question from a two second glance, which is all I can spare at the moment: probabilistic throughput guarantee? Does this imply probabilistic guarantee of delivery? If so, you're talking UDP or something not TCP in any case. In which case you're talking substantial change from current Tor. Thus maybe an interesting design theory suggestion, but something that will not be implementable in the system for years if ever. Gotta run, Paul On Fri, Oct 07, 2005 at 08:08:27PM +0100, Andrei Serjantov wrote: Greetings. Let me introduce myself. I'm a grad student and the U of MN in computer science. I've been working on anonymous network systems. I also had a chance to play with Tor, and read the Low-Cost Traffic Analysis of Tor paper (mentioned below). I have a general question: this may or may not decrease performance, but wouldn't locking and/or randomizing bandwidth per flow through a Tor server solve this problem? This attack seem comparable to a variant on SSL (and general crypto) timing attacks. Similar solutions could be applied. Also, since this attack relies on a malicious node being able to estimate its flow's likely performance through an honest node at any given time, Tor could apply a somewhat more complex mixing approach, making this attack more difficult. I was thinking of something like lottery scheduling, which is really easy to implement and, if done right, will not impose any noticeable CPU overhead, and still provide the same (albeit probabilistic, not deterministic) throughput guarantees for every flow. Please let me know your thoughts. I will hopefully have some time to spend implementing this in the near future, if there is a consensus that some of these suggestions would help. Before you start hacking, I would advocate writing down your mixing strategy and trying to show (or at least argue) that what you are doing has a reasonable anonymity/performance tradeoff. It's probably worth sticking my nose out and saying that Tor does not really want to do any mixing for performance reasons -- lower performance means lower number of users and hence lower anonymity sets against weaker adversaries. (hmm is this strictly true?? I suppose the anonymity set is the set of all people if you don't observe the entire network) A. - -- Eugene Y. Vasserman http://www.cs.umn.edu/~eyv/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDRtV74S3hfPlRZlkRA6KaAJ9v64LJ5OrqA22POcfZGu7gBNtrBQCbBLJ4 ovdIV2Q1EDDKF5G2/Hv9Y3A= =0/lG -END PGP SIGNATURE- - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Handbook for bloggers and cyber-dissidents]
- Forwarded message from Thomas Sj?gren [EMAIL PROTECTED] - From: Thomas Sj?gren [EMAIL PROTECTED] Date: Wed, 5 Oct 2005 23:20:14 +0200 To: [EMAIL PROTECTED] Subject: Handbook for bloggers and cyber-dissidents User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] Reporters Without Borders (Reporters sans fronti?res, RSF) has released a Handbook for bloggers and cyber-dissidents: http://www.rsf.org/rubrique.php3?id_rubrique=542 Topics include: How to blog anonymously Technical ways to get around censorship Ensuring your e-mail is truly private Internet-censor world championship From the chapter How to blog anonymously: Step five - Onion Routing through Tor [...] Given the complexity of the technology, Sarah is pleasantly surprised to discover how easy it is to install Tor, an onion routing system. She downloads an installer which installs Tor on her system, then downloads and installs Privoxy, a proxy that works with Tor and has the pleasant side benefit of removing most of the ads from the webpages Sarah views. After installing the software and restarting her machine, Sarah checks noreply.org and discovers that she is, in fact, successfully cloaked by the Tor system - noreply.org thinks shes logging on from Harvard University. She reloads, and now noreply thinks shes in Germany. From this she concludes that Tor is changing her identity from request to request, helping to protect her privacy. This has some odd consequences. When she uses Google through Tor, it keeps switching language on her. One search, its in English - another, Japanese. Then German, Danish and Dutch, all in the course of a few minutes. Sarah welcomes the opportunity to learn some new languages, but shes concerned about some other consequences. Sarah likes to contribute to Wikipedia, but discovers that Wikipedia blocks her attempts to edit articles when shes using Tor. Tor also seems to have some of the same problems Sarah was having with other proxies. Her surfing slows down quite a bit, as compared to surfing the web without a proxy - she finds that she ends up using Tor only when shes accessing sensitive content or posting to her blog. And shes once again tied to her home computer, since she cant install Tor on a public machine very easily. Most worrisome, though, she discovers that Tor sometimes stops working. Evidently, her ISP is starting to block some Tor routers - when Tor tries to use a blocked router, she can wait for minutes at a time, but doesnt get the webpage shes requested. -- - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: TOR in Java?]
- Forwarded message from Nick Mathewson [EMAIL PROTECTED] - From: Nick Mathewson [EMAIL PROTECTED] Date: Thu, 6 Oct 2005 14:51:09 -0400 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: TOR in Java? User-Agent: Mutt/1.4.2.1i Reply-To: [EMAIL PROTECTED] On Thu, Oct 06, 2005 at 08:21:20PM +0200, Oliver S. wrote: I think that TOR-servers don't need to be that performant as their usage is currently and will in future be very uncommon. So it would be easier to deveop TOR in Java (or maybe even C#?). This would also reduce the probability of security-issues like buffer-overflows (may- be it would be even possible to go back the TOR-chain through chai- ned buffer-overflows, i.e. BOs that go from one gate in the chain from the previous). What do you think of my idea. I think your idea is a fine one for somebody's spare time; we always need more implementations for the Tor protocol, and Java is a popular choice these days. You might want to start with the code from the Java Anon Proxy people; I don't know their current status here, but for a while, they had a working Tor *client* written in Java. Of course, a server is significantly more complicated, so there would be a lot more work. As for the performance issue: you are completely wrong about Tor servers not needing CPU; at reasonable bandwidth, the requirements are high. Fortunately, most of the CPU is used for AES, DH, and RSA, all of which any sane implementation will implement in native code, so one might stand a chance of having a compatible implementation of the Tor protocol written in a less performance critical language. In other words: if you want to clone Tor in Java, feel free! We look forward to your work. Note, however, that I keep talking about compatible implementations here. Tor is 49 thousand lines right now[1], and we're trying to strengthen incrementally it all the time. Throwing out the implementation that we've been working on for the last four years and starting again from scratch is not likely to work for us. As for the rest of this thread: language choice is a classical bike-shed problem[2]. Please, tread lightly, and consider whether what you're saying needs to be said. If you're worried about Java: there's no risk we'll switch the main Tor implementation to it in the foreseeable future. If you want Java: great, get some programmers together and bang out an implementation. [1] Tor has about 37.6 klines of code, and 11.4 klines of comments. [2] On bikesheds: http://www.unixguide.net/freebsd/faq/16.19.shtml yrs, -- Nick Mathewson - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] more on USG RFI for metrics on the 'terror war']
] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Italy requires logging of personal info at cybercafes]
, according to the Interior Ministry. The ministry also reported that they are conducting rigorous surveillance of high-risk areas of terrorist activity and over 13,000 strategic locations in Italy. On Aug. 12 and 13 alone, a reported 32,703 checks were carried out on suspicious individuals. Despite the inconvenience, most Italians seem relatively unfazed by the law. If I am not doing anything wrong, fundamentally nothing is going to happen to me, says Mauro Pallotta, a young artist, after checking his e-mail at Savoni's cafe. URL: http://www.csmonitor.com/2005/1004/p07s01-woeu.htm - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hooking nym to wikipedia]
- Forwarded message from cyphrpunk [EMAIL PROTECTED] - From: cyphrpunk [EMAIL PROTECTED] Date: Tue, 4 Oct 2005 11:35:43 -0700 To: [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Subject: Re: Hooking nym to wikipedia Reply-To: cyphrpunk [EMAIL PROTECTED] On 10/3/05, Jason Holt [EMAIL PROTECTED] wrote: More thoughts regarding the tokens vs. certs decision, and also multi-use: This is a good summary of the issues. With regard to turning client certs on and off: from many years of experience with anonymous and pseudonymous communication, the big usability problem is remembering which mode you are in - whether you are identified or anonymous. This relates to the technical problem of preventing data from one mode from leaking over into the other. The best solution is to use separate logins for the two modes. This prevents any technical leakage such as cookies or certificates. Separate desktop pictures and browser skins can be selected to provide constant cues about the mode. Using this method it would not be necessary to be asked on every certificate usage, so that problem with certs would not arise. (As far as the Chinese dissident using net cafes, if they are using Tor at all it might be via a USB token like the one (formerly?) available from virtualprivacymachine.com. The browser on the token can be configured to hold the cert, making it portable.) Network eavesdropping should not be a major issue for a pseudonym server. Attackers would have little to gain for all their work. The user is accessing the server via Tor so their anonymity is still protected. Any solution which waits for Wikimedia to make changes to their software will probably be long in coming. When Jimmy Wales was asked whether their software could allow logins for trusted users from otherwise blocked IPs, he didn't have any idea. The technical people are apparently in a separate part of the organization. Even if Jimmy endorsed an idea for changing Wikipedia, he would have to sell it to the technical guys, who would then have to implement and test it in their Wiki code base, then it would have to be deployed in Wikipedia (which is after all their flagship product and one which they would want to be sure not to break). Even once this happened, the problem is only solved for that one case (possibly also for other users of the Wiki code base). What about blogs or other web services that may decide to block Tor? It would be better to have a solution which does not require customization of the web service software. That approach tries to make the Tor tail wag the Internet dog. The alternative of running a pseudonym based web proxy that only lets good users pass through will avoid the need to customize web services on an individual basis, at the expense of requiring a pseudonym quality administrator who cancels nyms that misbehave. For forward secrecy, this service would expunge its records of which nyms had been active, after a day or two (long enough to make sure no complaints are going to come back). As far as the Unlinkable Serial Transactions proposal, the gist of it is to issue a new blinded token whenever one is used. That's a clever idea but it is not adequate for this situtation, because abuse information is not available until after the fact. By the time a complaint arises the miscreant will have long ago received his new blinded token and the service will have no way to stop him from continuing to use it. I could envision a complicated system whereby someone could use a token on Monday to access the net, then on Wednesday they would become eligible to exchange that token for a new one, provided that it had not been black-listed due to complaints in the interim. This adds considerable complexity, including the need to supply people with multiple initial tokens so that they could do multiple net accesses while waiting for their tokens to be eligible for exchange; the risk that exchange would often be followed immediately by use of the new token, harming unlinkability; the difficulty in fully black-listing a user who has multiple independent tokens, when each act of abuse essentially just takes one of his tokens away from him. Overall this would be too cumbersome and problematic to use for this purpose. Providing forward secrecy by having the nym-based web proxy erase its records every two days is certainly less secure than doing it by cryptographic means, but at the same time it is more secure than trusting every web service out there to take similar actions to protect its clients. Until a clean and unemcumbered technological approach is available, this looks like a reasonable compromise. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100
[EMAIL PROTECTED]: Re: nym-0.2 released (fwd)]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Sun, 2 Oct 2005 22:23:50 + (UTC) To: cyphrpunk [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], cryptography@metzdowd.com Subject: Re: nym-0.2 released (fwd) Reply-To: [EMAIL PROTECTED] On Sun, 2 Oct 2005, cyphrpunk wrote: 1. Limting token requests by IP doesn't work in today's internet. Most Hopeless negativism. I limit by IP because that's what Wikipedia is already doing. Sure, hashcash would be easy to add, and I looked into it just last night. Of course, as several have observed, hashcash also leads to whack-a-mole problems, and the abuser doesn't even have to be savvy enough to change IPs. Why aren't digital credential systems more widespread? As has been suggested here and elsewhere at great length, it takes too much infrastructure. It's too easy when writing a security paper to call swaths of CAs into existance with the stroke of the pen. To assume that any moment now, people will start carrying around digital driver's licenses and social security cards (issued in the researcher's pet format), which they'll be happy to show the local library in exchange for a digital library card. That's why I'm so optimistic about nym. A reasonable number of Tor users, a technically inclined group of people on average, want to access a single major site. That site isn't selling ICBMs; they mostly want people to have access anyway. They have an imperfect rationing system based on IPs. The resource is cheap, the policy is simple, and the user needs to conceal a single attribute about herself. There's a simple mathematical solution that yields certificates which are already supported by existing software. That, my friend, is a problem we can solve. I suggest a proof of work system a la hashcash. You don't have to use that directly, just require the token request to be accompanied by a value whose sha1 hash starts with say 32 bits of zeros (and record those to avoid reuse). I like the idea of requiring combinations of scarce resources. It's definitely on the wishlist for future releases. Captchas could be integrated as well. 2. The token reuse detection in signcert.cgi is flawed. Leading zeros can be added to r which will cause it to miss the saved value in the database, while still producing the same rbinary value and so allowing a token to be reused arbitrarily many times. Thanks for pointing that out! Shouldn't be hard to fix. 3. signer.cgi attempts to test that the value being signed is 2^512. This test is ineffective because the client is blinding his values. He can get a signature on, say, the value 2, and you can't stop him. 4. Your token construction, sign(sha1(r)), is weak. sha1(r) is only 160 bits which could allow a smooth-value attack. This involves getting signatures on all the small primes up to some limit k, then looking for an r such that sha1(r) factors over those small primes (i.e. is k-smooth). For k = 2^14 this requires getting less than 2000 signatures on small primes, and then approximately one in 2^40 160-bit values will be smooth. With a few thousand more signatures the work value drops even lower. Oh, I think I see. The k-smooth sha1(r) values then become bonus tokens, so we use a large enough h() that the result is too hard to factor (or, I suppose we could make the client present properly PKCS padded preimages). I'll do some more reading, but I think that makes sense. Thanks! -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Guardian Observer (London) on Google Privacy Issues]
to console themselves with a story of the biter bit. Google's chief executive, Eric Schmidt, was reportedly enraged this month when an online newspaper published his address and other personal details - having found them on Google. - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: nym-0.2 released (fwd)]
- Forwarded message from cyphrpunk [EMAIL PROTECTED] - From: cyphrpunk [EMAIL PROTECTED] Date: Sat, 1 Oct 2005 15:27:32 -0700 To: Jason Holt [EMAIL PROTECTED] Cc: cryptography@metzdowd.com, [EMAIL PROTECTED] Subject: Re: nym-0.2 released (fwd) Reply-To: [EMAIL PROTECTED] On 9/30/05, Jason Holt [EMAIL PROTECTED] wrote: http://www.lunkwill.org/src/nym/ ... My proposal for using this to enable tor users to play at Wikipedia is as follows: 1. Install a token server on a public IP. The token server can optionally be provided Wikipedia's blocked-IP list and refuse to issue tokens to offending IPs. Tor users use their real IP to obtain a blinded token. 2. Install a CA as a hidden service. Tor users use their unblinded tokens to obtain a client certificate, which they install in their browser. 3. Install a wikipedia-gateway SSL web proxy (optionally also a hidden service) which checks client certs and communicates a client identifier to MediaWiki, which MediaWiki will use in place of the REMOTE_ADDR (client IP address) for connections from the proxy. When a user misbehaves, Wikipedia admins block the client identifier just as they would have blocked an offending IP address. All these degrees of indirection look good on paper but are problematic in practice. Each link in this chain has to trust all the others. Whether the token server issues tokens freely, or the CA issues certificates freely, or the gateway proxy creates client identifiers freely, any of these can destroy the security properties of the system. Hence it makes sense for all of them to be run by a single entity. There can of course be multiple independent such pseudonym services, each with its own policies. In particular it is not clear that the use of a CA and a client certificate buys you anything. Why not skip that step and allow the gateway proxy simply to use tokens as user identifiers? Misbehaving users get their tokens blacklisted. There are two problems with providing client identifiers to Wikipedia. The first is as discussed elsewhere, that making persistent pseudonyms such as client identifiers (rather than pure certifications of complaint-freeness) available to end services like Wikipedia hurts privacy and is vulnerable to future exposure due to the lack of forward secrecy. The second is that the necessary changes to the Wikipedia software are probably more extensive than they might sound. Wikipedia tags each (anonymous) edit with the IP address from which it came. This information is displayed on the history page and is used widely throughout the site. Changing Wikipedia to use some other kind of identifier is likely to have far-reaching ramifications. Unless you can provide this client idenfier as a sort of virtual IP (fits in 32 bits) which you don't mind being displayed everywhere on the site (see objection 1), it is going to be expensive to implement on the wiki side. The simpler solution is to have the gateway proxy not be a hidden service but to be a public service on the net which has its own exit IP addresses. It would be a sort of virtual ISP which helps anonymous users to gain the rights and privileges of the identified, including putting their reputations at risk if they misbehave. This solution works out of the box for Wikipedia and other wikis, for blog comments, and for any other HTTP service which is subject to abuse by anonymous users. I suggest that you adapt your software to this usage model, which is more general and probably easier to implement. CP - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: nym-0.2 released (fwd)]
- Forwarded message from Adam Langley [EMAIL PROTECTED] - From: Adam Langley [EMAIL PROTECTED] Date: Sun, 2 Oct 2005 03:21:41 +0100 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], cryptography@metzdowd.com Subject: Re: nym-0.2 released (fwd) Reply-To: [EMAIL PROTECTED] cyphrpunk: Each link in this chain has to trust all the others. ... any of these can destroy the security properties of the system. Dude, we're not launching missiles here, it's just Wikipedia. On 10/2/05, Jason Holt [EMAIL PROTECTED] wrote: The reason I have separate token and cert servers is that I want to end up with a client cert that can be used in unmodified browsers and servers. First, how do you add client certificates in modern browsers? Oh, actually I've just found it in Firefox, but what about IE/Opera/whatever else? Can you do it easily? The blinded signature is just a long bit string and it might well be better from a user's point of view for them to 'login' by pasting the base64 encoded blob into a box. Just a thought (motivated in no small part by my dislike for all things x509ish) privacy and is vulnerable to future exposure due to the lack of forward secrecy. The lack of forward secrecy is pretty fundamental in a reputation based system. The more you turn up the forward secrecy, the less effective any reputation system is going to be. And I'm also going to say well done to Jason for actually coding something. There do seem to be a lot couch-geeks on or-talk - just look at the S/N ratio on the recent wikipedia threads. It might not work, but it's *something*. No amount of talk is going to suddenly become a solution. AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: nym-0.2 released (fwd)]
is even correct. The simpler solution is to have the gateway proxy not be a hidden service but to be a public service on the net which has its own exit IP addresses. It would be a sort of virtual ISP which helps anonymous users to gain the rights and privileges of the identified, including putting their reputations at risk if they misbehave. This solution works out of the box for Wikipedia and other wikis, for blog comments, and for any other HTTP service which is subject to abuse by anonymous users. I suggest that you adapt your software to this usage model, which is more general and probably easier to implement. Sure. I always meant for the gateway to exit on a public IP address. The reason to make it a hidden service is to keep n00bs from forgetting to turn on tor when they talk to the proxy. Thanks for clarifying, though. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: nym-0.2 released (fwd)]
- Forwarded message from cyphrpunk [EMAIL PROTECTED] - From: cyphrpunk [EMAIL PROTECTED] Date: Sun, 2 Oct 2005 09:12:18 -0700 To: Jason Holt [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], cryptography@metzdowd.com Subject: Re: nym-0.2 released (fwd) Reply-To: [EMAIL PROTECTED] A few comments on the implementation details of http://www.lunkwill.org/src/nym/: 1. Limting token requests by IP doesn't work in today's internet. Most customers have dynamic IPs. Either they won't be able to get tokens, because someone else has already gotten one using their temporary IP, or they will be able to get multiple ones by rotating among available IPs. It may seem that IP filtering is expedient for demo purposes, but actually that is not true, as it prevents interested parties from trying out your server more than once, such as to do experimental hacking on the token-requesting code. I suggest a proof of work system a la hashcash. You don't have to use that directly, just require the token request to be accompanied by a value whose sha1 hash starts with say 32 bits of zeros (and record those to avoid reuse). 2. The token reuse detection in signcert.cgi is flawed. Leading zeros can be added to r which will cause it to miss the saved value in the database, while still producing the same rbinary value and so allowing a token to be reused arbitrarily many times. 3. signer.cgi attempts to test that the value being signed is 2^512. This test is ineffective because the client is blinding his values. He can get a signature on, say, the value 2, and you can't stop him. 4. Your token construction, sign(sha1(r)), is weak. sha1(r) is only 160 bits which could allow a smooth-value attack. This involves getting signatures on all the small primes up to some limit k, then looking for an r such that sha1(r) factors over those small primes (i.e. is k-smooth). For k = 2^14 this requires getting less than 2000 signatures on small primes, and then approximately one in 2^40 160-bit values will be smooth. With a few thousand more signatures the work value drops even lower. A simple solution is to do slightly more complex padding. For example, concatenate sha1(0||r) || sha1(1||r) || sha1(2||r) || ... until it is the size of the modulus. Such values will have essentially zero probability of being smooth and so the attack does not work. CP - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Why some Tor servers are slow (was Re: TOR Park Exit Node Question)]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Fri, 30 Sep 2005 18:46:01 -0400 To: [EMAIL PROTECTED] Subject: Why some Tor servers are slow (was Re: TOR Park Exit Node Question) User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] On Fri, Sep 30, 2005 at 02:04:46PM +0300, Giorgos Pallas wrote: What I mean is, is it normal for the Tonga server to claim over 4 MB of bandwidth ? If so, why are other servers that are on a 100 Mbit link not reporting more bandwidth ? Tonga is using dual AMD64's. Moria also uses those CPUs. They seem to be extremely fast at crypto (and everything else). Tonga also advertises port 80 and 443, so it's useful for people stuck behind fascist firewalls. Tonga also opened up its exit policy to attract more traffic. Servers that have lots of unused capacity, and are fast and have high uptime, and offer unusual ports like the default file-sharing ports, will bootstrap themselves by advertising a little bit, attracting more clients, and so on. (I'm not sure I actually like the fact that Tonga opened up its file sharing ports, since it puts more load on the rest of the network too, but I guess since we're still in development, a little bit of stress like this can be good for us.) While typing this it occurred to me that the default MaxAdvertisedBandwith is 2 MB and that Tonga has probably set it higher... Actually, the default MaxAdvertisedBandwidth is 128 TB. I believe you're thinking of BandwidthRate. Whis has also been a question of mine. Why my tor router handles a very low traffic volume (~30 KB in and out) while at the same time has 100% connectivity, 100Mbps of real bandwidth and stays up for more than a week (until it crashes due to memory ;-)... Could anyone help with that? It's frustrating wanting to share (bandwidth in our case) with the community but not being able to do so! There is something wrong with the masquerade Tor server. You can see it yourself (you may have to try from someplace other than masquerade's LAN, though) -- run telnet 155.207.113.227 9001 and hit enter about 10 times. Notice how it's really sluggish and takes a long time before it hangs up. Now run telnet 82.94.251.206 443 and do the same thing. Notice how it realizes the ssl handshake has failed after about 5 lines. This is how it's supposed to be. So masquerade is somehow not putting much attention into its ssl handshakes. This could be because its network connection is actually through a proxy or a firewall that is dropping some of the packets or slowing things down tremendously. It could also be that it's running on a 100 mhz 486, or its ulimits are set to something crazy-low, or it's busy ray-tracing a movie, or something else. I'd be curious to learn what's up with it. I've seen this behavior before on Windows machines behind cable modems and crappy NAT boxes. --Roger - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: nym-0.2 released]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Sat, 1 Oct 2005 02:18:43 + (UTC) To: [EMAIL PROTECTED] Subject: nym-0.2 released Reply-To: [EMAIL PROTECTED] nym-0.2 is now available at: http://www.lunkwill.org/src/nym/ My tor server is currently down, so I can't set up a public trial of this, but perhaps someone else will. This release makes the following improvements: * Tokens are now issued one-per-IP to clients via a token CGI script. Tokens are still blindly issued, so nobody (including the token issuer) can associate tokens with IP addresses. The list of already-served IPs could be periodically removed, allowing users to obtain new pseudonyms on a regular basis. (Abusers will then need to be re-blocked assuming they re-misbehave). * A token can be used to obtain a signature on a client certificate from a separate CA CGI script (potentially on a different machine). Tokens can only be spent to obtain one cert. Code to make a CA, client certs and have the certs signed is included. * The CA public key can be installed on a third web server (or proxy) to require that users have a valid client certificate. Servers can maintain a blacklist of misbehaving client certs. Misbehavers will then be unable to access the server until they obtain a new token and client cert (via a new IP). My proposal for using this to enable tor users to play at Wikipedia is as follows: 1. Install a token server on a public IP. The token server can optionally be provided Wikipedia's blocked-IP list and refuse to issue tokens to offending IPs. Tor users use their real IP to obtain a blinded token. 2. Install a CA as a hidden service. Tor users use their unblinded tokens to obtain a client certificate, which they install in their browser. 3. Install a wikipedia-gateway SSL web proxy (optionally also a hidden service) which checks client certs and communicates a client identifier to MediaWiki, which MediaWiki will use in place of the REMOTE_ADDR (client IP address) for connections from the proxy. When a user misbehaves, Wikipedia admins block the client identifier just as they would have blocked an offending IP address. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Wireless access for all? Google plan would offer free Internet throughout SF]
is with public money and publicly controlled internet access, said Vasquez. We take a lot of caution about how government should intervene in the market. URL: http://sfgate.com/cgi-bin/article.cgi?file=/c/a/2005/10/01/ GOOGLE.TMP Weblog at: http://weblog.warpspeed.com - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Pseudonymity for tor: nym-0.1 (fwd)]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 23:32:48 + (UTC) To: [EMAIL PROTECTED] Subject: Re: Pseudonymity for tor: nym-0.1 (fwd) Reply-To: [EMAIL PROTECTED] -- Forwarded message -- Date: Thu, 29 Sep 2005 23:32:24 + (UTC) From: Jason Holt [EMAIL PROTECTED] To: Ian G [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Subject: Re: Pseudonymity for tor: nym-0.1 (fwd) On Thu, 29 Sep 2005, Ian G wrote: Couple of points of clarification - you mean here CA as certificate authority? Normally I've seen Mint as the term of art for the center in a blinded token issuing system, and I'm wondering what the relationship here is ... is this something in the 1990 paper? Actually, it was just the closest paper at hand for what I was trying to do, which is nymous accounts, just as you say. So I probably shouldn't have referred to spending at all. My thinking is that if all Wikipedia is trying to do is enforce a low barrier of pseudonymity (where we can shut off access to persons, based on a rough assumption of scarce IPs or email addresses), a trivial blind signature system should be easy to implement. No certs, no roles, no CRLs, just a simple blindly issued token. And in fact it took me about 4 hours (while the conversation on or-talk has been going on for several days...) There are two problems with what I wrote. First, the original system is intended for cash instead of pseudonymity, and thus leaves the spender a disincentive to duplicate other serial numbers (since you'd just be accused of double spending); this is a problem since if an attacker sees you use your token, he can get the same token signed for himself and besmirch your nym. And second, it would be a pain to glue my scripts into an existing authentication system. Both problems are overcome if, instead of a random token, the client blinds the hash of an X.509 client cert. Then the returned signature gives you a complete client cert you can plug into your web browser (and which web servers can easily demand). Of course, you can put anything you want in the cert, since the servers know that my CA only certifies 1 bit of data about users (namely, that they only get one cert per scarce resource). But the public key (and verification mechanisms built in to TLS) keeps abusers from being able to pretend they're other users, since they won't have the users' private keys. rant The frustrating part about this is the same reason why I'm getting out of the credential research business. People have solved this problem before (although I didn't know of any Free solutions; ADDS and SOX are hard to google -- are they Free?). I even came up with at least a proof of concept in an afternoon. And yet the argument on the list went on and on, /without even an acknowledgement of my solution/. Everybody just kept debating the definitions of anonymity and identity, and accusing each other of anarchy and tyranny. We go round and round when we talk about authentication systems, but never get off the merry-go-round. Contrast that with Debevec's work at Berkeley; Ph.D in 1996 on virtual cinematography, then The Matrix comes out in 1999 using his techniques and revolutionizes action movies. Sure, graphics is easier because it doesn't require everyone to agree on an /infrastructure/, but then, neither does the tor/wikipedia problem. I'm grateful for guys like Roger Dingledine and Phil Zimmerman who actually make a difference with a privacy system, but they seem to be the exception, rather than the rule. /rant So thanks for at least taking notice. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Abuse resistant anonymous publishing - Proposed solution to the Wikipedia issue.]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] - From: Jimmy Wales [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 18:26:48 -0400 To: [EMAIL PROTECTED] Subject: Re: Abuse resistant anonymous publishing - Proposed solution to the Wikipedia issue. User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Reply-To: [EMAIL PROTECTED] Ben Burch wrote: The biggest problem I see is that if moderation is commissive, rather than reactive, then if the original poster commits a crime (like violating the Official Secrets Act) then the moderator who approves the posting would likely be liable for the same crime. Well, at least with respect to Wikipedia there are a few misconceptions I should clear up. First, something like that wouldn't be appropriate for Wikipedia on editorial grounds. (No original research) -- we have specific intellectual standards that would generally preclude that sort of thing. Second, 'moderation' at wikipedia is reactive. That is, people vandalize, and then we clean it up. The only solution I can think of that would allow Tor and Wiki to interoperate would be to have a Tor-Wikipedia Moderation Team who would actively look for Wikipedia vandalism originating from Tor exit nodes, and revert out vandal's postings promptly. The support we would need from Wikipedia would be minor; Wiki would have to implement a Watch function for postings from Tor exit nodes that the Tor-Wikipedia moderation team would get email notifications on. There already are exit node listings that would allow Wikipedia to create and refresh this list on a regular basis, and obviously they can already do that as they have implemented a block. Wikipedia would have to agree that the Tor-Wikipedia Moderation Team would have the right to revert ANY change from a Tor exit node without discussion. Once the vandals realize that they won't have any fun using Tor to vandalize Wikipedia, the job of the TWMT would get quite easy, as I don't imagine there would be more than a few dozen real edits on any given day from the Tor cloud. Or am I barking up the wrong tree here? Well, it seems unlikely that we could recruit enough people to do this effectively. We already have a huge number of people monitoring the site, people who are (mostly) sympathetic to Tor's aims, but they get tired of it. --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]
- Forwarded message from cyphrpunk [EMAIL PROTECTED] - From: cyphrpunk [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 16:44:37 -0700 To: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]] Reply-To: [EMAIL PROTECTED] One of the problems with the idea of a pseudonym service distinguishing between good and 'bad users is that it has no way on its own of telling the difference. The service manages pseudonyms, which are intended to be used out on the web in some way. But the service can't tell if people are playing nicely or not. The only way this could happen is if the service receives *complaints*. This is the only feedback mechanism possible. I gather that Tor does in fact send out complaints about people who misbehave. Perhaps blog services do so as well. One problem is that these complaints generally don't arrive in real time. It takes time for a human being to notice that some vandalism has occured and register a complaint. If the pseudonym service is going to be able to respond, it has to know which pseudonym was active at the time the bad actions occured. Jimmy Wales very accurately describes the problem with pseudonyms at the web-server level. If Wikipedia or blog comments require the use of pseudonyms, these can be linked after the fact. I am very sensitive to this problem myself. The implied solution is that the pseudonym service would maintain the pseudonyms, but would not reveal them to the web service. Rather, it would only provide a certificate that the pseudonym is currently in good standing, i.e. it has not received (too many) complaints. This implies that the pseudonym service must maintain a record of recently used pseudonyms, and have some way of mapping them to what the web services (which issue the complaints, services like Wikipedia) would have seen. This mapping might be by IP address, or if Wikipedia and other services are willing to do more, it could perhaps be an opaque identifier which the pseudonym service provided at the time the web service (Wikipedia) asked whether this pseudonym was a good guy or not. As a specific example, the pseudonym service might have replied, to a query from Wikipedia, Yes, this user is a good guy, and the sequence number of this reply is #1493002. Then later if abuse occured, Wikipedia (or the blog service, or other victim of vandalism) comes back and said we had a problem with the user who was certified with sequence number #1493002. The pseudonym server would map this back to the pseudonym in use at that time, and invalidate the pseudonym (or at least give it a bad mark, with enough such marks killing the nym). The main problems with this solution are first, it requires considerable manual work on the part of the pseudonym server, similar to the work necessary at an ISP to resolve complaints about users. It could be a full time job. And second, it requires custom software at Wikipedia and other web services that might be willing to work to implement such a solution. The second problem could be alleviated by the use of a related service, a web proxy that is only for good pseudonyms. The web proxy would provide transparent pass-through similar to anonymizer.com, but only for users who were able to provide the kind of certification described above, from the pseudonym server. In this way, the outgoing IP addresses belonging to the web proxy would be good from the POV of Wikipedia and other web services. Those services could continue to use IP blocking as one of their main tools for handling misuse, treating the web proxy service as being like an ISP. The web proxy service could be bundled with the pseudonym service, or they could exist independently. CP - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]
- Forwarded message from Nick Mathewson [EMAIL PROTECTED] -
From: Nick Mathewson [EMAIL PROTECTED]
Date: Thu, 29 Sep 2005 00:38:01 -0400
To: [EMAIL PROTECTED]
Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]
User-Agent: Mutt/1.4.2.1i
Reply-To: [EMAIL PROTECTED]
Hi again, Jimmy!
On Wed, Sep 28, 2005 at 06:57:37AM -0400, Jimmy Wales wrote:
[...]
I said no such thing. Tor servers exist for the sole purpose of aiding
people who have a genuine need for privacy. Tor operators by and large
are unhappy that Tor users can't edit Wikipedia, and are genuinely
interested in exploring solutions, especially solutions which involve
changes or enhancements to the Tor architecture which help solve the
problem not just for Wikipedia but for _all_ internet services which
desire to carefully balance a desire for privacy and openness against abuse.
I think I've identified one of the reasons some people here are disturbed
about your suggestions. When you talk about changing the Tor
architecture, they think you mean changes to Tor that would require
all users to have pseudonyms, or ostracize the users who didn't. When
you say Tor should do X, they think you mean the Tor software
should do X.{1}
If that were what you meant, they would be right to be concerned.
Pseudonymity is wrong for many users. Complicating the core Tor
implementation would be bad.
But these aren't your goals, if I understand correctly. Wikipedia
doesn't ultimately care how Tor is implemented, or what it contains,
so long as it is significantly less effective as a tool for Wikipedia
abuse. Yes?
This could be achieved, as some people fear, through modifying the
core of Tor. But that isn't the only way to change matters. As
discussed, introducing a separate pseudonymous authentication service
(perhaps even an anonymous credential service, if we can find a way to
do this without patent infringement) would serve just as well, and
require no modifications to the Tor code. Users who didn't want to
use such a service would be no worse off than they are today. Users
who wanted to use Tor and edit Wikipedia at the same time could decide
whether the implications of such a service were acceptable to them.
{1} To be clear, I think that it's more accurate to talk about changes
to the User/Tor/Wikipedia interaction, and to suggest a need for
action by the Tor project and its supporters, than to talk about a
need for changes in Tor's architecture, and a need for action by
Tor.
yrs,
--
Nick Mathewson
- End forwarded message -
--
Eugen* Leitl a href=http://leitl.org;leitl/a
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature
[EMAIL PROTECTED]: Pseudonymity for tor: nym-0.1 (fwd)]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 01:51:32 + (UTC) To: cryptography@metzdowd.com Subject: Pseudonymity for tor: nym-0.1 (fwd) -- Forwarded message -- Date: Thu, 29 Sep 2005 01:49:26 + (UTC) From: Jason Holt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Pseudonymity for tor: nym-0.1 Per the recent discussion regarding tor and wikipedia, I've hacked together an implementation of the basic system from Chaum, Fiat and Naor's 1990 Untraceable Electronic Cash paper. This system allows CAs to blindly issue tokens (or coins) which can then be spent elsewhere. It runs in perl, and comprises a CA, nym-maker, client application and auth checker (for the server). The tarball is here: http://www.lunkwill.org/src/nym/ Of course, it's useless at the moment since it gives out tokens indiscriminately (and probably has massive bugs), but if anyone actually cares about this idea, it will be (more or less) easy to do the following: * Put up a sample CA and server that people can use (potentially as hidden services). * Make the CA issue only one token per email address, or one token per IP address, one per computational puzzle, one for every $20 mailed in... * Automatically expire CA keys and generate new ones on a regular basis (rather than bothering with CRLs) * Instead of randomly generated tokens, have the CA sign an actual X.509 cert request, which will then become a perfectly valid X.509 cert useful as a client-side cert in unmodified browsers and web servers * Create some sort of aid for maintaining server-side (or CA) blacklists of improperly behaving users * Check to see if the protocol is actually still secure and properly implemented. Comments welcome. -J - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]
- Forwarded message from David Benfell [EMAIL PROTECTED] -
From: David Benfell [EMAIL PROTECTED]
Date: Thu, 29 Sep 2005 02:59:44 -0700
To: [EMAIL PROTECTED]
Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]
User-Agent: Mutt/1.5.7i
Reply-To: [EMAIL PROTECTED]
On Thu, 29 Sep 2005 00:17:07 -0400, Nick Mathewson wrote:
I assume that you're not just ignoring everybody else and replying
only to what Jimmy says, right? There have been other posts here
explaining why pseudonymity and Tor are not at odds, so long as
pseudonymity is user selected.
Pseudonyms are a separate problem from Tor. As someone posted, Tor
does not prevent people from using pseudonyms. If pseudonyms will
solve Wikipedia's problem, then fine; a good portion of this argument
has been about Wikipedia's need for authentication. See my comments
following your footnote.
Wikipedia has user accounts and IP-based blocking. That's a kind of
authentication. Wikipedia does not require you to use a user account
to edit pages, and does not do much to ensure that user accounts
belong to real people. That's a lack of authentication.
Now why couldn't *he* say that? The man's involved with an
encyclopedia project; he should be able to write.
The way this particular aspect of our disagreement arose is that I
accused him of wanting Tor to do his authentication for him. He
claimed that Wikipedia does do its own authentication. Now you
explain that Wikipedia does not *require* authentication. Which
undermines the usefulness of offering authentication.
It's like how Tor blocks some highly-abusable services, like SMTP on
port 25, but doesn't do content filtering to try to hunt for abusive
behavior on exiting streams. We filter out some abuse, but we can't
filter out all abuse without turning off the network. An anti-Tor
rhetorician could say, You filter abuse, but you don't filter abuse!
But what would that prove?
You are attempting to compare Tor's security policy to Wikipedia's
security policy.
Tor has a security policy. Tor's security policy is to protect
originating IP addresses which might be connected to persons. We
hope, in combination with Privoxy, it protects anonymity
reasonably well. On the reasonable (I think) premise that other
sites are primarily responsible for their own security, it only
limits some abuse.
Now, what is Wikipedia's security policy? With no authentication
requirement, and a policy that allows anyone to edit (unless they're
connecting from a blacklisted IP address), I might as well ask, What
is truth?
{1} This case is more commonly known, in the literature, as
pseudonymous communication than anonymous communication. Then
again, if you're going to invoke dictionaries in a technical
discussion, anonymity becomes a very broad term.
But Tor is about anonymity. Not about pseudonymity. Not about other
forms of authentication. As it should be.
From a communication perspective, anonymity has a very specific
meaning. It means we cannot identify a person. Note that the failure
to identify a person makes no reference to kind of identification.
There need be no preference for real life names versus pseudonyms
versus IP addresses versus whatever else you can think of. Anything
that identifies a person contradicts the concept that this person is
anonymous.
This has practical implications. For instance, as someone pointed
out, when the Chinese police raid a dissident's apartment, and search
his hard drive, they are able to tie the pseudonym to a real life
identity. If the police can also connect the pseudonym to what they
consider crime, the distinction between a pseudonym and a real
life name loses much of its value; hopefully, the pseudonym permitted
the dissident to continue his activities for longer.
Now, I will certainly agree, as someone else pointed out, that Tor
should permit the use of pseudonyms or other forms of authentication.
But the fact remains that any identification--as implied by
authentication--contradicts anonymity; it is therefore something which
Tor should not involve itself with.
Simply put, it is not and cannot be Tor's problem.
--
David Benfell, LCP
[EMAIL PROTECTED]
---
Resume available at http://www.parts-unknown.org/
- End forwarded message -
--
Eugen* Leitl a href=http://leitl.org;leitl/a
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature
[EMAIL PROTECTED]: Pseudonymity for tor: nym-0.1]
- Forwarded message from Jason Holt [EMAIL PROTECTED] - From: Jason Holt [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 01:49:26 + (UTC) To: [EMAIL PROTECTED] Subject: Pseudonymity for tor: nym-0.1 Reply-To: [EMAIL PROTECTED] Per the recent discussion regarding tor and wikipedia, I've hacked together an implementation of the basic system from Chaum, Fiat and Naor's 1990 Untraceable Electronic Cash paper. This system allows CAs to blindly issue tokens (or coins) which can then be spent elsewhere. It runs in perl, and comprises a CA, nym-maker, client application and auth checker (for the server). The tarball is here: http://www.lunkwill.org/src/nym/ Of course, it's useless at the moment since it gives out tokens indiscriminately (and probably has massive bugs), but if anyone actually cares about this idea, it will be (more or less) easy to do the following: * Put up a sample CA and server that people can use (potentially as hidden services). * Make the CA issue only one token per email address, or one token per IP address, one per computational puzzle, one for every $20 mailed in... * Automatically expire CA keys and generate new ones on a regular basis (rather than bothering with CRLs) * Instead of randomly generated tokens, have the CA sign an actual X.509 cert request, which will then become a perfectly valid X.509 cert useful as a client-side cert in unmodified browsers and web servers * Create some sort of aid for maintaining server-side (or CA) blacklists of improperly behaving users * Check to see if the protocol is actually still secure and properly implemented. Comments welcome. -J - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] - From: Jimmy Wales [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 07:29:24 -0400 To: [EMAIL PROTECTED] Subject: Re: Hello directly from Jimbo at Wikipedia User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Reply-To: [EMAIL PROTECTED] Steven J. Murdoch wrote: What needs to be done is to give Wikipedia a way to tell the difference between legitimate Tor users and abusers. The basis for my proposal is that abusers can currently get IP addresses quite easily, through open proxies, zombie machines or simply rebooting their ADSL modem, as well as through Tor. To mitigate abuse from Tor, the cost of committing abuse through Tor needs to be just higher than the cost of an abuser getting another IP address. This is not very high. I do not use Tor, and so at risk of offending those who already think that I hate Tor, I will say that it has been said to me by some people that we're lucky that Tor is horribly slow, or lots of people would use it, making the problem much worse. :-) Whether this will work depends on the type of abuse that Wikipedia receives, and Jimbo is much more qualified to comment on this then me. The typical problem case, and I asked around for horror stories to confirm my impression, is that some lunatic first starts writing at Wikipedia in an incoherent, biased, offensive, etc. way. The community at first tries to work with them, because it does take a while to absorb our peaceful ways if you're used to Usenet or mailing list debates. But eventually, the worst offenders end up getting blocked. Then they go ballistic. Imagining themselves to be el1t3 h4xx0rs, they write (or find online somewhere) vandalbots and start using them to replace pages with fuck you or goatse images or... well, there seems to be no shortage of creativity in the world of the deranged and snubbed. We don't sweat this too much. We just block them and rever the changes. The problem is much worse for small wiki sites than it is for Wikipedia because we're fully staffed by hundreds of smart people 24 hours a day. The people on the frontlines tell me this isn't such a huge problem, because we do things to limit the abuse. One of the things we currently do is block Tor. I consider that a reasonable solution to the vandalism problem, but an unfortunate thing, since to my mind, Tor is something very good. It would be nice if we could look at the edits coming from Tor and say Oh, these are fine, they are mostly responsible edits. It'd even be ok if we could look at the edits coming from Tor and say Ok, so there's a touch more vandalism from these than from other ip pools, but there's also some good stuff coming through from places where we normally don't see a lot of editing activity. We'll put up with it. As it is now, we look at it and say oh, jesus. --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] -
From: Jimmy Wales [EMAIL PROTECTED]
Date: Thu, 29 Sep 2005 07:40:41 -0400
To: [EMAIL PROTECTED]
Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
Reply-To: [EMAIL PROTECTED]
Nick Mathewson wrote:
But these aren't your goals, if I understand correctly. Wikipedia
doesn't ultimately care how Tor is implemented, or what it contains,
so long as it is significantly less effective as a tool for Wikipedia
abuse. Yes?
That's right. I'm not an expert in Tor-ish matters, and so despite my
strident manner at times, I am very happy to learn more and understand
why some initial suggestion I might have has already been considered and
rejected with good cause.
And as an ongoing gesture of goodwill, let me explain _why_ I want Tor
to be significantly less effective as a tool for Wikipedia abuse. It
isn't because Tor is a threat to our work. One of the nice things about
how Tor is implemented is that we can easily get a list of the exit
servers and block them. Problem solved.
No, the reason I am interested in exploring possibilities for reducing
the abuse is not to protect wikipedia, but to make it possible for Tor's
goals to be achieved more effectively.
{1} To be clear, I think that it's more accurate to talk about changes
to the User/Tor/Wikipedia interaction, and to suggest a need for
action by the Tor project and its supporters, than to talk about a
need for changes in Tor's architecture, and a need for action by
Tor.
Yes. The one thing I should caution against, though, is assuming that
the right solution to the problem should involve anything complicated on
the part of Wikipedia. We're willing to do whatever, but I'm also
interested in how this problem can be solved more generally. In this
way, tor servers can be allowed to post anonymously and in a hit-and-run
fashion to blogs, for example.
--Jimbo
- End forwarded message -
--
Eugen* Leitl a href=http://leitl.org;leitl/a
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] - From: Jimmy Wales [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 07:49:34 -0400 To: [EMAIL PROTECTED] Cc: Nick Mathewson [EMAIL PROTECTED] Subject: Re: Hello directly from Jimbo at Wikipedia User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Reply-To: [EMAIL PROTECTED] Jeffrey F. Bloss wrote: I was operating under the assumption that the problem was more along the lines of nefarious juveniles selectively posting Kilroy was here graffiti. Something along those lines. If I'm out in left field about the nature of the attack against Wikipedia, I'd be happy to be corrected, and forced to agree that HashCash would be unsuitable. I have no opinion about HashCash just yet. I have to think about it some more. The nefarious juveniles problem is partly what it is, yes. But that sort of random vandalism goes on all the time, and isn't particularly problematic. What is problematic is the lunatic on crack and steriods who is selectively posting Kilroy sucked your mothers cock graffiti, obsessively, hundreds of times. Our admins find it much more peaceful to just block open proxies and Tor servers than to deal with that for hours on end, days on end, weeks on end. I am not an expert on ideas like HashCah or anything of the sort. I am a bit of an expert on the behavior of problem users at Wikipedia. :-) And what I can say is that problem users at Wikipedia are problem users everywhere for the most part. Ordinary sane people don't go on a spree of Wikipedia vandalism. So the _degree_ of trust we need is actually quite small. It isn't We certify this person to be a certain user, guaranteed, the same as ever. It's just this packet is being sent to you from a source that has somehow tended generally to lead us to believe to some small extent that the person posting it has not been a jackass, by and large. Or, as has been brilliantly discussed here already, it could be this packet has been sent to you via a mechanism that one might bother to use, were one a dissident really needing anonymity, but sufficiently bothersome that were one simply a lunatic on crack, one would more likely have simply switched to using anonymous proxies. It won't be perfect, but as an empirical matter, it's probably good enough. --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
Sorry for the flood, but this is winding down already. What I didn't like about this discussion is that all concerned parties seem to have been shouting into space past each other, just trying to make a noise instead of understanding and solving the problem. - Forwarded message from Steven J. Murdoch [EMAIL PROTECTED] - From: Steven J. Murdoch [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 00:27:51 +0100 To: [EMAIL PROTECTED] Cc: Jimmy Wales [EMAIL PROTECTED] Subject: Re: Hello directly from Jimbo at Wikipedia User-Agent: Mutt/1.4.1i Reply-To: [EMAIL PROTECTED] On Tue, Sep 27, 2005 at 05:48:59PM -0400, Jimmy Wales wrote: All I'm saying is that Tor could segregate users easily enough into two clouds: We sorta trust these ones, more or less, a little bit, but no guarantees -- We don't trust these ones, we don't know them. This would be very difficult to do using the existing Tor design as it doesn't know anything about users or sessions. It lives at the TCP layer and all it does is shift packets from one IP address to another, giving some privacy to both ends. Adding higher layer functionality to Tor increases the chance that it will do neither job well, so here is a proposal which I think does what you want, but avoids this problem. The goal is to increase the cost for a Tor user to commit abuse on Wikipedia. It doesn't need to be full-proof, but just enough to make them go elsewhere. Wikipedia could require Tor users to log in before making edits, and ban accounts if they do something bad. However the cost of creating new accounts is not very high. The goal of this proposal is to impose a cost on creating accounts which can be used though Tor. Non-Tor access works as normal and the cost can be small, just enough to reduce the incentive of abuse. Suppose Wikipedia allowed Tor users to only read articles and create accounts, but not able to change anything. The Tor user then goes to a different website, call it the puzzle server. Here the Tor user does some work, perhaps does a hashcash computation[1] or solves a CAPTCHA[2], then enters the solution along with their new Wikipedia username. The puzzle server (which may be run by Wikipedia or Tor volunteers), records the fact that someone has solved a puzzle along with the username entered. The puzzle server doesn't need the Wikipedia password as there is no reason for someone to do work for another person's account. Now when that Tor user logs into their Wikipedia account to edit something, the Wikipedia server asks the puzzle server whether this account has ever solved a puzzle. If it has, the user can make the edit, if not then the user is told to go to the puzzle server first. This check can be very simple - just an HTTP request to the puzzle server specifying the Wikipedia username, which returns yes vs no, or 200 vs 403. For performance reasons this can be cached locally. There is no cryptography here, and I don't think it is needed, but it can be added without much difficulty. If the Tor user starts committing abuse, his account is cancelled. The puzzle server doesn't need to be told about this, as Wikipedia will not let that user make any edits. The reason this approach avoids the usual problems with proof-of-work schemes[3] is that good Tor users only have to solve the puzzle once, just after they create the account. Bad Tor users will need to solve another puzzle every time they are caught and had their account cancelled. So my question to Jimbo is: what type of puzzle do you think would be enough to reduce abuse through Tor to a manageable level? The difficulty of the puzzle can be tuned over time but what would be necessary for Wikipedia to try this out? Hope this helps, Steven Murdoch. [1] http://www.hashcash.org/ [2] http://www.captcha.net/ [3] Proof-of-Work Proves Not to Work by Ben Laurie and Richard Clayton: http://www.cl.cam.ac.uk/users/rnc1/proofwork.pdf -- w: http://www.cl.cam.ac.uk/users/sjm217/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from Paul Syverson [EMAIL PROTECTED] -
From: Paul Syverson [EMAIL PROTECTED]
Date: Thu, 29 Sep 2005 09:56:19 -0400
To: [EMAIL PROTECTED]
Subject: Re: Hello directly from Jimbo at Wikipedia
User-Agent: Mutt/1.4.1i
Reply-To: [EMAIL PROTECTED]
Some points of clarification that I hope will help:
(1) On anonymity and authentication/pseudonymity/etc.
All versions of Onion Routing, including Tor, were designed to separate
identification from routing. The slogan way that I have put this for
the last five or six years is:
Onion Routing is about anonymizing the communication pipe, not what
goes through it.
The devil's always in the details, but as one-line summaries go, I
think that sums it up pretty well.{1}
(2) On various pseudonym authentication or anonym
authentication{2}, etc. approaches to solving the problem at hand.
Some of this is ultimately necessary for various applications,
especially once the Internet looks as Geoff described it. (In fact I
think it's one precondition to realizing anything like that vision.)
But I'm dubious about any of those proposed to date here providing
enough friction to identifier acquisition to deter abusers but not
honest users in this context. They may be worth trying. Roger's
suggestion about the temporary IP blocks and Steven's about the
separate puzzle servers come to mind, probably some others I'm
forgetting just now. But as Roger says, somebody's gotta code them
up---and probably much more work---deploy them, maintain them, and
evaluate their effectiveness, all on the Tor-Wikipedia frontier. I
suspect that the abuser who goes postal as Jimmy described is willing
to waste lots of time acquiring IDs, but perhaps stereotypes about
attention span are close enough to true for some of the proposals to
be effective. I had my own proposal that doesn't rely on any of this,
and that could be implemented and deployed in a few days (OK after
spending at least a few months or so thinking about the design, the
engineering, and the implications.) In the spirit of mutt: All these
ideas suck; I just think that one sucks a little less.
-
{1} Some further specifics for (1)
Anonymity and identification/authentication can be entirely
compatible. By this I mean that one can be anonymous (to everyone) as
far as one identifier goes but authenticated (to a specific protocol
principal) wrt another as part of the same communication. This has
been an intentional part of the design of every Onion Routing system
including Tor. It contrasts with systems like Crowds, which was
directed at distinct but related security properties, thus they made
anonymity of the circuit inherently depend on the anonymity of the
data passing over it. As a specific example of using Tor for
authenticated communication over anonymous circuits, when travelling I
often need to log back into NRL to check mail and do other things. I
do this via ssh over Tor. That way the local hotel staff, ISP staff,
any other network observers don't see me logging in to NRL. But I can
assure you that I want to make sure I am going to NRL and no place
else and that I want to make sure only I, and no one else, succeeds in
accessing my account. (And Jimbo, in my experience, it has been
realtime enough to be editing in vi or emacs with no noticeable
trouble over this line. I can't say that someone who expects permanent
T1 rate downloading is going to be happy with Tor, but you should check it
out and see the performance for yourself over a few days, rather than
relying on the reports you've heard.)
I also discussed this in my testimony to the National Academy of
Engineering panel that did a study of authentication and privacy
several years ago. (Cf. _Who Goes There? Authentication Through the
Lens of Privacy_ from the National Academies Press.)
As many have noted, Tor has enough of a job trying to do one thing
well. Trying to do more things will just mean it does that thing less
well or later. But that does not preclude designing to be compatible
with other things, e.g., privoxy to somewhat sanitize, i.e., anonymize
web traffic over Tor, or connect to enable authenticated communication
via ssh over Tor. (There's a program named `connect' in case you had
trouble parsing that.) The discussion now is how to make Tor and
Wikipedia compatible, the interface as Nick put it.
{2} Yes you can authenticate someone who is anonymous from you.
Besides various group signature approaches, cf., e.g., my papers on
UST (Unlinkable Serial Transactions), or look at the proposal for
common terminology (new version recently out) at
http://dud.inf.tu-dresden.de/Anon_Terminology.shtml
What we called an `anonym' in the UST work and elsewhere they call a
`transaction pseudonym'.
-
- End forwarded message -
--
Eugen* Leitl a href=http://leitl.org;leitl
[EMAIL PROTECTED]: [IP] eDonkey to close]
Now we will see how good the anonymizing networks are, and how long it will take until they will become a target. I'm surprised it has taken them so long. I'd expect this would have happened at least 5 years ago. - Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 18:33:21 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] eDonkey to close X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: dep21 [EMAIL PROTECTED] Date: September 28, 2005 6:12:43 PM EDT To: [EMAIL PROTECTED] Subject: for ip: eDonkey to close http://www.extremedrm.com/article/eDonkey+Chief+Blasts+Litigators+In+Senate+Testimony/161190_1.aspx EDonkey (MetaMachine) are to 'exit the business' of peer to peer after a cease and desist letter from the RIAA a few weeks ago. They simply couldn't afford the protracted litigation needed to prove their case in a court. david - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Abuse resistant anonymous publishing]
to take responsibility. In any case the final user is no certain as we will see... Wait a sec, a bad user can connect other abusive users easily!? Yes as soon as an abuse user connects to the intro graph they can introduce as many of their friends as they like! This is the reason why filtering policies need to make use of the full path from the Root to the user that ultimately takes responsibility: a user that consistently introduces many other abusers will always be on the path, and can be used to filter stuff out! As a side effect of this one cannot (and should not) trust that the user that finally took responsibility is indeed the initiator of the abusive action. They could be a Sybil or another person up the chain that disagrees with the fact that this action constitutes abuse! Why are you calling it 'taking responsibility' instead of tracing? The point of the protocol is for someone to say 'I stand by this action' -- his path to the root can then be used for filtering such action out, by users that do consider it as abuse. Note that there is always contention in online communities about what constitutes abuse and this mechanism allows for differing opinions. Then there can be different policies filtering out different users in the chain. Possibly anyone (not just people on the Path between Root and Charlie) should be able to take responsibility and have the item tagged with their path. What about abusing the anti-abuse system? There is a risk that trolls will abuse the action of requesting tracing/taking responsibility for all actions, trying to get as much information as possible/wasting time/undermining confidence in the system. The conditions under which this mechanism is initiated is really not clear, (Root decides, voting, veto, ...). In any case it is a good idea for someone to take responsibility of the initiation of this process by tagging the request with their path to the Root. This way Root, Alice and Bob can filter out persistent abusers of the anti-abuse system :-). There is no contradiction there: anonymous political speech is a right (hence this complex system), but moderation (censorship?) has to be done transparently, and those doing it must come forward by tagging their action with their path to Root. It seems that Root has a lot of power in all this (== your system embodies fascist values!)? Yes, this is a problem. At the same time there is nothing stopping (aside from efficiency and the appropriate crypto-fu) full decentralization. Each person can be their own Root, and apply custom filtering according to the paths relative to them. Note that taking responsibility cannot be abused any more than before (since either you connect directly to the abuser, at which point you should know better, or you are still connected through nodes that will not consider your action abusive and will take responsibility for it!). Ok, so how do we do all this magic? It is clear that a trusted third party can do all this efficiently. Can we find a variant of certificate systems that allow delegation in an anonymous way to decentralize all this, and make sure that no one party can screw any other? Open research problem -- I am working on it! Any feedback is welcome! George - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [FoRK] [EMAIL PROTECTED]: Ripple currency development begins]]
- Forwarded message from Mark Baker [EMAIL PROTECTED] - From: Mark Baker [EMAIL PROTECTED] Date: Thu, 29 Sep 2005 10:31:33 -0400 To: fork@xent.com Subject: [FoRK] [EMAIL PROTECTED]: Ripple currency development begins] User-Agent: Mutt/1.5.6+20040907i A very munchkin-esque project. It appears to need a bootstrap though; the last thing I need is another social network to maintain. - Forwarded message from Ryan Fugger [EMAIL PROTECTED] - From: Ryan Fugger [EMAIL PROTECTED] Subject: Ripple currency development begins Date: Thu, 29 Sep 2005 02:15:42 -0700 Reply-To: Ryan Fugger [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bork.markbaker.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.5 tests=BAYES_00,MISSING_HEADERS, RCVD_BY_IP autolearn=ham version=3.0.4 This email is going out to all who have expressed interest in the Ripple decentralized currency project (http://ripple.sf.net/). I hope you are all doing well. Since I got bogged down trying to define a protocol for communication between hosts in a Ripple peer network, it seemed like a good idea to go back and start with a simpler single-host prototype. The other developer on the project is two-thirds done the initial coding in Python using the Django framework. We will be developing the initial single-host version of Ripple as proprietary software -- we don't want to allow multiple Ripple hosts that can't talk to each other. The fully decentralized multi-host protocol and software, if and when it is necessary, would be appropriately free and open. Our goal in either case is to build and administer a commercially viable Ripple payment service. Anyone wishing to put some energy (or money) into the project for a share of the venture, please let me know. Thanks for all your help, Ryan - End forwarded message - -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com ___ FoRK mailing list http://xent.com/mailman/listinfo/fork - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] - From: Jimmy Wales [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 19:50:52 -0400 To: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]] User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Reply-To: [EMAIL PROTECTED] Eugen Leitl wrote: Wikipedia already needs this sort of thing because of AOL IPs -- they have similar characteristics to Tor, in that a single IP produces lots of behavior, some good some bad. So Wikipedia understands that the transport layer isn't to blame, yet they persist in asking for changes in the Tor transport to address the problem of malicious users? *groan* Actually, the transport layer *is* to blame. I don't know how much more clear I can be about it. Because Tor users are almost universally bad, because almost no good edits come out of the Tor network, we block them. Why is it that Tor users are so bad? The main reason is that the anonymity provides them with cover. AOL users are sort of bad, but not universally bad. Why is that? It is in part because of the way their transport layer is designed. That's not the perception they need to change. They need to realize that if an avenue for action without responsibility exists, someone will use it. We *do* realize that. That's exactly what I'm talking about. Tor provides an avenue for action without responsibility, and people do use it. Wikis get defaced all the time *without* AOL or Tor, because the philosophy allows anyone to edit. It is that philosophy that is in error, not the transport layers used by the vandals. If what you're saying is I think it is fine for Wikipedia to block Tor, then you really aren't contributing productively to this conversation. There are some facts we know: we can usefully reduce the amount of anonymous grief we get by blocking Tor exit servers. So, this is what we are currently doing. I consider this unfortunate, but there you go. We are not looking for a perfect solution. Yes, Wikis will be vandalized. We're prepared to deal with that, we do deal with that. But what I am seeking is some efforts to think usefully about how to helpfully reconcile our dual goals of openness and privacy. I don't say privacy is wrong, so Tor should change their philosophy. I make no apologies for simply ignoring you if you say that openness is wrong, so Wikipedia should change their philosophy. Roger gets it. The Wikipedians don't. What is it that we don't get? This thread started off because a Tor server complained to me about the blocking, and part of my response is that one beef I have is that some people in the Tor community seem very happy to simply stick their heads in the sand and pretend that Wikipedians don't get it. That's not helpful. --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from cypherpunk [EMAIL PROTECTED] - From: cypherpunk [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 17:25:07 -0700 To: [EMAIL PROTECTED] Subject: Re: Hello directly from Jimbo at Wikipedia Reply-To: [EMAIL PROTECTED] As an occasional Tor and Wikipedia user, let me add a couple of points. First, in case it is not obvious, the problem with the present system is that Tor users can no longer edit on Wikipedia. I have done so in the past, in what I like to think is a constructive manner, but cannot do so since this summer. I have valid although perhaps unpopular contributions to make, and not only is my freedom to express myself limited, the quality of the material on Wikipedia suffers due to the absence of my perspective. The status quo is not acceptable and we should work to find a solution. Looking at the proposals for authentication servers and such, I see a major issue which is not being addressed. That is, how does the web server distinguish authenticated Tor users from unathenticated ones? If this is via a complicated protocol, there is no point as the servers won't use it. The hard truth is this: the distinction must be done on the basis of IP address. That is, there must be a separate set of Tor exit nodes which are only for authenticated users. This does not necessarily mean building complex authentication protocols into the Tor network, and having two classes of traffic flowing around. It could be that this authenticated Tor is a separate network. It only lets users in who are authenticated, and owns a specific set of IP addresses which servers can whitelist. The regular Tor exit nodes can be blacklisted as they are now. The technical problem is then, how to achieve as much anonymity as possible in the authenticated network, while still providing the abuse prevention services which Wikipedia and other servers will require in order to whitelist the nodes. What does Wikipedia need? What is the minimum level of service they require? Presumably, it is similar to what they can get via ISPs, who also map many users to a fixed set of IP addresses. Wikipedia can complain to the ISP, and it will get back in some form to that user. Of course, Wikipedia does not know the details of how their complaint is handled. Is the user kicked off, banned temporarily, or merely given a stern warning? What matters to them is that, generally, users that they complain about don't keep coming back. Their complaints are effective, at least much or most of the time. This is the level of response which an authenticated Tor network would have to provide. The problem with this functionality from Tor's perspective is that unlike an ISP, Tor does not have knowledge of the mapping from users to IP addresses. Given a complaint that a certain IP was misused at a certain time, Tor has no information about which user to penalize. To solve the problem we would need to use some cryptographic mechanism. Let authenticated users gain credentials via some expensive, slow process. Let them embed the credentials in their messages such that they are revealed in some blinded form to the exit node. Let the exit nodes remember the credentials which were used at different times. When valid complaints arrive, let the exit nodes blacklist the credential which was in use at that time. This stops the abuser. There could be many such authenticated-Tor subnetworks. Each could have its own credential servers, its own abuse policies, and its own set of exit IP addresses. They would be like anonymous ISPs, from the POV of web server operators like Wikipedia. Those which are effectively able to suppress abuse will avoid blacklists and their users will be able to successfully use web based services. CP - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
. That's a sad fact to me. It's a difficult thing for those of us who are serious about these issues. But the really sad thing is when elements of the Tor community are not willing to face up to this as a legitimate and difficult problem. everyone is so worried about it, but has any one ever been successfully been able to use tor to effectively spam anyone? Yes, of course! We deal with it constantly. We have an effective means of dealing with it: we block Tor servers from editing wikipedia. But is that what any of us want? Misbehaviour is in the eye of the observer, however. No, actually it isn't. There is such a thing as objectively identifiable malicious behavior. We aren't Chinese censors here. We're the good guys. We want to work with you. Yes, we could implement tight security to only allow people who identify themselves (perhaps we'll require a credit card number, someone suggests?)... but *cough*, aren't we supposed to care about privacy here? --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from Nick Mathewson [EMAIL PROTECTED] -
From: Nick Mathewson [EMAIL PROTECTED]
Date: Wed, 28 Sep 2005 05:03:30 -0400
To: [EMAIL PROTECTED]
Subject: Re: Hello directly from Jimbo at Wikipedia
User-Agent: Mutt/1.4.2.1i
Reply-To: [EMAIL PROTECTED]
On Wed, Sep 28, 2005 at 02:45:35AM -0400, Jeffrey F. Bloss wrote:
[...]
Has anyone considered applying a HashCash type solution to this?
Hashcash is often considered, but commonly dismissed, because it
limits identities based on the wrong resource: computers.
If you haven't read the paper 'Proof-of-work' Proves Not To Work by
Ben Laurie and Richard Clayton, I recommend it highly. See
http://www.cl.cam.ac.uk/users/rnc1/proofwork.pdf . It mostly
discusses why hashcash can't prevent spam, but the arguments would
seem to apply to wikipedia editing as well.
[...]
On the other hand, if there were an authentication service that gave
you pseudonyms for Tor users who wanted pseudonyms, you could tell
which pseudonyms contributed well, and which were jerks, and which
were nonentities.
The problem I see with this is that as the name implies, it's
pseudo-anonymous.
Sorry, but you've stumbled a personal crusade of mine.
The word is pseudonymous, not pseudo-anonymous. And the difference is
importatant. Pseudonymous means using false names, like calling
yourself Batman instead of Bruce Wayne. Anonymous means without a
name, like writing The Joker will pay for his crimes and not
signing it. Pseudo-anonymous isn't a real word, but if it were, it
would mean falsely anonymous, like the bank robber who disguised
himself by wearing a motorcycle helmet with his name written on the
back.{1}
Tor is an anonymous network by design. And there is a
difference.
As one of the designers, I'd like to weigh in. Tor provides
anonymity, but we've never opposed people who wanted to use an
anonymous system to bootstrap per-service or cross-service
pseudonymity.
We will never, of course, alter Tor to make people have pseudonyms.
But letting using pseudonyms is not against our overarching goals.
The overarching goals are privacy and usability.{2}
It's real time nature also compounds any additional partitioning
problems a hard-keyed pseudonym setup brings with it.
I don't see any iterable (that is, awful) partitioning attacks here.
Assume a network where some users have pseudonyms and some don't.
Assume that pseudonyms are first obtained through a blinded{3}
process, so that an attacker can't tell which user has which
pseudonym.
Assume that the attacker is watching all authentication services
(since this is probably the best point for these attacks). The
attacker could tell when users create new pseudonyms, and when
pseudonymous users are active. From this info, the attacker could
rule out some users as possible owners of some pseudonyms, but that's
about it. Correlation and intersection attacks are unlikely to work
unless the attacker is watching the user as well as the auth server,
and that's outside our threat model.
Although, this too might fall under that good enough umbrella as
long as the tor network were disjoined from the nym creation and key
distribution process as much as possible. The nyms would have to be
managed outside a tor egress point to maintain user's anonymity.
Right.
I also question whether or not a system can be devised that makes
nym creation expensive enough to thwart nefarious users from simply
collection a lot of nyms. :(
Right. I suspect that this is one of those social engineering
problems that we won't solve except by trying things out and seeing
whether they work.
{1} There are all other kinds of great terms in the field. For
example, allonymous is using a name belonging to someone else,
like if the Joker writes a letter and signs it Batman. Oddly,
there is no classical term for using one's given name.
{2} If you care about privacy and not usability, I recommend DC nets.
If you care about usability and not privacy, I recommend turning
Tor off.
{3} Again see http://en.wikipedia.org/wiki/Blind_signature
yrs,
--
Nick Mathewson
- End forwarded message -
--
Eugen* Leitl a href=http://leitl.org;leitl/a
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature
[EMAIL PROTECTED]: [Geowanking] Google Earth Exposes the Indian Military]
- Forwarded message from Shekhar Krishnan [EMAIL PROTECTED] - From: Shekhar Krishnan [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 12:17:23 +0100 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], fsf-friends@mm.gnu.org.in, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: [Geowanking] Google Earth Exposes the Indian Military Organization: CRIT (Collective Research Initiatives Trust) X-Mailer: Evolution 2.4.0 Reply-To: [EMAIL PROTECTED] Dear All: :: apologies for cross-posting :: This has caused quite an uproar in Mumbai, and the consequences will be interesting to follow. To read more about open geo-data and free mapping initiatives in India, see the Mumbai Free Map ( http://www.crit.org.in/projects/gis | http://freemap.crit.org.in | http://www.freemap.in ). Please also visit and sign the open geo-data manifesto hosted by the Open Knowledge Foundation ( http://okfn.org/geo/manifesto.php ) and visit Mapping Hacks ( http://www.mappinghacks.com ). Best, Shekhar _ Google Earth exposes IAF bases CHARLES ASSISI TIMES NEWS NETWORK[ TUESDAY, SEPTEMBER 27, 2005 12:16:08 AM ] http://timesofindia.indiatimes.com/articleshow/1243460.cms MUMBAI: Legally, you aren???t supposed to come within arm???s length of India???s military bases. Whether it is the naval dockyards in Mumbai or the air force bases in New Delhi, Bangalore and Hyderabad, they continue to be strictly out of bounds for unauthorised personnel. But technology, unerringly, finds ways to subvert the law. A little over two weeks ago, Google released fresh satellite images of New Delhi, south Mumbai, Bangalore and Hyderabad as part of its new initiative, Google Earth ( http://earth.google.com ). These images, available to anybody with access to the Net, provide users with images of earth from space. Punch New Delhi and the software first zooms in on Rashtrapati Bhavan. After having taken a look at its lawns, take in a detailed perspective of Parliament building. Maybe, fly over the Prime Minister???s residence. And if that doesn???t satiates the voyeur in you, move over to Palam Airport where IAF planes are based. The level of detail even reveals the camouflage used to mask hangars. Pictures of Mumbai reveal with numbing clarity the docks where INS Viraat is berthed. Users can zoom close enough to take a reasonably good look at the deck of India???s lone aircraft carrier. Browse around and you can stroll past piers where warships of all kinds and submarines are docked. Pan across to take a long look at what lies beyond the fortified gates of Navy Nagar where access is normally controlled by gun-wielding guards. And if that isn???t enough, there are shots of a carrier under construction, which sources speculate, could be the top secret advanced technology vessel (ATV). It???s much the same thing with Bangalore. The air force base at Yelahanka with the jets and helicopters parked are available for all to view. And if it???s the HAL factory you???re interested in, zoom right in. -- __ Shekhar Krishnan 9, Supriya, 2nd Floor 709, Parsee Colony Road no.4 Dadar, Mumbai 400014 India http://www.crit.org.in/members/shekhar http://web.mit.edu/~shekhar/www ___ Geowanking mailing list [EMAIL PROTECTED] http://lists.burri.to/mailman/listinfo/geowanking - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from Adam Langley [EMAIL PROTECTED] - From: Adam Langley [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 14:25:15 +0100 To: [EMAIL PROTECTED] Subject: Re: Hello directly from Jimbo at Wikipedia Reply-To: [EMAIL PROTECTED] On 9/28/05, Nick Mathewson [EMAIL PROTECTED] wrote: Hashcash is often considered, but commonly dismissed, because it limits identities based on the wrong resource: computers. A similar scheme would be to make people perform many CAPTCHAs[1] in order to generate a login id. That way the resource is human time and it's difficult to generate lots of them [1]. Abuse from these accounts results in the account being deleted, which makes it costly. (More detail here: http://www.imperialviolet.org/page26.html#e509) The design of the CAPTCHA is actually far more difficult than I imagined because it turns out that the range of ability of people for solving them is very large - but there are several widly used CAPTCHAs which seems to be good for many of people. (Very unscientifically, it seems that computer minded people can solve them but other's have great problems. My mother can't even do the Google CAPTCHA). Although this seems possible it's tough to believe that it's worth doing for Wikipedia because I've already written a small (1500 line) patch for MediaWiki; the design of which was okayed in general by one of the developers. It was intended to make it easier to block and unblock IP ranges (like all Tor nodes) . The patch certainly wasn't perfect but, despite the efforts of several people, I never got any responce from anyone in MediaWiki about it. I don't mind - I've the attention span of a flea anyway. But it's not good for people who might be willing to do this work. AGL [1] http://en.wikipedia.org/wiki/Captcha [2] You could setup a sweatshop to do it, or you could distribute it and make setup a porn website which requires you to solve them to gain entry. Either way - it's quite a lot of effort. See http://www.boingboing.net/2004/01/27/solving_and_creating.html -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]]]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] - From: Jimmy Wales [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 09:27:12 -0400 To: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Reply-To: [EMAIL PROTECTED] Eugen Leitl wrote: What is it that we don't get? That Tor is working as designed, and that the problem with bad actors using its cloak is a problem with the actors themselves. Finally, we note that exit abuse must not be dismissed as a peripheral issue: when a system's public image suffers, it can reduce the number and diversity of that system's users, and thereby reduce the anonymity of the system itself. I'm pleased to report that the original design documents rightly agree with me that the it is in the interest of the longterm success of the Tor project that an attitude of throwing up our hands in defeat is not enough. Those people are not sticking their heads in the sand. They're correctly noting that nothing is broken except the bad actors. That *is* sticking their heads in the sand. Yes, we can lay moral blame on the bad actors. That's fine. Let's all stop typing for a minute or two and just _hate_ them for it. Ok, now we all feel better. :-) But now we're back to the question: how can Tor be improved to deal with this very serious and important problem? What are the steps that might be taken, however imperfect, to reduce the amount of abuse coming from Tor nodes? --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: [Geowanking] Google Earth Exposes the Indian Military]
- Forwarded message from Sonny Parafina [EMAIL PROTECTED] - From: Sonny Parafina [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 09:33:03 -0400 To: [EMAIL PROTECTED] Subject: Re: [Geowanking] Google Earth Exposes the Indian Military User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) Reply-To: [EMAIL PROTECTED] Its funny when the tables are turned. Long before Google Maps or Earth was released, was Cryptome's Eyeball series, which used internet mapping and photos mined from internet sources to raise awareness about different places. For exampe here's a recent Eye-Ball report: http://cryptome.org/nonas-eyeball.htm The best one was when Cryptome published the address, maps, aerial photos to convicted/pardoned felon Admiral John Pointdexter who promoted the Total Information Awareness program in the wake of the 9/11 attacks. sonny Allan Doyle wrote: See also this article in the Register http://www.theregister.co.uk/2005/09/13/ google_earth_threatens_democracy/ and the quote about India on the first page: India agrees. Reuters quotes an anonymous security official there as confirming that the issue of satellite imagery had been discussed at the highest level but the government had concluded that 'technology cannot be stopped'. We are aware that there are websites which give detailed pictures of buildings like the president's house including every tree in the compound. Our security agencies are aware of this but how can we stop technology? he added. At the end of the last page, there are links to other articles they have been running about Google Earth. Very interesting stuff. Allan On Sep 28, 2005, at 07:17, Shekhar Krishnan wrote: Dear All: :: apologies for cross-posting :: This has caused quite an uproar in Mumbai, and the consequences will be interesting to follow. To read more about open geo-data and free mapping initiatives in India, see the Mumbai Free Map ( http://www.crit.org.in/projects/gis | http://freemap.crit.org.in | http://www.freemap.in ). Please also visit and sign the open geo-data manifesto hosted by the Open Knowledge Foundation ( http://okfn.org/geo/manifesto.php ) and visit Mapping Hacks ( http://www.mappinghacks.com ). Best, Shekhar _ Google Earth exposes IAF bases CHARLES ASSISI TIMES NEWS NETWORK[ TUESDAY, SEPTEMBER 27, 2005 12:16:08 AM ] http://timesofindia.indiatimes.com/articleshow/1243460.cms MUMBAI: Legally, you aren?t supposed to come within arm?s length of India?s military bases. Whether it is the naval dockyards in Mumbai or the air force bases in New Delhi, Bangalore and Hyderabad, they continue to be strictly out of bounds for unauthorised personnel. But technology, unerringly, finds ways to subvert the law. A little over two weeks ago, Google released fresh satellite images of New Delhi, south Mumbai, Bangalore and Hyderabad as part of its new initiative, Google Earth ( http://earth.google.com ). These images, available to anybody with access to the Net, provide users with images of earth from space. Punch New Delhi and the software first zooms in on Rashtrapati Bhavan. After having taken a look at its lawns, take in a detailed perspective of Parliament building. Maybe, fly over the Prime Minister?s residence. And if that doesn?t satiates the voyeur in you, move over to Palam Airport where IAF planes are based. The level of detail even reveals the camouflage used to mask hangars. Pictures of Mumbai reveal with numbing clarity the docks where INS Viraat is berthed. Users can zoom close enough to take a reasonably good look at the deck of India?s lone aircraft carrier. Browse around and you can stroll past piers where warships of all kinds and submarines are docked. Pan across to take a long look at what lies beyond the fortified gates of Navy Nagar where access is normally controlled by gun-wielding guards. And if that isn?t enough, there are shots of a carrier under construction, which sources speculate, could be the top secret advanced technology vessel (ATV). It?s much the same thing with Bangalore. The air force base at Yelahanka with the jets and helicopters parked are available for all to view. And if it?s the HAL factory you?re interested in, zoom right in. -- __ Shekhar Krishnan 9, Supriya, 2nd Floor 709, Parsee Colony Road no.4 Dadar, Mumbai 400014 India http://www.crit.org.in/members/shekhar http://web.mit.edu/~shekhar/www ___ Geowanking mailing list [EMAIL PROTECTED] http://lists.burri.to/mailman/listinfo/geowanking ___ Geowanking mailing list [EMAIL PROTECTED] http://lists.burri.to/mailman/listinfo/geowanking - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor]]]]]
- Forwarded message from Geoffrey Goodell [EMAIL PROTECTED] - From: Geoffrey Goodell [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 09:55:41 -0400 To: [EMAIL PROTECTED] Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia Tor User-Agent: Mutt/1.5.6+20040907i Reply-To: [EMAIL PROTECTED] On Wed, Sep 28, 2005 at 09:27:12AM -0400, Jimmy Wales wrote: But now we're back to the question: how can Tor be improved to deal with this very serious and important problem? What are the steps that might be taken, however imperfect, to reduce the amount of abuse coming from Tor nodes? I think that we can agree that there are short-term and long-term solutions to this problem. In the short-term, we can block Tor nodes by routing address and develop special mechanisms to allow Tor users to edit Wikipedia content anyway. We can do this either via some sort of indirection or via some sort of special change to Wikipedia itself, working around the limitations in Mediawiki. We can focus on the short-term for now. However, I think that most proponents of Tor believe that in the long-term, Wikipedia should support location-independent users. So we need a plan going forward, and this plan should be sufficiently general to apply to any location-independent users, not just users of Tor. I think that many of us hope that some day the Internet will be flat and routing information will be useless in tracking identity or reputation. This will be difficult to achieve, but it is certainly my hope. As such, I am loath to encourage the design of systems that require any form of access control at the network layer, and I believe that the right thing to do is avoid such temptation, even if software tools like Mediawiki appear to be designed with network-layer access control in mind. Geoff - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Wikipedia Tor]
- Forwarded message from Jimmy Wales [EMAIL PROTECTED] - From: Jimmy Wales [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 11:00:58 -0400 To: [EMAIL PROTECTED] Cc: Paul Syverson [EMAIL PROTECTED] Subject: Re: Wikipedia Tor User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) Reply-To: [EMAIL PROTECTED] Paul Syverson wrote: I want to emphasize a central aspect of my suggestion: The goal is not just to provide a filter for abusive posts, it's to change incentives. This is exactly the right approach! We can't know for sure without running the experiment, but my guess is that if abusive posts through Tor never succeed (OK perhaps virtually never), and if the process of posting through Tor informs posters of that fact, then Tor will become worth it for your admins. The abusers will disappear or greatly diminish because they will know from being warned, and if necessary from experience, that their attempts will fail. Posts through Tor will then mostly have value (in the sense of not being abusive in the ways that prompted this discussion.) I would say that even some fairly slight changes to the incentive structure may help a lot. The less desirable Tor is for problem users, the more they will shift to traditional broken open proxies. We can play whack-a-mole with these as we do now, while at the same time leaving Tor more open. Yes, I know (and I'm sure Jimmy knows) that this won't solve the longterm underlying issues. Abusive posters will just move on to another avenue than Tor. But I think it will be a quick, cheap, and big win for both Tor and Wikipedia. Yes, but I don't really mind them moving to other avenues. That's the point. If I didn't love Tor, I wouldn't care about blocking Tor either. Let them abuse broken proxy servers, let them do whatever, that's fine, we can deal with it. We just want to open up to Tor. Yes, as Marc Abel suggested you could implement passwords, pseudonyms, or hell ZKPs. But this is stepping onto the slippery slope of trying to solve the more longterm problem that using IP addresses in the way Wikipedia does is a temporarily useful kludge. (Kludges are great, but function creep is dangerous and can make for bigger problems in the long run.) Let me see if I can explain a bit more of the math behind this. I'm just going to make up a hypothetical example. Suppose 100 out of every 1,000,000 edits to Wikipedia is malicious. And suppose we study them and discover, hmm, 25 of them come from Tor, which is easily blockable. 50 of them come from static ips or dynamic ips that are expensive for users to get new. 25 of them are from broken proxies. Now, our present solution is to block Tor, do various things in other situations, and this works reasonably well. Of the 25 bad edits we block from Tor, some portion of them surely shift to other means, but not all of them. So we find it to be a net win. Except. Except we don't really like to block Tor. Now, fast forward, and imagine that the expensive ip situation goes away in a few years, either due to widespread onion routing, or whatever you may want to dream up that makes our temporary kludge of using ips no longer functional. Then we'll still only have 100 out of every 1,000,000 edits to Wikipedia as being malicious. How we'll deal with that is how we'll deal with that, but that's fine. We'll manage. For now the key thing to do is to shift the incentives on the bad users so that Tor is less desirable for them than playing with the broken proxies or just doing whatever with a dialup account or aol addresses or whatever. --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Hello directly from Jimbo at Wikipedia]
- Forwarded message from Marc Abel [EMAIL PROTECTED] - From: Marc Abel [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 12:17:40 -0400 To: [EMAIL PROTECTED] Subject: Re: Hello directly from Jimbo at Wikipedia X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Reply-To: [EMAIL PROTECTED] Hi Jimbo, My concern about pseudonyms is that they can compromised after-the-fact. Suppose Li Li is over in China writing blogs, and she selects Muzimei as her pseudonym and implements it with any of several digital signature schemes. Then she writes a bunch of blog entries, and possibly a few edits to her Wikipedia page. Wikipedia trusts her because of her reputation, and presumably no one knows her real name is Li Li. Except there's an eyewitness to one of her blogs, or the authorities raid her Linux box and her private key is compromised. Li Li has a serious problem, because all of her previous activity is signed by her Muzimei pseudonym, so after 36 hours of interrogation she confesses, is found guilty of separatism in an 18 minute trial, and executed 20 days later. I still lean in favor of approaches which protect Wikipedia on the basis of actual content submitted, instead of information about the submitter. This is why Paul Syverson and I are advancing these types of proposals. Once again, one way to check content (until machines can think better) is to have not-necessarily-anonymous parties with interests in specific subjects ok what would otherwise be anonymous posts prior to the posts showing up. This system would be only as efficient as these approving personnel for anonymous posts, but these people can be mutually selected in the sense that an anonymous editor can nominate anyone, and Wikipedia may refuse anyone. It's a little like any meeting held under Robert's Rules of Order. To discuss anything, someone must present a motion and someone else needs to second it. If the content's not pertinent enough for even a second, there really no need for the group to consider it. In the mechanism I am suggestion (as an intermediate-term approach to try), the mover may be anonymous if the seconder is willing not to be. Marc On Wed, 2005-09-28 at 08:36, Jimmy Wales wrote: Marc Abel wrote: This has law enforcement implications; if you can prove that Alice took the cookie from the cookie jar, perhaps using eyewitnesses, you can now show that Alice did many other unreputable things. Can you explain this in more detail? --Jimbo - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [p2p-hackers] [Fwd: [Planetlab-users] Announcing: TCP NAT Traversal/Hole-Punching Library]]
- Forwarded message from Michael Parker [EMAIL PROTECTED] - From: Michael Parker [EMAIL PROTECTED] Date: Wed, 28 Sep 2005 12:39:43 -0700 To: [EMAIL PROTECTED] Subject: [p2p-hackers] [Fwd: [Planetlab-users] Announcing: TCP NAT Traversal/Hole-Punching Library] User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] I just got this by way of the PlanetLab mailing list... Definitely thought it would be of interest! - Mike Original Message Subject: [Planetlab-users] Announcing: TCP NAT Traversal/Hole-Punching Library From:Saikat Guha [EMAIL PROTECTED] Date:Wed, September 28, 2005 3:46 am -- Hi all, (apologies if you get multiple copies of this) I am pleased to announce the availability of our open-source TCP NAT Traversal/Hole-Punching library based on our research published in [1]. [1] Characterization and Measurement of TCP Traversal through NATs and Firewalls, S. Guha and P. Francis. IMC 2005. http://nutss.net/pub/imc05-tcpnat.pdf The key result of the paper is: TCP NAT traversal can work 85%-90% of the time today (without any special assumptions about NATs), and 100% of the time between pairs of certain popular, well-behaved NATs. See [1] for more details. An open-source Java library for TCP NAT Traversal is now available: webpage: http://nutss.net/stunt.php faq: http://nutss.net/jstunt-faq.php library and example: http://nutss.net/jstunt-examples.php The above library has been tested for pair-wise connectivity across 11 brands of NATs from Windows and Linux hosts. NATs tested were Linksys, DLink, Netgear, Belkin, 3Com, Netopia, Allied Telesyn, SMC, Trendnet, USR, Buffalo Tech. Out of the 121 possible pair-wise combinations, 113 connections are successful. The only ones that failed are when both the endpoints are behind the _same_ NAT device that does not support TCP hairpin-behavior yet (see [1]). The java library is released under LGPL; contact me if this does not meet your needs. Feel free to extend it/port it etc. Q: I am a P2P developer/researcher. How does this help me? A: The library adds TCP NAT traversal out-of-the-box. This increases the connectivity in your P2P network since two users behind their NATs can now exchange data without having to go through an intermediary node. You can: - Use this library as is (for development of P2P software, research, small deployments, etc in java) - Study it to provide TCP NAT Traversal in your existing P2P applications in your language of choice. - etc. If you have any questions, comments, suggestions, or problems, do not hesitate to contact me. Cheers, -- Saikat ___ Users mailing list: [EMAIL PROTECTED] https://lists.planet-lab.org/mailman/listinfo/users - End forwarded message - ___ Gnucla-devel mailing list [EMAIL PROTECTED] http://starsky.ee.ucla.edu/cgi-bin/mailman/listinfo/gnucla-devel ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
/. [How Chinese Evade Government's Web Controls]
Link: http://slashdot.org/article.pl?sid=05/09/27/1235203 Posted by: CmdrTaco, on 2005-09-27 13:37:00 [1]Carl Bialik from the WSJ writes China is moving to 'centralize all China-based Web news and opinion under a state regulator,' the Wall Street Journal reports, but determined citizens have found a way out of previous restrictions in what has become a cat-and-mouse game: '[2]Many Chinese Internet users, dismissing what they call government scare tactics, find ways around censorship. The government requires users of cybercafs to register with their state-issued ID cards on each visit, but some users avoid cybercaf registration by paying off owners. In response, the government has installed video cameras in some cafs and shut others. ... While certain words such as democracy are banned in online chat rooms, China's Web users sometimes transmit sensitive information as images, or simply speak in code, inserting special characters such as underscoring into typing.' Also noteworthy is that major portals seem to be cooperating with authorities' restrictions: 'Insiders who work for the big portal sites say they are already in regular contact with authorities about forbidden topics, such as the outlawed Falun Gong religious group, which their teams of Web editors pull off bulletin boards.' References 1. mailto:[EMAIL PROTECTED] 2. http://online.wsj.com/public/article/0,,SB112777213097452525-zRQZ3S8IZkZDPMZNay0R6RUfXOw_20060926,00.html?mod=blogs - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Wikipedia Tor]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 15:54:38 -0400 To: [EMAIL PROTECTED] Subject: Re: Wikipedia Tor User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] On Tue, Sep 27, 2005 at 11:18:31AM -0400, Paul Syverson wrote: On Tue, Sep 27, 2005 at 10:27:58AM -0400, Matt Thorne wrote: everyone is so worried about it, but has any one ever been successfully been able to use tor to effectively spam anyone? No. Cf. http://tor.eff.org/faq-abuse.html#WhatAboutSpammers To be fair, this answer is yes. People have used Tor to deface Wikipedia pages, along with Slashdot pages, certain IRC networks, and so on. I think that counts as spam at least in a broad sense. A potential for cooperation is the proposal below for authenticated access to Wikipedia through Tor. I will not speak to any particular design here, but if Wikipedia has a notion of clients trusted to post to Wikipedia, it should be possible to work with them to have an authentication server that controls access to Wikipedia through Tor. As I understand it, Jimmy is hoping that we will develop and maintain this notion. We would run both halves of the Tor network, and when they complain about a user, we would cut that user out of the authenticated side. Jimmy and I talked about Tor-and-Wikipedia many months ago, and the conclusion was that they (mediawiki) would be willing to try a variety of technological solutions to see if they work (i.e. cut down on vandalism and aren't too much of a burden to run). My favorite is to simply have certain address classes where the block expires after 15 minutes or so. Brandon Wiley proposed a similar idea but where the block timeout is exponentially longer for repeated abuse, so services that are frequently blocked will stay blocked longer. This is great. But somebody needs to actually code it. Wikipedia already needs this sort of thing because of AOL IPs -- they have similar characteristics to Tor, in that a single IP produces lots of behavior, some good some bad. The two differences as I understand them are that AOL will cancel user accounts if you complain loudly enough (but there's constant tension here because in plenty of cases AOL decides not to cancel the account, so Wikipedia has to deal some other way like temporarily blocking the IP), and that it's not clear enough to the Wikipedia operators that there *are* good Tor users. (One might argue that it's hard for Wikipedia to change their perception and learn about any good Tor uses, firstly because good users will blend in and nobody will notice, and secondly because they've prevented them all from editing so there are no data points either way.) So I've been content to wait and watch things progress. Perhaps we will find a volunteer who wants to help hack the mediawiki codebase to be more authentication-friendly (or have more powerful blocking config options). Perhaps we'll find a volunteer to help build the blind-signature pseudonymous authenticated identity management infrastructure that Nick refers to. Perhaps the Wikimedia operators will increasingly get a sense that Tor has something to offer besides vandalism. (I presume this thread re-surfaced because Tor users and operators are periodically telling Wikipedia that they don't like being blocked.) Maybe we will come to the point eventually that it makes sense to do something different than blocking the Tor IP addresses from editing Wikipedia. (Which, we should all remember compared the Gentoo forum situation, is a great step above blocking them from both reading and writing.) It could be that we never reach that point. Certain services on the Internet (like some IRC networks) that are really prone to abuse are probably doing the right thing by blocking all Tor users (and all AOL users, and all open proxies, and ...). And we want to keep Tor easy to block, or we're really going to start getting the other communities angry at us. In summary, I'm not too unhappy with the status quo for now. Tor needs way more basic development / usability work still. In the absence of actual volunteers-who-code on the side of Tor _or_ Wikipedia to resolve the problem, I'm going to focus on continuing to make Tor better, so down the road maybe we'll be able to see better answers. --Roger - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: RE: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization]
- Forwarded message from Nick Lothian [EMAIL PROTECTED] - From: Nick Lothian [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 11:05:31 +0930 To: Peer-to-peer development. [EMAIL PROTECTED] Subject: RE: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization Reply-To: Peer-to-peer development. [EMAIL PROTECTED] p2p-hackers, meet rest-discuss. rest-discuss, I'd like to introduce you to p2p-hackers. RESTafarians: there is a long-running conversation on p2p-hackers about friendnets, also known as darknets, small world networks, and F2F networks; also capabilities security, sometimes known as smart contracts. An example thread begins at http://zgp.org/pipermail/p2p-hackers/2005-August/002915.html p2p-hackers: Tyler Close' method for HTTP access control using nothing but unguessable (and secret) URIs came up on REST-discuss. That thread begins at http://groups.yahoo.com/group/rest-discuss/message/5228 In the context of friendnets, Tyler's scheme is a beautifully simple way of controlling access using nothing but low-tech means. Not only does it limit access to trusted parties, it also allows for transitive relationships. (Warning: his scheme is counterintuitive, since the dependence on secret URLs smells like security through obscurity). Interesting idea. It may not be security via obscurity, but it does appear to ignore a number of practical considerations. For instance, what about the secret URL being passed on in referrer headers to other pages? I think some browsers block it when you go from a secure page to a non-secure page on another site (although I'm unsure about that). The argument that users shouldn't put links to on a secured page is more surprising than the things it is trying to avoid (to me anyway). OTOH, all browsers block HTTP authenticaion credentials from being passed in the referrer header. Nick ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Wikipedia Tor]
- Forwarded message from Arrakis Tor [EMAIL PROTECTED] - From: Arrakis Tor [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 07:48:22 -0500 To: [EMAIL PROTECTED] Subject: Wikipedia Tor Reply-To: [EMAIL PROTECTED] This is a conversation with Jimmy Wales regarding how we can get Wikipedia to let Tor get through. Anyone with a port 80 can vandalize your website. Yes, but we notice that we can control a significant amount of vandalism by blocking ip numbers which have proven to be particularly problematic. TOR servers are among the absolute worst. And TOR operators don't seem to care. We go to the trouble to block all the file sharing clients, and often abused ports and protocols like IRC. Many of us typically block ports which do not have any legitimate reason for being used. If all it take is a port 80 to vandalize the wikipedia, of which port 80 is a public service, then there is no point in discriminating against Tor users since every IP is an equal opportunity offender. Equal *opportunity*, but we have very strong empirical evidence here. TOR ip numbers are the worst offenders that we have seen. People use TOR specifically to hide their identity, specifically to vandalize wikipedia. You say that tor is quite irresponsibly managed. How would you propose we manage tor servers differently? Ban users who vandalize wikipedia. That'd be a start. Rate limit edits at Wikipedia, that'd be good. Write an extension to your software which would help us to distinguish between trusted and newbie Tor clients. I completely fail to comprehend why Tor server operators consistently refuse to take responsibility for their crazed users. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
/. [How Chinese Evade Government's Web Controls]
Link: http://slashdot.org/article.pl?sid=05/09/27/1235203 Posted by: CmdrTaco, on 2005-09-27 13:37:00 [1]Carl Bialik from the WSJ writes China is moving to 'centralize all China-based Web news and opinion under a state regulator,' the Wall Street Journal reports, but determined citizens have found a way out of previous restrictions in what has become a cat-and-mouse game: '[2]Many Chinese Internet users, dismissing what they call government scare tactics, find ways around censorship. The government requires users of cybercafs to register with their state-issued ID cards on each visit, but some users avoid cybercaf registration by paying off owners. In response, the government has installed video cameras in some cafs and shut others. ... While certain words such as democracy are banned in online chat rooms, China's Web users sometimes transmit sensitive information as images, or simply speak in code, inserting special characters such as underscoring into typing.' Also noteworthy is that major portals seem to be cooperating with authorities' restrictions: 'Insiders who work for the big portal sites say they are already in regular contact with authorities about forbidden topics, such as the outlawed Falun Gong religious group, which their teams of Web editors pull off bulletin boards.' References 1. mailto:[EMAIL PROTECTED] 2. http://online.wsj.com/public/article/0,,SB112777213097452525-zRQZ3S8IZkZDPMZNay0R6RUfXOw_20060926,00.html?mod=blogs - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Re: Wikipedia Tor]
- Forwarded message from Roger Dingledine [EMAIL PROTECTED] - From: Roger Dingledine [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 15:54:38 -0400 To: [EMAIL PROTECTED] Subject: Re: Wikipedia Tor User-Agent: Mutt/1.5.9i Reply-To: [EMAIL PROTECTED] On Tue, Sep 27, 2005 at 11:18:31AM -0400, Paul Syverson wrote: On Tue, Sep 27, 2005 at 10:27:58AM -0400, Matt Thorne wrote: everyone is so worried about it, but has any one ever been successfully been able to use tor to effectively spam anyone? No. Cf. http://tor.eff.org/faq-abuse.html#WhatAboutSpammers To be fair, this answer is yes. People have used Tor to deface Wikipedia pages, along with Slashdot pages, certain IRC networks, and so on. I think that counts as spam at least in a broad sense. A potential for cooperation is the proposal below for authenticated access to Wikipedia through Tor. I will not speak to any particular design here, but if Wikipedia has a notion of clients trusted to post to Wikipedia, it should be possible to work with them to have an authentication server that controls access to Wikipedia through Tor. As I understand it, Jimmy is hoping that we will develop and maintain this notion. We would run both halves of the Tor network, and when they complain about a user, we would cut that user out of the authenticated side. Jimmy and I talked about Tor-and-Wikipedia many months ago, and the conclusion was that they (mediawiki) would be willing to try a variety of technological solutions to see if they work (i.e. cut down on vandalism and aren't too much of a burden to run). My favorite is to simply have certain address classes where the block expires after 15 minutes or so. Brandon Wiley proposed a similar idea but where the block timeout is exponentially longer for repeated abuse, so services that are frequently blocked will stay blocked longer. This is great. But somebody needs to actually code it. Wikipedia already needs this sort of thing because of AOL IPs -- they have similar characteristics to Tor, in that a single IP produces lots of behavior, some good some bad. The two differences as I understand them are that AOL will cancel user accounts if you complain loudly enough (but there's constant tension here because in plenty of cases AOL decides not to cancel the account, so Wikipedia has to deal some other way like temporarily blocking the IP), and that it's not clear enough to the Wikipedia operators that there *are* good Tor users. (One might argue that it's hard for Wikipedia to change their perception and learn about any good Tor uses, firstly because good users will blend in and nobody will notice, and secondly because they've prevented them all from editing so there are no data points either way.) So I've been content to wait and watch things progress. Perhaps we will find a volunteer who wants to help hack the mediawiki codebase to be more authentication-friendly (or have more powerful blocking config options). Perhaps we'll find a volunteer to help build the blind-signature pseudonymous authenticated identity management infrastructure that Nick refers to. Perhaps the Wikimedia operators will increasingly get a sense that Tor has something to offer besides vandalism. (I presume this thread re-surfaced because Tor users and operators are periodically telling Wikipedia that they don't like being blocked.) Maybe we will come to the point eventually that it makes sense to do something different than blocking the Tor IP addresses from editing Wikipedia. (Which, we should all remember compared the Gentoo forum situation, is a great step above blocking them from both reading and writing.) It could be that we never reach that point. Certain services on the Internet (like some IRC networks) that are really prone to abuse are probably doing the right thing by blocking all Tor users (and all AOL users, and all open proxies, and ...). And we want to keep Tor easy to block, or we're really going to start getting the other communities angry at us. In summary, I'm not too unhappy with the status quo for now. Tor needs way more basic development / usability work still. In the absence of actual volunteers-who-code on the side of Tor _or_ Wikipedia to resolve the problem, I'm going to focus on continuing to make Tor better, so down the road maybe we'll be able to see better answers. --Roger - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: Wikipedia Tor]
- Forwarded message from Arrakis Tor [EMAIL PROTECTED] - From: Arrakis Tor [EMAIL PROTECTED] Date: Tue, 27 Sep 2005 07:48:22 -0500 To: [EMAIL PROTECTED] Subject: Wikipedia Tor Reply-To: [EMAIL PROTECTED] This is a conversation with Jimmy Wales regarding how we can get Wikipedia to let Tor get through. Anyone with a port 80 can vandalize your website. Yes, but we notice that we can control a significant amount of vandalism by blocking ip numbers which have proven to be particularly problematic. TOR servers are among the absolute worst. And TOR operators don't seem to care. We go to the trouble to block all the file sharing clients, and often abused ports and protocols like IRC. Many of us typically block ports which do not have any legitimate reason for being used. If all it take is a port 80 to vandalize the wikipedia, of which port 80 is a public service, then there is no point in discriminating against Tor users since every IP is an equal opportunity offender. Equal *opportunity*, but we have very strong empirical evidence here. TOR ip numbers are the worst offenders that we have seen. People use TOR specifically to hide their identity, specifically to vandalize wikipedia. You say that tor is quite irresponsibly managed. How would you propose we manage tor servers differently? Ban users who vandalize wikipedia. That'd be a start. Rate limit edits at Wikipedia, that'd be good. Write an extension to your software which would help us to distinguish between trusted and newbie Tor clients. I completely fail to comprehend why Tor server operators consistently refuse to take responsibility for their crazed users. - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [Politech] Are geeks being targeted as terrorists? [fs]]
- Forwarded message from Declan McCullagh declan@well.com - From: Declan McCullagh declan@well.com Date: Mon, 26 Sep 2005 02:29:16 -0700 To: politech@politechbot.com Subject: [Politech] Are geeks being targeted as terrorists? [fs] User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) Original Message Subject: Geeks being targeted as terrorists Date: Fri, 23 Sep 2005 16:18:04 -0400 From: Richard M. Smith [EMAIL PROTECTED] To: 'Declan McCullagh' declan@well.com Hi Declan, It appears that there is a growing group of geeks who are being singled out as terrorists. Although suspected or charged with terror-related crimes, these folks in many cases were simply in the wrong place at the wrong time, have quirky hobbies, or showed poor judgement. Attached is a list of articles about these individuals and their alledged crimes. Richard M. Smith http://www.ComputerBytesMan.com = Suspicious behaviour on the tube http://www.guardian.co.uk/comment/story/0,,1575411,00.html Cape pilot wages battle over FBI's 'No Fly' action http://www.capecodonline.com/cctimes/capepilot23.htm In N.Y., Case Of Germs Shifts From Bioterror To Moral Error http://www.washingtonpost.com/wp-dyn/articles/A16281-2004Jun29.html Man Charged Under Patriot Act for Laser http://abcnews.go.com/US/wireStory?id=385589 Agents search homes of bioterror expert [Kenneth M. Berry] Actions in N.Y., N.J. part of anthrax investigation http://tinyurl.com/c6fnu Patent 6,710,711 - Method for identifying chemical, biological and nuclear attacks or hazards, Kenneth M. Berry http://tinyurl.com/3p6jj Scientist in plague vial case set to appear court http://www.cnn.com/2003/US/Southwest/01/15/missing.plague/ The Hunting of Steven J. Hatfill Why are so many people eager to believe that this man is the anthrax killer? by David Tell http://tinyurl.com/8ac2m Man wrongly linked to Madrid bombings sues Names Ashcroft, Justice Department, FBI; challenges Patriot Act http://www.cnn.com/2004/LAW/10/04/mayfield.lawsuit/ ___ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [Politech] White House supports forcible DNA extraction from Americans by cops [priv]]
- Forwarded message from Declan McCullagh declan@well.com - From: Declan McCullagh declan@well.com Date: Mon, 26 Sep 2005 02:36:51 -0700 To: politech@politechbot.com Subject: [Politech] White House supports forcible DNA extraction from Americans by cops [priv] User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) We discussed this here weeks ago: http://www.politechbot.com/2005/09/13/more-on-dna/ http://www.politechbot.com/2005/09/10/federal-dna-database/ --- http://www.washingtonpost.com/wp-dyn/content/article/2005/09/23/AR2005092301665.html Bill Would Permit DNA Collection From All Those Arrested By Jonathan Krim Washington Post Staff Writer Saturday, September 24, 2005; Page A03 Suspects arrested or detained by federal authorities could be forced to provide samples of their DNA that would be recorded in a central database under a provision of a Senate bill to expand government collection of personal data. The controversial measure was approved by the Senate Judiciary Committee last week and is supported by the White House, but has not gone to the floor for a vote. It goes beyond current law, which allows federal authorities to collect and record samples of DNA only from those convicted of crimes. The data are stored in an FBI-maintained national registry that law enforcement officials use to aid investigations, by comparing DNA from criminals with evidence found at crime scenes. [...remainder snipped...] ___ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] China Tightens Its Restrictions for News Media on the Internet]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Mon, 26 Sep 2005 13:49:32 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] China Tightens Its Restrictions for News Media on the Internet X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Dewayne Hendricks [EMAIL PROTECTED] Date: September 26, 2005 11:40:25 AM EDT To: Dewayne-Net Technology List [EMAIL PROTECTED] Subject: [Dewayne-Net] China Tightens Its Restrictions for News Media on the Internet Reply-To: [EMAIL PROTECTED] [Note: This item comes from reader John McMullen. DLH] From: John F. McMullen [EMAIL PROTECTED] Date: September 25, 2005 10:58:53 PM PDT To: johnmac's living room [EMAIL PROTECTED] Cc: Dewayne Hendricks [EMAIL PROTECTED], Dave Farber [EMAIL PROTECTED] Subject: China Tightens Its Restrictions for News Media on the Internet From the New York Times -- http://www.nytimes.com/2005/09/26/ international/asia/26china.html? ex=1285387200en=38ac65b7be2e2b9bei=5090partner=rssuserlandemc=rss China Tightens Its Restrictions for News Media on the Internet By JOSEPH KAHN BEIJING, Sept. 25 - China on Sunday imposed more restrictions intended to limit the news and other information available to Internet users, and it sharply restricted the scope of content permitted on Web sites. The rules are part of a broader effort to roll back what the Communist Party views as a threatening trend toward liberalization in the news media. Taken together, the measures amount to a stepped- up effort to police the Internet, which has become a dominant source of news and information for millions of urban Chinese. Major search engines and portals like Sina.com and Sohu.com, used by millions of Chinese each day, must stop posting their own commentary articles and instead make available only opinion pieces generated by government-controlled newspapers and news agencies, the regulations stipulate. The rules also state that private individuals or groups must register as news organizations before they can operate e-mail distribution lists that spread news or commentary. Few individuals or private organizations are likely to be allowed to register as news organizations, meaning they can no longer legally distribute information by e-mail. Existing online news sites, like those run by newspapers or magazines, must give priority to news and commentary pieces distributed by the leading national and provincial news organs. This restriction on the ability of Web sites to republish articles produced by the huge array of news organizations that do not fall under direct government control seems intended to ensure that the Propaganda Department has time to filter content generated by local publications before it can be widely disseminated on the Internet. The new rules are the first major update to policies on Internet news and opinion since 2000. The foremost responsibility of news sites on the Internet is to serve the people, serve socialism, guide public opinion in the right direction, and uphold the interests of the country and the public good, the regulations state. Although Chinese authorities have already effectively unlimited powers to control the gathering and publication of news, the Propaganda Department has sometimes struggled to censor information about delicate developments before it circulates on the Internet. About 100 million Chinese now have access to the Internet. Though the government closely monitors domestic content and blocks what officials consider to be subversive Web sites from overseas, savvy users can obtain domestic and overseas information that never appears in China's traditional news media. By the time officials have decided that a topic might prove harmful to the governing party's agenda, an item about it has often already been posted or discussed on hundreds of sites and viewed by many people, defeating some traditional censorship tools. Experts who follow the Internet say one of the most significant changes is the ban on self-generated opinion and commentary articles that accompany the standard state-issued news bulletins on major portal sites. Weblog at: http://weblog.warpspeed.com - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Request: Check your cell phone to see if it's always transmitting your location [priv]]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Thu, 22 Sep 2005 08:57:50 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] Request: Check your cell phone to see if it's always transmitting your location [priv] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Declan McCullagh declan@well.com Date: September 21, 2005 6:22:26 PM EDT To: politech@politechbot.com Subject: [Politech] Request: Check your cell phone to see if it's always transmitting your location [priv] Related Politech message: http://www.politechbot.com/p-05008.html And a column I wrote on this a while ago: http://news.com.com/2010-1071_3-5064829.html -Declan Original Message Subject: Always-on location tracking in cellphones Date: Wed, 21 Sep 2005 18:04:30 -0400 From: Richard M. Smith [EMAIL PROTECTED] To: 'Declan McCullagh' declan@well.com Hi Declan, We have talked before about the FCC mandate which is requiring all U.S. wireless carriers to provide location information to emergency operators accurate to about 150 feet on all 911 calls as part of the Enhanced 911 program (http://www.fcc.gov/911/enhanced/). To meet this FCC mandate, my Verizon Wireless Treo 650 cellphone includes some kind of GPS tracking technology. The Treo also has an option to select if location information is sent in to Verizon for all calls or only 911 calls. I was a bit surprised to learn that my Treo defaults to always sending location information. After a bit of initial confusion, I got confirmation from both Palm and Verizon Wireless that my observation about the default was correct. However, Verizon Wireless told me this is a mistake and going forward, they plan to change the default to 911 calls only. I'm curious now when other models of cellphones transmit location information to carriers. Can folks on Politech check their cellphones and phone manuals to see what kind of controls there are over location information and send me the results? I'll also need the make and model of the phone and the wireless carrier. For my Treo phone, I found the location option under Phone Preferences in the Options menu of the main phone screen. Thanks, Richard M. Smith http://www.ComputerBytesMan.com ___ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: GPS Jammer Firm nearly ejected from Russian air show.
On Thu, Sep 22, 2005 at 04:50:07PM +0200, Nomen Nescio wrote: GPS frequencies are fixed, so they can be interfered with. Only in Military receivers are somewhat hardened at least against terrestrial jamming. It would be probably impossible to be immune to strong airborne (balloons and drones) jammers. these days of general technological incompetence, where intangible scientific principles have reverted to their ancient status as mystic, is the concept of RF interference newsworthy. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
[EMAIL PROTECTED]: [IP] Request: Check your cell phone to see if it's always transmitting your location [priv]]
- Forwarded message from David Farber [EMAIL PROTECTED] - From: David Farber [EMAIL PROTECTED] Date: Thu, 22 Sep 2005 08:57:50 -0400 To: Ip Ip ip@v2.listbox.com Subject: [IP] Request: Check your cell phone to see if it's always transmitting your location [priv] X-Mailer: Apple Mail (2.734) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Declan McCullagh declan@well.com Date: September 21, 2005 6:22:26 PM EDT To: politech@politechbot.com Subject: [Politech] Request: Check your cell phone to see if it's always transmitting your location [priv] Related Politech message: http://www.politechbot.com/p-05008.html And a column I wrote on this a while ago: http://news.com.com/2010-1071_3-5064829.html -Declan Original Message Subject: Always-on location tracking in cellphones Date: Wed, 21 Sep 2005 18:04:30 -0400 From: Richard M. Smith [EMAIL PROTECTED] To: 'Declan McCullagh' declan@well.com Hi Declan, We have talked before about the FCC mandate which is requiring all U.S. wireless carriers to provide location information to emergency operators accurate to about 150 feet on all 911 calls as part of the Enhanced 911 program (http://www.fcc.gov/911/enhanced/). To meet this FCC mandate, my Verizon Wireless Treo 650 cellphone includes some kind of GPS tracking technology. The Treo also has an option to select if location information is sent in to Verizon for all calls or only 911 calls. I was a bit surprised to learn that my Treo defaults to always sending location information. After a bit of initial confusion, I got confirmation from both Palm and Verizon Wireless that my observation about the default was correct. However, Verizon Wireless told me this is a mistake and going forward, they plan to change the default to 911 calls only. I'm curious now when other models of cellphones transmit location information to carriers. Can folks on Politech check their cellphones and phone manuals to see what kind of controls there are over location information and send me the results? I'll also need the make and model of the phone and the wireless carrier. For my Treo phone, I found the location option under Phone Preferences in the Options menu of the main phone screen. Thanks, Richard M. Smith http://www.ComputerBytesMan.com ___ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
