From joaquin.keller at francetelecom.com Mon Oct 3 07:38:18 2005 From: joaquin.keller at francetelecom.com (KELLER Joaquin RD-MAPS-ISS) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Deadline extension || CfP || ICIWA / WEBSA / ENSYS / P2PSA /ONLINE 2006, Guadeloupe, February Message-ID: ============== Deadline extension: CALL FOR SUBMISSIONS ============== (Please accept our apologies if you receive multiple copies of this CFP) ------- New submission deadline: October 16, 2005. ------- Call for Papers International Conference on Internet and Web Applications and Services ICIW'06 February 23-25, 2006 Guadeloupe, French Caribbean http://www.iaria.org/conferences/ICIW06.html Location: Guadeloupe, French Caribbean Submission deadline: October 16, 2005 Notification: November 13, 2005 Camera ready: December 1, 2005 Conference: February 23-25, 2006 The ICIW 2006 will have the following tracks: ICIWA 2006 Internet and Web-based Applications and Services ENSYS 2006 Entertainment Systems P2PSA 2006 P2P Systems and Applications WEBSA 2006 Web Services-based Systems and Applications ONLINE 2006 Online Communications, Collaborative Systems, and Social Networks We would like to cordially invite you to contribute to the conference with some of the following: - Distribute the Call for Papers and solicit contributions - Submit papers - Organize a special session - Propose a panel or tutorial Submit: http://www.iaria.org/conferences/SubmitGuadaICIW06.html GENERAL INFORMATION The ICIW 2006 (International Conference on Internet and Web Applications and Services) inaugurates a series of co-located events that covers the complementary aspects related to designing and deploying of applications based on IP&Web techniques and mechanisms. The main conference focuses on several tracks concerning Web technologies, design and development of Web-based applications, and interactions of these applications with other types of systems. Management aspects related to these applications and challenges on specialized domains are aided at too. Evaluation techniques and standard position on different aspects are part of the expected agenda. The call for submissions covers both theoretical and experimental topics. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited topic areas. Industrial presentations are not subject to these constraints. Tutorials on specific related topics and panels on challenging areas are encouraged. TOPICS OF SPECIAL INTEREST (but not limited to): ICIWA 2006: Internet and Web-based Applications and Services Web technologies, frameworks, languages, mechanisms Web applications design and development Interaction with/from Web-based applications Web-based applications' features Management of Web-based applications Evaluation of Web applications Specialized Web applications Aggregating multimedia documents E-business, appliances, and services IP Grid Management and Grid Services IP-based convergent solutions and next generation networks Standards, case studies and special groups on web-based applications ENSYS 2006: Entertainment Systems Developing entertainment systems and applications Platforms for entertainment systems Speech technology & its usability for entertainment systems Networking requirements for entertainment systems Traffic generated by entertainment applications QoS/SLA on entertainment systems Reliability and high availability of entertainment systems Identify aspects in entertainment systems Real-time access to entertainment systems Customized access entertainment systems Navigation and entertainment systems Integration and interoperability aspects in entertainment systems Entertainment systems and applications Networking and system support for entertainment systems Wireless and mobile technologies for entertainment Wireless multimedia for entertainment Systems for music and movie distribution Games on mobile and resource-constrained devices Mobile video entertainment systems Car/flight/train entertainment systems Ubiquitous entertainment systems Interactive television Technologies for sport and entertainment WiFi wireless home entertainment systems Wearable technologies for entertainment P2PSA 2006: P2P Systems and Applications P2P architectures, techniques, paradigms P2P programming and data handling P2P security features Data and compute intensive applications P2P networks and protocols P2P management P2P Trust and reputation management Fault tolerance in P2P, quality of availability, accounting in P2P Self-adaptiveness in P2P overlay networks Self-configurable P2P systems Case studies, benchmarking Copyright and intellectual property, Electronic marketplace, Digital asset management and trading systems Platforms, environments, testbeds WEBSA 2006: Web Services-based Systems and Applications Web services foundation, architectures, frameworks, languages Web services architecture and business continuity Special Web services mechanisms Semantic Web, Ontology, and Web services Web service applications Data Management aspects in Web Services Autonomic e-Business integration and collaboration Web service based Grid computing and P2P computing Web services based applications for e-Commerce Multimedia applications using Web Services Automatic computing for Web services Web services challenges on trust, security, performance, scalability Enterprise Web services Web services discovery, announcing, monitoring and management Platforms, technologies, mechanisms and case studies Grid architectures, middleware and toolkits ONLINE 2006: Online Communications, Social networks Theory, frameworks, mechanisms, and tools for online communication Methodologies and languages for on-line communications Web services and XML use for online communications Tools for assessing online work, distributed workload Shared business processes Collaborative groups and systems Theory and formalisms of group interactions Group synergy in cooperative networks Online gambling, gaming, children groups Identity features, risks, jurisdiction for online communications Specifics emergency and e-coaching on online communications B2B and B2E cooperation Privacy, identify, security on online communications Individual anonymity, group trust, and confidentiality on online groups Conflict, delegation, group selection Community costs in collaborative groups Building online social networks with popularity contexts, persuasion, etc. Technology support for collaborative systems Techniques, mechanisms, and platforms for remote cooperation INSTRUCTION FOR THE AUTHORS The ICIW 2006 Proceedings will be published by IEEE Computer Society Press. Important dates: Submission deadline: October 16, 2005 Notification: November 13, 2005 Camera ready: December 1, 2005 Only .pdf or .doc files will be accepted for paper submission. All received papers will be acknowledged via the EDAS system. The files should be sent via http://www.iaria.org/conferences/SubmitGuadaICIW06.html Final author manuscripts will be 8.5" x 11" (two columns IEEE format), not exceeding 6 pages; max 4 extra pages allowed at additional cost. The formatting instructions can be found via anonymous FTP site at: ftp://pubftp.computer.org/Press/Outgoing/proceedings/8.5x11%20-%20Formatting%20files/instruct.pdf Once you receive the notification of paper acceptance, you will be provided by the IEEE CS Press an online author kit with all the steps an author needs to follow to submit the final version. The author kits URL will be included in the letter of acceptance. Technical marketing/business/positioning presentations The conference initiates a series of business, technical marketing, and positioning presentations on the same topics. Speakers must submit a 10-12 slide deck presentations with substantial notes accompanying the slides, in the .ppt format (.pdf-ed). The slide deck will be published in the conference's CD collection, together with the regular papers. Please send your presentations to petre@iaria.org. Tutorials Tutorials provide overviews of current high interest topics. Proposals can be for half or full day tutorials. Please send your proposals to petre@iaria.org Panel proposals: The organizers encourage scientists and industry leaders to organize dedicated panels dealing with controversial and challenging topics and paradigms. Panel moderators are asked to identify their guests and manage that their appropriate talk supports timely reach our deadlines. Moderators must specifically submit an official proposal, indicating their background, panelist names, their affiliation, the topic of the panel, as well as short biographies. For more information, petre@iaria.org TECHNICAL PROGRAM COMMITTEES Check http://www.iaria.org/conferences/ComICIW06.html for a complete list of the program committe members and their associated tracks. Looking forward for your contributions, ICIWA / WEBSA / ENSYS / P2PSA / ONLINE 2006 Chairs: Karim El Guemhioui, Universit? du Qu?bec en Outaouais, Canada, karim.elguemhioui@uqo.ca M?rio Freire, University of Beira Interior, Portugal, mario@di.ubi.pt Sergiu Dascalu, University of Nevada at Reno, USA, dascalus@cs.unr.edu Rafael Dueire Lins, Universidade Federal de Pernambuco, Brazil, rdl@ufpe.br Abdelhakim Hafid, University of Montreal, Canada, ahafid@iro.umontreal.ca Joaquin Keller, France Telecom, France, joaquin.keller@francetelecom.com Dumitru Roman, Digital Enterprise Research Institute, Austria, dumitru.roman@deri.org Abdelhamid Mellouk, University of Paris XII - Val de Marne, France, mellouk@ieee.org Vladimir Tosic, Lakehead University, Canada, vladat@computer.org =================================================== From matthew at matthew.at Thu Oct 6 05:20:23 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] amicima MFPNet status Message-ID: <200510060520.j965KRU92313@where.matthew.at> Status update for folks wondering what's amicima has been up to... It took about a month longer than we'd hoped, but the MFPNet and MFPAC code has many more features, more scalability, and is much cleaner code than we'd expected to get done for the first release as a result. In fact, we took the time to almost completely rewrite the entire MFPNet layer from improved specifications given our experience using the first version in-house for the last year. The biggest feature that MFPNet brings is the ability to open MFP flows directly to named endpoints without worrying about their IP address(es) or whether or not NAT/firewall traversal is needed... it "just works", and supports unique endpoint namespaces in each domain as well, with full inter-domain interoperability. MFPAC builds on this, providing services for authenticated one-to-many communication of control or status messages, designed for the rapid implementation of secure peer-to-peer call setup, file availability, or presence updating, among other applications. The source code (GPL, with an available commercial license) should be released in less than a week (just cleaning up some final documentation and checking for any hiding bugs), but for now the API headers for MFPNet and its companion MFPAC are available on our website at http://www.amicima.com/developers/downloads.html and some additional documentation will be up on the website over the next few days. Once the MFPNet layer is shipped we'll be working to quickly get at least one demo application out in source and executable form so everyone can get a chance to play with how it performs in real life. Then, depending on time and funding, we'll be moving on to finalizing our MFPGroup secure DHT-based many-to-many communication layer. For those who've already starting experimenting with or using the MFP layer, we'll be releasing an update with some bug fixes and minor feature enhancements this week as well. Matthew Kaufman matthew@matthew.at http://www.amicima.com From matthew at matthew.at Sat Oct 8 22:18:30 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] amicima MFPNet status In-Reply-To: <200510060520.j965KRU92313@where.matthew.at> Message-ID: <200510082218.j98MIcU10908@where.matthew.at> Amicima's MFPNet layer (including MFPAC), as pre-announced on Wednesday, is now released as open-source software. It is available at our website: http://www.amicima.com/developers/downloads.html It, like MFP, is licensed under the GPL with an available commercial license for developers of closed-source or non-GPL-compatible software. If you have previously downloaded MObj or MFP, updated versions of those, including some bug fixes for MFP, are available on the web site as well. Next up will be at least one demo application that shows off what MFP and MFPNet can do, followed, depending on time and funding, by the MFPGroup secure DHT layer and other applications. Matthew Kaufman matthew@matthew.at www.amicima.com From sam at neurogrid.com Mon Oct 10 18:53:51 2005 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Workshop on Dependable and Sustainable Peer-to-Peer Systems Message-ID: <434AB8BF.1090908@neurogrid.com> [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 R&D 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 ks91@sfc.wide.ad.jp [PROGRAM COMMITTEE] See the workshop web site (http://das-p2p.wide.ad.jp/). ----- From rabbi at abditum.com Tue Oct 11 19:10:28 2005 From: rabbi at abditum.com (Len Sassaman) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] CodeCon 2006 Call For Papers Message-ID: CodeCon 2006 February 10-12, 2006 San Francisco CA, USA www.codecon.org Call For Papers CodeCon is the premier showcase of cutting edge software development. It is an excellent opportunity for programmers to demonstrate their work and keep abreast of what's going on in their community. All presentations must include working demonstrations, ideally accompanied by source code. Presentations must be done by one of the active developers of the code in question. We emphasize that demonstrations be of *working* code. We hereby solicit papers and demonstrations. * Papers and proposals due: December 15, 2005 * Authors notified: January 1, 2006 Possible topics include, but are by no means restricted to: * community-based web sites - forums, weblogs, personals * development tools - languages, debuggers, version control * file sharing systems - swarming distribution, distributed search * security products - mail encryption, intrusion detection, firewalls Presentations will be 45 minutes long, with 15 minutes allocated for Q&A. Overruns will be truncated. Submission details: Submissions are being accepted immediately. Acceptance dates are November 15, and December 15. After the first acceptance date, submissions will be either accepted, rejected, or deferred to the second acceptance date. The conference language is English. Ideally, demonstrations should be usable by attendees with 802.11b connected devices either via a web interface, or locally on Windows, UNIX-like, or MacOS platforms. Cross-platform applications are most desirable. Our venue will be 21+. To submit, send mail to submissions-2006@codecon.org including the following information: * Project name * url of project home page * tagline - one sentence or less summing up what the project does * names of presenter(s) and urls of their home pages, if they have any * one-paragraph bios of presenters, optional, under 100 words each * project history, under 150 words * what will be done in the project demo, under 200 words * slides to be shown during the presentation, if applicable * future plans General Chair: Jonathan Moore Program Chair: Len Sassaman Program Committee: * Bram Cohen, BitTorrent, USA * Jered Floyd, Permabit, USA * Ian Goldberg, Zero-Knowledge Systems, CA * Dan Kaminsky, Avaya, USA * Ben Laurie, The Bunker Secure Hosting, UK * Nick Mathewson, The Free Haven Project, USA * David Molnar, University of California, Berkeley, USA * Jonathan Moore, Mosuki, USA * Meredith L. Patterson, University of Iowa, USA * Len Sassaman, Katholieke Universiteit Leuven, BE Sponsorship: If your organization is interested in sponsoring CodeCon, we would love to hear from you. In particular, we are looking for sponsors for social meals and parties on any of the three days of the conference, as well as sponsors of the conference as a whole and donors of door prizes. If you might be interested in sponsoring any of these aspects, please contact the conference organizers at codecon-admin@codecon.org. Press policy: CodeCon provides a limited number of passes to qualifying press. Complimentary press passes will be evaluated on request. Everyone is welcome to pay the low registration fee to attend without an official press credential. Questions: If you have questions about CodeCon, or would like to contact the organizers, please mail codecon-admin@codecon.org. Please note this address is only for questions and administrative requests, and not for workshop presentation submissions. From ian at locut.us Sun Oct 16 10:13:34 2005 From: ian at locut.us (Ian Clarke) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] DAS-P2P Call for Papers, April 2006, Vienna Message-ID: ************************************************************************ ****** * The First International Workshop on * Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) * http://das-p2p.wide.ad.jp/ * * In conjunction with The First International Conference on * Availability, Reliability and Security (ARES 2006). * http://www.ifs.tuwien.ac.at/ares2006/ * * Vienna University of Technology, Austria * April 20th-22nd, 2006 ************************************************************************ ****** [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 peer-to-peer (P2P) systems, with respect to their designs, operations, applications and social impacts. 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, who 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 Springer- Verlag LNCS Proceedings Author Guidelines: 10-point, single-spaced, one-column format (see http://www.springer.de/comp/lncs/authors.html for detail). Each of your contributions should not exceed 10 pages. See the workshop web site (http://das-p2p.wide.ad.jp/) for the submission procedure. [PUBLICATION] Proceedings of the workshop will be published as Lecture Notes in Computer Science (LNCS) by Springer-Verlag. [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. [PROGRAM COMMITTEE] * Stephane Bressan, National University of Singapore, Singapore * Bernard Burg, Panasonic Research, USA * Yusuke Doi, TOSHIBA Corporation, Japan (co-chair) * Debojyoti Dutta, University of Southern California, USA * Achmad Nizar Hidayanto, University of Indonesia, Indonesia * Sam Joseph, University of Hawaii, USA * Youki Kadobayashi, Nara Instritute of Science and Technology, Japan (co-chair) * Anirban Mondal, University of Tokyo, Japan * Akiko Orita, Keio University, Japan * Omer F Rana, Cardiff University, UK * Kenji Saito, Keio University, Japan (co-chair) * Claudio Sartori, University of Bologna, Italy * Sheng Zhong, State University of New York at Buffalo, USA See the workshop web site (http://das-p2p.wide.ad.jp/) for any updates. ----- For further information, please contact program co-chair Kenji Saito, Graduate School of Media and Governance, Keio University, 5322 Endo, Fujisawa, Kanagawa 252-8520 Japan, e-mail: ks91@sfc.wide.ad.jp ---------- From ian at locut.us Sun Oct 16 10:15:38 2005 From: ian at locut.us (Ian Clarke) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] DAS-P2P Call for Papers, April 2006, Vienna In-Reply-To: References: Message-ID: <1798BFD0-FF59-4820-B5AD-4AE923D84BE7@locut.us> Oops, apologies, just realised that Sam Joseph had already posted this. Ian. On 16 Oct 2005, at 11:13, Ian Clarke wrote: > ********************************************************************** > ******** > * The First International Workshop on > * Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) > * http://das-p2p.wide.ad.jp/ > * > * In conjunction with The First International Conference on > * Availability, Reliability and Security (ARES 2006). > * http://www.ifs.tuwien.ac.at/ares2006/ > * > * Vienna University of Technology, Austria > * April 20th-22nd, 2006 > ********************************************************************** > ******** > > [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 peer-to-peer (P2P) systems, with respect to > their > designs, operations, applications and social impacts. > > 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, who 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 Springer- > Verlag LNCS > Proceedings Author Guidelines: 10-point, single-spaced, one-column > format > (see http://www.springer.de/comp/lncs/authors.html for detail). > Each of your > contributions should not exceed 10 pages. > > See the workshop web site (http://das-p2p.wide.ad.jp/) for the > submission > procedure. > > [PUBLICATION] > > Proceedings of the workshop will be published as Lecture Notes in > Computer > Science (LNCS) by Springer-Verlag. > > [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. > > [PROGRAM COMMITTEE] > > * Stephane Bressan, National University of Singapore, Singapore > * Bernard Burg, Panasonic Research, USA > * Yusuke Doi, TOSHIBA Corporation, Japan (co-chair) > * Debojyoti Dutta, University of Southern California, USA > * Achmad Nizar Hidayanto, University of Indonesia, Indonesia > * Sam Joseph, University of Hawaii, USA > * Youki Kadobayashi, Nara Instritute of Science and Technology, Japan > (co-chair) > * Anirban Mondal, University of Tokyo, Japan > * Akiko Orita, Keio University, Japan > * Omer F Rana, Cardiff University, UK > * Kenji Saito, Keio University, Japan (co-chair) > * Claudio Sartori, University of Bologna, Italy > * Sheng Zhong, State University of New York at Buffalo, USA > > See the workshop web site (http://das-p2p.wide.ad.jp/) for any > updates. > > ----- > For further information, please contact program co-chair Kenji Saito, > Graduate School of Media and Governance, Keio University, 5322 > Endo, Fujisawa, > Kanagawa 252-8520 Japan, e-mail: ks91@sfc.wide.ad.jp > ---------- > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > From zubin_madon at yahoo.com Mon Oct 17 03:52:08 2005 From: zubin_madon at yahoo.com (zubin madon) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] looking for someone with experience in bittorrent and java Message-ID: <20051017035208.86831.qmail@web30304.mail.mud.yahoo.com> Hi all, We are looking for someone with experience in p2p (esp., BitTorrent), solving firewall issues, and good with java programming to help create an application. We are in san francisco area. If you are interested please email back to me. thanks, zubin __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From webmaster at zgp.org Tue Oct 18 07:46:20 2005 From: webmaster at zgp.org (webmaster@zgp.org) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Warning Message: Your services near to be closed. Message-ID: <20051018074220.6BF173FC2C@capsicum.zgp.org> An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051018/52bb3e2c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: document.zip Type: application/octet-stream Size: 27750 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20051018/52bb3e2c/document.obj From lemonobrien at yahoo.com Tue Oct 18 18:58:52 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Warning Message: Your services near to be closed. In-Reply-To: <20051018074220.6BF173FC2C@capsicum.zgp.org> Message-ID: <20051018185853.4458.qmail@web53610.mail.yahoo.com> my email address is an yahoo email address; i think you may be barking up the wrong tree. webmaster@zgp.org wrote: Dear Zgp Member, Your e-mail account was used to send a huge amount of unsolicited spam messages during the recent week. If you could please take 5-10 minutes out of your online experience and confirm the attached document so you will not run into any future problems with the online service. If you choose to ignore our request, you leave us no choice but to cancel your membership. Virtually yours, The Zgp Support Team +++ Attachment: No Virus found +++ Zgp Antivirus - www.zgp.org _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051018/342286db/attachment.html From p2phack at cilux.org Tue Oct 18 19:13:47 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Warning Message: Your services near to be closed. In-Reply-To: <20051018185853.4458.qmail@web53610.mail.yahoo.com> References: <20051018185853.4458.qmail@web53610.mail.yahoo.com> Message-ID: <4355496B.9000206@cilux.org> Just so it's clear to anyone that didn't spot it (the bad English in the Subject and body, the bogus virus scan message plus the fact that it's a zip are indicators), this is a user-activated worm, as described here: http://www.sarc.com/avcenter/venc/data/w32.mytob.ku@mm.html The email apparently originated from via 'cncnet.net': 1ge1-C6K1-MSFC-SH2-CHJ1.sh.cncnet.net [210.22.66.70] 210.22.105.130 (a traceroute on the IP address given in the email headers) Whois: China NetCom Corp. Building C,No.156 Fuxingmennei St.Beijing,10031,China 100031 So, leave it alone...! Duncan From codewarrior at cuseeme.de Tue Oct 18 19:16:05 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Warning Message: Your services near to be closed. In-Reply-To: <20051018185853.4458.qmail@web53610.mail.yahoo.com> References: <20051018185853.4458.qmail@web53610.mail.yahoo.com> Message-ID: On Oct 18, 2005, at 8:58 PM, Lemon Obrien wrote: > my email address is an yahoo email address; i think you may be > barking up the wrong tree. this was fake anyway... got that to earlyer chers > > webmaster@zgp.org wrote: > Dear Zgp Member, > > Your e-mail account was used to send a huge amount of unsolicited > spam messages during the recent week. If you could please take 5-10 > minutes out of your online experience and confirm the attached > document so you will not run into any future problems with the > online service. > > If you choose to ignore our request, you leave us no choice but to > cancel your membership. > > Virtually yours, > The Zgp Support Team -- "If you're not confused, You're not paying attention" Les Enfants Terribles C.V.O. Marc Manthey Hildeboldplatz 1a 50672 K?ln - Germany main site: www.let.de developer:www.cuseeme.de www.applehelpers.com my blog:http://brain.let.de AIM ,MSN, MAC= macbroadcast From dsandler at cs.rice.edu Wed Oct 19 03:09:54 2005 From: dsandler at cs.rice.edu (Dan Sandler) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Announcement: FeedTree (RSS over p2p) Message-ID: <9515D254-2EEE-43D7-AED8-108BB5601081@cs.rice.edu> We are pleased to announce the availability of FeedTree, a peer-to-peer distribution system for RSS and Atom feed updates. # For the impatient: # Details and downloads at http://feedtree.net/ FeedTree reduces the bandwidth burden of offering news feeds, while at the same time allowing feed updates to reach end users faster than before (within seconds, not hours). Users of FeedTree form a peer-to-peer network which is used to disseminate new feed events; this multicast (built on Scribe) is an efficient group notification mechanism which spreads the burden of distributing feed data among the feed's subscribers. Our software (available now) includes: * The FeedTree Proxy, an end-user Java application which allows *existing* RSS reading apps to receive updates via the FeedTree network. The proxy also works with current RSS and Atom feeds, polling them as necessary and sharing new content with other FeedTree users. * The FeedTree Publisher, an optional tool allowing feed authors to "push" updates to FeedTree users immediately. It runs alongside existing RSS/Atom feeds, so it works with all existing CMSes and weblog engines. The publisher also allows publishers to add digital signatures to their feeds (helping nodes verify the authenticity of updates). More information, including research papers, documentation, source code, and bug reporting can be found on the FeedTree website: http://feedtree.net/ . We'd love to hear about your experiences using the system, as well as any other feedback you might have. FeedTree is an ongoing project of researchers in the Rice University Computer Science Department. -- Dan Sandler dsandler@cs.rice.edu http://www.cs.rice.edu/~dsandler/ From webmaster at zgp.org Thu Oct 20 21:42:45 2005 From: webmaster at zgp.org (webmaster@zgp.org) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] *DETECTED* ONLINE USER VIOLATION Message-ID: <20051020213842.34F273FD3D@capsicum.zgp.org> An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051021/6810aa78/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: important-details.zip Type: application/octet-stream Size: 27768 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20051021/6810aa78/important-details.obj From webmaster at zgp.org Fri Oct 21 07:38:08 2005 From: webmaster at zgp.org (webmaster@zgp.org) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Your new account password is approved Message-ID: <20051021073802.E87353FC41@capsicum.zgp.org> An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051021/859b087d/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: password.zip Type: application/octet-stream Size: 49934 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20051021/859b087d/password.obj From francis.moore at rawflow.com Tue Oct 25 13:45:47 2005 From: francis.moore at rawflow.com (Frank Moore) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] P2P Authentication Message-ID: <435E370B.4060807@rawflow.com> Hi, I have the following problem: I'm working on a hybrid p2p network where there is a central server and lots of clients (peers). I need a way for clients to authenticate themselves when they join the network. I've looked at doing a challenge response type thing using Challenge Handshake Authentication Protocol (CHAP) but that means putting a shared secret key in each client and the server. It seems entirely possible that someone could reverse engineer the client executable to get hold of the shared secret key and then write a 'rogue' client (or server) to subvert the network? Is there a standard (or any) way of authenticating peers in p2p networks that doesn't require secret shared keys? Cheers, F. From dcarboni at gmail.com Tue Oct 25 14:23:08 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E370B.4060807@rawflow.com> References: <435E370B.4060807@rawflow.com> Message-ID: <71b79fa90510250723w8048f26w8cb126bd4274a6da@mail.gmail.com> On 10/25/05, Frank Moore wrote: > Hi, > > I have the following problem: > > I'm working on a hybrid p2p network where there is a central server and > lots of clients (peers). I need a way for clients to authenticate > themselves when they join the network. I've looked at doing a challenge > response type thing using Challenge Handshake Authentication Protocol > (CHAP) but that means putting a shared secret key in each client and > the server. > > It seems entirely possible that someone could reverse engineer the > client executable to get hold of the shared secret key and then write a > 'rogue' client (or server) to subvert the network? > > Is there a standard (or any) way of authenticating peers in p2p > networks that doesn't require secret shared keys? > I have a similar problem. Currently I'm thinking to use socket over SSL to establish a connection between peers. So my idea is: (1) a unique certification authority CA for the community issues certificates to participants who are entitled to join (2) once p1 connects to p2, ssl authentication via certificate is requested both for the 'client' and for the 'server'. If both certificates are issued by CA the connection is up otherwise the connection fails. This way, there is no need to connect to a central DB and there are not shared secrets but each node must keep secret its private key. I'm just concerned about performances. D. -- I lose control 'cause I'm a creature of the night (Bruce and Bongo) -- http://people.crs4.it/dcarboni From wesley at felter.org Tue Oct 25 15:19:31 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E370B.4060807@rawflow.com> References: <435E370B.4060807@rawflow.com> Message-ID: <435E4D03.5090900@felter.org> Frank Moore wrote: > I'm working on a hybrid p2p network where there is a central server and > lots of clients (peers). I need a way for clients to authenticate > themselves when they join the network. Authenticate what aspect of themselves? To whom? Wes Felter - wesley@felter.org From bryan.turner at pobox.com Tue Oct 25 15:20:39 2005 From: bryan.turner at pobox.com (Bryan Turner) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <71b79fa90510250723w8048f26w8cb126bd4274a6da@mail.gmail.com> Message-ID: <200510251520.j9PFKdEi026575@rtp-core-2.cisco.com> Frank, Davide's suggestion is correct, your situation is exactly what the Public Key Infrastructure was designed to handle. [1] Under PKI a node must first register with the central authority, who signs the public key of the new node. This step need only be done once for each entity in the network (you can be the CA for your network). Later, when two nodes in the network meet, they simply exchange public keys and check the signature. Authentication is implicit if you hold a signed public key and its private counterpart. SSL uses this type of mechanism (given the correct options), and is well documented in RFCs/TechNotes [2]. Using PKI, each client must store only one key pair, the central authority's public key, and the CA's signature on their public key. You should be aware that revoking authentication is very cumbersome and requires active participation by the clients. This tends to be a weak link in PKI deployments. I prefer to sign keys as a 'lease' for some amount of time (weeks/months) and they are automatically rejected after this time, not sure if this extension has made it into the newer versions of SSL yet. [1] PKI : http://www.pki-page.org/ [2] SSL/TLS : http://www21.ocn.ne.jp/~k-west/SSLandTLS/index-e.html --Bryan bryan.turner@pobox.com -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Davide Carboni Sent: Tuesday, October 25, 2005 10:23 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] P2P Authentication I have a similar problem. Currently I'm thinking to use socket over SSL to establish a connection between peers. So my idea is: (1) a unique certification authority CA for the community issues certificates to participants who are entitled to join (2) once p1 connects to p2, ssl authentication via certificate is requested both for the 'client' and for the 'server'. If both certificates are issued by CA the connection is up otherwise the connection fails. This way, there is no need to connect to a central DB and there are not shared secrets but each node must keep secret its private key. I'm just concerned about performances. D. From kerry at vscape.com Tue Oct 25 15:28:25 2005 From: kerry at vscape.com (Kerry Bonin) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <71b79fa90510250723w8048f26w8cb126bd4274a6da@mail.gmail.com> References: <435E370B.4060807@rawflow.com> <71b79fa90510250723w8048f26w8cb126bd4274a6da@mail.gmail.com> Message-ID: <435E4F19.4090104@vscape.com> FWIW, this is exactly how I do it - my architecture is hybrid, the only non p2p resources are some secure database servers for a special class of data and a CA. Every "registered" user gets any X.509 cert and has to store their own private keys. Just make sure your root cert keys are _really_ safe - if you want new users to be able to automatically obtain certs, that implies network access to the CA. Make sure you firewall well, scrub the incoming CSRs, and have some DDOS resistant proxies in front of it (client puzzles work great for that aspect.) Using an HSM instead of a normal server helps, but they're expensive... Another nice thing about certs is that you don't have to use SSL - if you still want a UDP based protocol, just use the cert to sign your key exchange, then use a stream cipher that can live w/ dropped packets. I've got a simple protocol for this I need to turn into an RFC and publish as open source, just too many other items in front of it at the moment... Davide Carboni wrote: >On 10/25/05, Frank Moore wrote: > > >>Hi, >> >>I have the following problem: >> >>I'm working on a hybrid p2p network where there is a central server and >>lots of clients (peers). I need a way for clients to authenticate >>themselves when they join the network. I've looked at doing a challenge >>response type thing using Challenge Handshake Authentication Protocol >>(CHAP) but that means putting a shared secret key in each client and >>the server. >> >>It seems entirely possible that someone could reverse engineer the >>client executable to get hold of the shared secret key and then write a >>'rogue' client (or server) to subvert the network? >> >>Is there a standard (or any) way of authenticating peers in p2p >>networks that doesn't require secret shared keys? >> >> >> > >I have a similar problem. Currently I'm thinking to use socket over >SSL to establish a connection between peers. So my idea is: >(1) a unique certification authority CA for the community issues >certificates to participants who are entitled to join >(2) once p1 connects to p2, ssl authentication via certificate is >requested both for the 'client' and for the 'server'. If both >certificates are issued by CA the connection is up otherwise the >connection fails. > >This way, there is no need to connect to a central DB and there are >not shared secrets but each node must keep secret its private key. >I'm just concerned about performances. >D. > > >-- >I lose control 'cause I'm a creature of the night (Bruce and Bongo) >-- >http://people.crs4.it/dcarboni >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051025/b50223db/attachment.htm From francis.moore at rawflow.com Tue Oct 25 15:39:21 2005 From: francis.moore at rawflow.com (Frank Moore) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E4D03.5090900@felter.org> References: <435E370B.4060807@rawflow.com> <435E4D03.5090900@felter.org> Message-ID: <435E51A9.6020808@rawflow.com> Wes Felter wrote: > Authenticate what aspect of themselves? To whom? > > Wes Felter - wesley@felter.org Wes, I want a client to join a P2P network after authenticating itself to a streaming server. The server needs to authenticate that the client is not a rogue who will subvert the stream. Once the client has authenticated and can join the network it will be allowed to stream to other peers below it in the network hierarchy. Cheers, F. From wesley at felter.org Tue Oct 25 16:02:52 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E51A9.6020808@rawflow.com> References: <435E370B.4060807@rawflow.com> <435E4D03.5090900@felter.org> <435E51A9.6020808@rawflow.com> Message-ID: <435E572C.9020909@felter.org> Frank Moore wrote: > I want a client to join a P2P network after authenticating itself to a > streaming server. > The server needs to authenticate that the client is not a rogue who will > subvert the stream. In theory the solution to this problem is TCG remote attestation, but you can't actually use it (yet). The practical half-solution is to obfuscate your protocol as much as you can. It's not clear to me whether a shared secret or PKI provides more obfuscation; certainly PKI is more complex and computationally-intensive. Wes Felter - wesley@felter.org From paul at soniq.net Tue Oct 25 16:18:51 2005 From: paul at soniq.net (Paul Boehm) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E51A9.6020808@rawflow.com> References: <435E370B.4060807@rawflow.com> <435E4D03.5090900@felter.org> <435E51A9.6020808@rawflow.com> Message-ID: <435E5AEB.3040303@soniq.net> Frank Moore wrote: > I want a client to join a P2P network after authenticating itself to a > streaming server. > The server needs to authenticate that the client is not a rogue who will > subvert the stream. > Once the client has authenticated and can join the network it will be > allowed to stream to other > peers below it in the network hierarchy. Frank, I'm not sure if there are any viable strategies for ensuring that a client hasn't been tampered with. Just like with classical copy protection schemes, all known countermeasures are easily bypassed, and all known obfuscation schemes don't render reverse-engineering significantly more difficult. Your best bet probably is to design the security measures into the protocol, e.g. by authenticating the transmitted data, or by asking other peers to connect to random other streaming peers to verify they are not tampering with the data. What measures are neccessary or most effective of course depends on your application, and what attacker model you are dealing with in the first place. But the common theme is to let the network do the job, not the local clients of would-be attackers. Paul From lemonobrien at yahoo.com Tue Oct 25 18:44:49 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E572C.9020909@felter.org> Message-ID: <20051025184449.44736.qmail@web53603.mail.yahoo.com> why don't you just use ssl or some type of encrypted password. Wes Felter wrote:Frank Moore wrote: > I want a client to join a P2P network after authenticating itself to a > streaming server. > The server needs to authenticate that the client is not a rogue who will > subvert the stream. In theory the solution to this problem is TCG remote attestation, but you can't actually use it (yet). The practical half-solution is to obfuscate your protocol as much as you can. It's not clear to me whether a shared secret or PKI provides more obfuscation; certainly PKI is more complex and computationally-intensive. Wes Felter - wesley@felter.org _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051025/a22562d6/attachment.html From nagendra at cs.stanford.edu Tue Oct 25 19:11:29 2005 From: nagendra at cs.stanford.edu (nagendra modadugu) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E4F19.4090104@vscape.com> References: <435E370B.4060807@rawflow.com> <71b79fa90510250723w8048f26w8cb126bd4274a6da@mail.gmail.com> <435E4F19.4090104@vscape.com> Message-ID: <20051025191129.GB9348@cs.stanford.edu> * Kerry Bonin [2005-10-25 08:28:25 -0700]: > Another nice thing about certs is that you don't have to use SSL - if > you still want a UDP based protocol, just use the cert to sign your key > exchange, then use a stream cipher that can live w/ dropped packets. > I've got a simple protocol for this I need to turn into an RFC and > publish as open source, just too many other items in front of it at the > moment... You may find Datagram TLS useful: http://ietf.org/internet-drafts/draft-rescorla-dtls-05.txt Datagram TLS is essentially a version of TLS that works over datagram transport while respecting datagram semantics. The handshake protocol implements some rudimentary reliability, but otherwise functions as in TLS. OpenSSL 0.9.8 includes an implementation of DTLS. nagendra From alenlpeacock at gmail.com Wed Oct 26 16:32:57 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E370B.4060807@rawflow.com> References: <435E370B.4060807@rawflow.com> Message-ID: Introducing a certificate authority not only requires that every participant in the network have complete trust in the authority, but creates a central choke point for congestion, failure, and attack. Here's a rough sketch of an alternative I've been thinking about. Please poke holes if you see them: Allow each node to choose its own identity in the form of a random, locally generated public/private key pair. A node's ID is the public key, or the hash of the public key. Each node needs to maintain trust records of other nodes it interacts with. In order for trust to work, it has to be intractable for imposters to hijack a node's identity. To accomplish this, the sender issues a challenge for every operation (or session), encoded using the public key of the receiver. The challenge contains the sender's public key concatenated with some random data. The receiver decodes the challenge with their own private key, and verifies that it contains the sender's public key. If it does, the sender responds with the decoded challenge. If it doesn't, the sender ignores the node (to prevent relay/man-in-the-middle attacks) and decreases trust in communication coming from that node. The sender likewise verifies the receiver's identity by issuing the same type of challenge in the opposite direction. In other words, given a node 'A', a node 'B', and an attacker 'C', each with a public/private key pair (Au/Ar, Bu/Br, etc): A ---- challenge Cb = enc(Au+rand, Bu) -------------------> B A <--- response Ra = dec(Cb, Br) iff Ra contains Au ------- B A <--- challenge Ca = enc(Bu+rand, Au) -------------------- B A ---- response Rb = dec(Ca, Ar) iff Rb contains Bu ------> B A <--------------- data, signed with Br ------------------- B Now, attacker C cannot pose as A when talking with B, nor as node B when talking with A (it wouldn't be able to form the correct response to the challenges). C can still proxy requests, but cannot tamper with the challenge/response or data without being detected. The only way for C to be a successful imposter is if it had possession of A or B's private keys. This is the identity guarantee required for trust to work. Anyone see how to compromise this guarantee? If you get a rogue or malicious node in the network, you can use the trust system to minimize its effectiveness. I don't think this scheme is new, and it is a tad inefficient if done for every operation. Using it to set up some type of secure session would be a useful improvement. You may want to consult some of the literature on trust systems. The GNUnet project in particular has a nice paper on excess-based economics and trust, but the literature has many other examples as well. Reputations are another variant. Alen On 10/25/05, Frank Moore wrote: > Hi, > > I have the following problem: > > I'm working on a hybrid p2p network where there is a central server and > lots of clients (peers). I need a way for clients to authenticate > themselves when they join the network. I've looked at doing a challenge > response type thing using Challenge Handshake Authentication Protocol > (CHAP) but that means putting a shared secret key in each client and > the server. > > It seems entirely possible that someone could reverse engineer the > client executable to get hold of the shared secret key and then write a > 'rogue' client (or server) to subvert the network? > > Is there a standard (or any) way of authenticating peers in p2p > networks that doesn't require secret shared keys? > > Cheers, > F. From solipsis at pitrou.net Wed Oct 26 16:44:34 2005 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> Message-ID: <1130345074.5978.4.camel@fsol> > In other words, given a node 'A', a node 'B', and an attacker 'C', > each with a public/private key pair (Au/Ar, Bu/Br, etc): [snip] How do A and B know their counterpart's public keys for sure? And if they do, then why reinvent the wheel? Traditional public key signing works well for these cases. IOW, I think your problem is ill-defined. From francis.moore at rawflow.com Wed Oct 26 16:54:14 2005 From: francis.moore at rawflow.com (Frank Moore) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> Message-ID: <435FB4B6.7070408@rawflow.com> Alen Peacock wrote: >Each node needs to maintain trust records of other nodes it interacts with. > > Alen, Actually, I only want to authenticate a node with the main server. There will be no authentication between nodes. Each node has to accept some initialisation information from the server, so it makes sense to do all the authentication at that point. Not sure if this makes things any easier? Cheers, F. From ap at hamachi.cc Wed Oct 26 16:56:22 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> Message-ID: <435FB536.4010205@hamachi.cc> Alen Peacock wrote: > Please poke holes if you see them: ... > I don't think this scheme is new, and it is a tad inefficient if done > for every operation. It's nearly as inefficient as it gets. It might be suitable for low traffic applications like instant messaging, and that's about it. You may want to look at how TLS, SSH and IPsec handle bulk traffic security - they all utilize symmetric encryption for this purpose and generate and use shared encryption and authentication keys. From alenlpeacock at gmail.com Wed Oct 26 19:49:35 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435FB536.4010205@hamachi.cc> References: <435E370B.4060807@rawflow.com> <435FB536.4010205@hamachi.cc> Message-ID: On 10/26/05, Alex Pankratov wrote: > > It's nearly as inefficient as it gets. It might be suitable for low > traffic applications like instant messaging, and that's about it. > You may want to look at how TLS, SSH and IPsec handle bulk traffic > security - they all utilize symmetric encryption for this purpose > and generate and use shared encryption and authentication keys. I won't argue about the inefficiency -- you are absolutely right. TLS, SSH, and IPsec all do bulk transfers far, far more efficiently. The purpose of the protocol I outlined is not for bulk traffic security - it is to verify the claimed identities of the participants in a completely decentralized fashion (though, to be fair, I didn't make that clear) before making the transfer, which can then be made either insecurely or securely using one of the methods you mentioned. I would also point out that there are a class of applications for which the noted inefficiency is amortized so as to not make too large of a difference (I don't think that IM is one of them). If the transfer stage moves a large amount of data over a higher-layer protocol, such as http, and if such transfers happen rarely (rarely defined as less often than the session timeout length), then the scheme is almost as efficient as any other -- there is an initial setup cost which is dwarfed by the amount of data which is moved as a result of the setup. Granted, this is still vulnerable to session hijacking, but that can be dealt with in any number of ways (including, if you want, using TLS / https instead of http). TLS, SSH, and IPsec don't solve the identity problem. If 'A' wants to participate in an overlay network where nodes are not only transient, but can migrate their identities from one machine to another, then the fact that the network is written using TLS doesn't really play into the decision of how much to trust node 'B' or node 'C'. As a matter of definition, 'B' and 'C' are default untrusted, and the fact that 'A' uses TLS to talk with 'B' and 'C' doesn't help 'A' increase its trust in either. The only way 'A' can increase trust in either 'B' or 'C' is by interacting with them, keeping some history of the results (trust), and then using that history to make future decisions about desirable and undesireable interactions. And the only way to make trust reliable is to ensure that imposters are unsuccessful -- that a node who says it is 'B' really is 'B'. Again, I'm not talking about session hijacking, I'm talking about long term identities and being able to prove that a node is who it says it is, without relying on a third party. Self-chosen assymetric keys provide a mechanism for accomplishing this, and I was just trying to outline one obvious and simple approach. Alen From alenlpeacock at gmail.com Wed Oct 26 19:55:15 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <1130345074.5978.4.camel@fsol> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> Message-ID: On 10/26/05, Antoine Pitrou wrote: > > > In other words, given a node 'A', a node 'B', and an attacker 'C', > > each with a public/private key pair (Au/Ar, Bu/Br, etc): > [snip] > > How do A and B know their counterpart's public keys for sure? > And if they do, then why reinvent the wheel? Traditional public key > signing works well for these cases. Both A and B make their public keys available upon request. Before interacting with B, A will have to obtain B's public key directly, and vice versa. This only needs to happen once. 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. > IOW, I think your problem is ill-defined. I'll go ahead and agree with you on this. I was projecting a problem I was thinking about onto the problem Frank was thinking about, and it is certainly true that my problems are not his problems :) Alen From solipsis at pitrou.net Wed Oct 26 20:01:23 2005 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> Message-ID: <1130356883.5978.47.camel@fsol> > Both A and B make their public keys available upon request. Before > interacting with B, A will have to obtain B's public key directly, and > vice versa. This only needs to happen once. > > Traditional public key signing doesn't work well if you want to > eliminate the central authority / trusted third party. Of course it does, since "both A and B make their public keys available upon request". You don't need a central source of authority if there is first a trusted channel by which the peers exchange their respective public keys. From v100 at braginskaya.net Wed Oct 26 22:35:47 2005 From: v100 at braginskaya.net (v100@braginskaya.net) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication Message-ID: <17582227.190151130366147404.JavaMail.servlet@kundenserver> Frank Moore: > I'm working on a hybrid p2p network where there is a central server and > lots of clients (peers). I need a way for clients to authenticate > themselves when they join the network. I've looked at doing a challenge > response type thing using Challenge Handshake Authentication Protocol > (CHAP) but that means putting a shared secret key in each client and > the server. How does a client qualify? What makes it eligible to participate? - You can give each one that does qualify (for whatever reasons) a unique number, a ticket. That's not a cryptographic key, but certainly you would want to make ticket generation impossible for adversaries. > It seems entirely possible that someone could reverse engineer the > client executable to get hold of the shared secret key and then write a > 'rogue' client (or server) to subvert the network? The attacker could create clones of the client he compromised, if every client has a unique id (or at least unique tickets). At least you could detect who gave up his identity. If tickets have limited lifetime, clients have to re-authenticate regularly. If your authentication is "out-of-band", you could be able to drop a few bad guys. Btw, have you looked at Kerberos? > Is there a standard (or any) way of authenticating peers in p2p > networks that doesn't require secret shared keys? That does depend on the property you want to authenticate, and on the nature of the principals you want to authenticate. Do you want to do age verification? Or do you want to make sure to deal with a human being? Or with a friend? In many cases you would need cryptographic keys, and a unique shared secret key between the server and each client is probably the easiest way to go. Cheers, Harald From zooko at zooko.com Wed Oct 26 21:24:24 2005 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> Message-ID: <20051026212425.03F781E0B@yumyum.zooko.com> > > 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 From kerry at vscape.com Thu Oct 27 13:52:57 2005 From: kerry at vscape.com (Kerry Bonin) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <20051026212425.03F781E0B@yumyum.zooko.com> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> Message-ID: <4360DBB9.4030805@vscape.com> 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 zooko@zooko.com 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 >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051027/3efb47ce/attachment.htm From alenlpeacock at gmail.com Thu Oct 27 14:45:52 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <4360DBB9.4030805@vscape.com> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> Message-ID: On 10/27/05, Kerry Bonin wrote: > I think some people are put off by the size and > complexity of the libraries involved, 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. Completely decentralized p2p applications have the advantage of being especially resilient to DoS and other attacks on centrality. Introducing centralized components negates this advantage. In the case of using CAs in a p2p app, the entire network can be disabled by attacking the CAs. p2p networks pose an interesting challenge because you have to design for the fact that malicious or misbehaving clients *will* be present. 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 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). Alen From alenlpeacock at gmail.com Thu Oct 27 14:54:16 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <20051026212425.03F781E0B@yumyum.zooko.com> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> Message-ID: On 10/26/05, zooko@zooko.com wrote: > > 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? Well, there are a number of *large*, highly centralized, hierarchical organizations which use it extensively :) (such as MIT for instance). But I don't know that it "works as intended" even for them -- usability, certificate management by users, etc. are all still big enough issues that I'd say it would be hard to argue with you on that point. Alen From kerry at vscape.com Thu Oct 27 15:22:55 2005 From: kerry at vscape.com (Kerry Bonin) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> Message-ID: <4360F0CF.3040608@vscape.com> In a p2p PKI, attacking the CA[s] does NOT take down the network, it only prevents new users from joining during the attack! There is also a simple way to harden against this - never publish the CA IPs to the network, only publish (D[s]HT) a list of current proxies that can access the CAs. Attacking the CAs then means attacking the proxies, and any known CA addresses. During an attack, it is possible to republish the proxy list. If your attackers are following the CA proxy list then you have a larger problem, but that can also be mitigated by exponentially increasing the active proxy list, which is simple if this proxy service is part of the peer protocol suite. This may expose more CA IPs via compromised nodes, but using a second layer of proxies selected by uptime or other trust metrics can further limit. It is also possible to use "honey pot" strategies to identify which proxies are leaking CA IPs. This approach, plus using a connect protocol that includes DDOS resistance like client puzzles, the attacker has quite a hard time taking down the CA's. There are more tricks, these are just some of my favorite... Alen Peacock wrote: >On 10/27/05, Kerry Bonin wrote: > > >>I think some people are put off by the size and >>complexity of the libraries involved, >> >> > > 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. > > Completely decentralized p2p applications have the advantage of >being especially resilient to DoS and other attacks on centrality. >Introducing centralized components negates this advantage. In the >case of using CAs in a p2p app, the entire network can be disabled by >attacking the CAs. > > p2p networks pose an interesting challenge because you have to >design for the fact that malicious or misbehaving clients *will* be >present. 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 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). > > Alen >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051027/e77b80d2/attachment.html From alenlpeacock at gmail.com Thu Oct 27 15:45:19 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <4360F0CF.3040608@vscape.com> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> <4360F0CF.3040608@vscape.com> Message-ID: On 10/27/05, Kerry Bonin wrote: > > There is also a simple way to harden against this - never publish the CA > IPs to the network, only publish (D[s]HT) a list of current proxies that can > access the CAs. Attacking the CAs then means attacking the proxies, and any > known CA addresses. During an attack, it is possible to republish the proxy > list. If your attackers are following the CA proxy list then you have a > larger problem, but that can also be mitigated by exponentially increasing > the active proxy list, which is simple if this proxy service is part of the > peer protocol suite. This may expose more CA IPs via compromised nodes, but > using a second layer of proxies selected by uptime or other trust metrics > can further limit. It is also possible to use "honey pot" strategies to > identify which proxies are leaking CA IPs. This approach, plus using a > connect protocol that includes DDOS resistance like client puzzles, the > attacker has quite a hard time taking down the CA's. There are more tricks, > these are just some of my favorite... Who controls the CA proxies in this scheme? If the "proxy service is part of the peer protocol suite" (I interpret this to mean that the proxies are just as untrusted as regular peers, or /are/ the regular peers), then you now have to worry about malicious and misbehaving proxies, which could provide an even bigger avenue of attack than the original set of CAs, no? I'm sure you've thought about this and probably have some countermeasures to mitigate these effects too, but I wonder if it doesn't start to look like a rabbit hole?... Alen From dcarboni at gmail.com Thu Oct 27 16:05:14 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> Message-ID: <71b79fa90510270905r639b1830l5e90fe0bba8495d2@mail.gmail.com> > > Completely decentralized p2p applications have the advantage of > being especially resilient to DoS and other attacks on centrality. > Introducing centralized components negates this advantage. In the > case of using CAs in a p2p app, the entire network can be disabled by > attacking the CAs. Not true. The CA is never contacted during p2p handshaking. It is defacto outside the network and it is supposed to sign a peer certificate only once in the lifetime of a peer. You can even drop a bomb on the CA and the network keeps working. The only side effect is that new peers that have not a certificate yet, cannot join. Nobody is disputing the advantages of decentralized network, but the use of a common well-reputed CA allows to build a certain level of trust in a p2p network which can be still completely decentralized regarding indexing, searching, and delivery of resources. My two cents. Bye -- I lose control 'cause I'm a creature of the night (Bruce and Bongo) -- http://people.crs4.it/dcarboni From alenlpeacock at gmail.com Thu Oct 27 17:17:24 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <71b79fa90510270905r639b1830l5e90fe0bba8495d2@mail.gmail.com> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> <71b79fa90510270905r639b1830l5e90fe0bba8495d2@mail.gmail.com> Message-ID: On 10/27/05, Davide Carboni wrote: > ...You can even drop a > bomb on the CA and the network keeps working. The only side effect is > that new peers that have not a certificate yet, cannot join. I'll concede this point to you and and Kerry willingly, for some classes of p2p networks. But for other classes, disabling new peers joining is almost as catastrophic as disabling the entire network -- certainly from a usability perspective, if this type of attack is common (which it will be if easy to mount), then this could be a major roadblock to adoption for users. As an example, imagine a well-healed adversary (such as the RIAA) disabling a p2p filesharing application by attacking its CAs. If your new users are not persistent, they'll get turned away and not come back. And from the p2p churn studies I've seen, you get a lot of "new users." Again, may not apply to all p2p networks. Alen From PaulLambert at AirgoNetworks.Com Thu Oct 27 17:34:35 2005 From: PaulLambert at AirgoNetworks.Com (Paul Lambert) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] RE: P2P Authentication Message-ID: <3FFBC907DD03A34CA4410C5C745DEB12084EED9D@wnimail.WoodsideNet.Com> > > 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 I'm not a big fan anymore of x.509 ... but with difficulty it does work. There are very large Government installations, MS code signing uses PKI, TLS and browsers use PKI (but poorly). P2P systems, at least 'Real P2P'(tm), has no use for a single central authority. Having every peer maintain their own trust hierarchy is viable. It's the forest model versus a single tree model. Paul From bmukherj at shoshin.uwaterloo.ca Thu Oct 27 18:23:09 2005 From: bmukherj at shoshin.uwaterloo.ca (Roop Mukherjee) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> Message-ID: One may argue that 'pure' P2P authentication would not have traditional PKI like trusted CAs simply because that would mean some nodes are inherently more trusted than others. What you would want in P2P authentication would be some way in which all nodes start off as equals but through subsequent rounds of protocol or through added context build trust that would allow authentication. Some sort of reputation system (like http://ccs.mit.edu/dell/reputation.html) with persistence would be useful. In my opinion a practical solution would involve a combination of asymmetric key cryptography and reputation system, where all CA's are treated as fallible nodes but can build their reputations. -- Roop __________________________________________________________ www.shoshin.uwaterloo.ca/~bmukherj On Thu, 27 Oct 2005, Alen Peacock wrote: > On 10/27/05, Kerry Bonin wrote: >> I think some people are put off by the size and >> complexity of the libraries involved, > > 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. > > Completely decentralized p2p applications have the advantage of > being especially resilient to DoS and other attacks on centrality. > Introducing centralized components negates this advantage. In the > case of using CAs in a p2p app, the entire network can be disabled by > attacking the CAs. > > p2p networks pose an interesting challenge because you have to > design for the fact that malicious or misbehaving clients *will* be > present. 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 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). > > Alen > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From kerry at vscape.com Fri Oct 28 01:43:33 2005 From: kerry at vscape.com (Kerry Bonin) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> <4360F0CF.3040608@vscape.com> Message-ID: <43618245.8020808@vscape.com> Misbehaving CA proxies present no threat other than revealing of the CA IPs, as any peer can know immediately if a CA is valid by examining its certificate or the trust chain of an issued cert. If the list of trusted roots is distributed w/ the original application, or if the CAs derive from an OS installed trusted root, it is impossible to impersonate one without first obtaining the private keys of one of the CAs. That's why I like using a PKI w/ p2p - the only real attack vector is against the CAs, and there are ways to hide them well (onion routing). Legal attacks would have to shut down all CAs to take down the network, which remains possible. I'm not architecting my system for file sharing, I'm actually building MMORPG infrastructure, so the legal attack is less of an issue for me, I'm focusing on technical attacks. Alen Peacock wrote: >On 10/27/05, Kerry Bonin wrote: > > >> There is also a simple way to harden against this - never publish the CA >>IPs to the network, only publish (D[s]HT) a list of current proxies that can >>access the CAs. Attacking the CAs then means attacking the proxies, and any >>known CA addresses. During an attack, it is possible to republish the proxy >>list. If your attackers are following the CA proxy list then you have a >>larger problem, but that can also be mitigated by exponentially increasing >>the active proxy list, which is simple if this proxy service is part of the >>peer protocol suite. This may expose more CA IPs via compromised nodes, but >>using a second layer of proxies selected by uptime or other trust metrics >>can further limit. It is also possible to use "honey pot" strategies to >>identify which proxies are leaking CA IPs. This approach, plus using a >>connect protocol that includes DDOS resistance like client puzzles, the >>attacker has quite a hard time taking down the CA's. There are more tricks, >>these are just some of my favorite... >> >> > > Who controls the CA proxies in this scheme? If the "proxy service >is part of the peer protocol suite" (I interpret this to mean that the >proxies are just as untrusted as regular peers, or /are/ the regular >peers), then you now have to worry about malicious and misbehaving >proxies, which could provide an even bigger avenue of attack than the >original set of CAs, no? I'm sure you've thought about this and >probably have some countermeasures to mitigate these effects too, but >I wonder if it doesn't start to look like a rabbit hole?... > > Alen >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051027/89e37d04/attachment.htm From lgonze at panix.com Fri Oct 28 02:13:05 2005 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <43618245.8020808@vscape.com> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> <20051026212425.03F781E0B@yumyum.zooko.com> <4360DBB9.4030805@vscape.com> <4360F0CF.3040608@vscape.com> <43618245.8020808@vscape.com> Message-ID: <43618931.7020709@panix.com> Kerry Bonin wrote: > Misbehaving CA proxies present no threat other than revealing of the > CA IPs, as any peer can know immediately if a CA is valid by examining > its certificate or the trust chain of an issued cert. If the list of > trusted roots is distributed w/ the original application, or if the > CAs derive from an OS installed trusted root, it is impossible to > impersonate one without first obtaining the private keys of one of the > CAs. If CAs are willing to issue new certs on demand and the goal is detecting attackers, a CA-signed certificate is the same as a self-signed one. From matthew at matthew.at Fri Oct 28 02:17:39 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E370B.4060807@rawflow.com> Message-ID: <200510280215.j9S2FiU14582@where.matthew.at> Frank Moore: > > Is there a standard (or any) way of authenticating peers in > p2p networks that doesn't require secret shared keys? > 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'?" The answer is essentially no, with one exception, though you can make it hard... Typical solutions to this problem are "a secret key (or keys) compiled in to the peer" and/or "hashing part of the executable code on demand" (which is just using the code itself as the key), but the problem is that if someone reverse-engineers (or you publish) the protocol or reverse-engineers (or you publish source to) the software, something that emulates any challenge-response can be built... At the extreme, they can run your software in the background, feeding it the challenges and using it to generate the responses for their client, or simply figure out what is being used as the data that is mixed with the challenge to produce the response. Using the code itself has the advantage that someone trying to "cheat" has to either drag along a copy of your code (and copyright law would apply in that case) or convince the user to install your good code as well. 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". The followup discussion about public key infrastructure, while interesting, is generally not relevant to your problem... In order to authenticate itself, the client would need to have a private key, and that's exactly the same problem as protecting a secret symmetric key from reverse engineering. Matthew Kaufman matthew@matthew.at www.amicima.com From matthew at matthew.at Fri Oct 28 02:28:53 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: Message-ID: <200510280226.j9S2QwU14620@where.matthew.at> 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 matthew@matthew.at www.amicima.com From matthew at matthew.at Fri Oct 28 02:39:23 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <435E4F19.4090104@vscape.com> Message-ID: <200510280237.j9S2bSU14661@where.matthew.at> Kerry Bonin: > Another nice thing about certs is that you don't have to use SSL - if you still want > a UDP based protocol, just use the cert to sign your key exchange, then use a stream > cipher that can live w/ dropped packets. I've got a simple protocol for this I need to > turn into an RFC and publish as open source, just too many other items in front of it at > the moment... You could also look at an existing implementation of a network protocol stack that provides this type of security; unreliable, partially-reliable and fully-reliable flows with shared congestion control; and other useful features like NAT traversal (all on top of UDP) at our website: http://www.amicima.com/developers/downloads.html It is GPL'd, so the source is right there if you want to see an example of how to do this, or just use our stack yourself. Matthew Kaufman matthew@matthew.at www.amicima.com From mfreed at cs.nyu.edu Fri Oct 28 13:26:24 2005 From: mfreed at cs.nyu.edu (Michael J. Freedman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Non-transitivity in DHTs Message-ID: Hi, At the risk of changing the active topic of DHTs and authentication, I wanted to point out a recent paper that we've just posted, which will appear at the upcoming WORLDS '05: Non-Transitive Connectivity and DHTs M. J. Freedman, K. Lakshminarayanan, S. Rhea, and I. Stoica http://www.scs.stanford.edu/mfreed/docs/ntr-worlds05.pdf While DHT algorithms seem quite elegant on paper, in practice we found that a great deal of our implementation effort was spent discovering and fixing problems caused by non-transitivity. Of course, maintaining a full link-state routing table at each DHT node would have sufficed to solve all such problems, but would also require considerably more bandwidth than a basic DHT. Instead, we each independently discovered a set of "hacks" to cover up the false assumption of full connectivity on which DHTs are based. Collectively, the authors have produced three independent DHT implementations: the Bamboo implementation in OpenDHT, the Chord implementation in i3, and the Kademlia implementation in Coral. Moreover, we have run public deployments of these three DHTs on PlanetLab for over a year. In this paper, we categorize the ways in which Bamboo, Chord, and Kademlia break down under non-transitivity, and we enumerate the ways we modified them to cope with these shortcomings. We also discuss application-level solutions to the problem. Many of these failure modes and fixes were quite painful for us to discover, and we hope that-at least in the short term-this work will save others the effort. In the longer term, we hope that by focusing attention on the problem, we will encourage future DHT designers to tackle non-transitivity head-on. ----- Beyond communicating these details to the development community, we had hoped to engender further discussion on how other DHT designers and implementors have dealt with similar problems and on what techniques should be used to avoid such limitations in the future. Thanks, --mike ----- www.michaelfreedman.org www.coralcdn.org From coderman at gmail.com Fri Oct 28 18:00:53 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Non-transitivity in DHTs In-Reply-To: References: Message-ID: <4ef5fec60510281100t62c2c399o27701babccef2d9@mail.gmail.com> On 10/28/05, Michael J. Freedman wrote: > ... > Beyond communicating these details to the development community, we had > hoped to engender further discussion on how other DHT designers and > implementors have dealt with similar problems and on what techniques > should be used to avoid such limitations in the future. i've found a number of the ad-hoc routing protocol / wireless mesh routing protocols[1] to be useful with regards to non-transitivity and decentralized networking in general. at the application level we are comfortable with easy promises of flow controlled streams between peers; lower level routing protocols get no such easy service. for example, some protocols utilize unidirectional links for distribution of route state even though such a link is not useful for transport (lacking bidirectional communication). the wireless protocols offer interesting uses of a true broadcast transport that are particularly relevant to fully decentralized peer networks. the real crux of the problem is reputation (and strong identity to bind reputation to, regarding the previous thread). for this reason i think DHT's will work best using smaller groups of peers which are known rather than larger groups of unknown and untrustworthy peers. [for example, coordinated attacks against DHT state using multiple malicious nodes; it is extremely hard to protect against this in a DHT] [1] http://en.wikipedia.org/wiki/Ad_hoc_protocol_list From alenlpeacock at gmail.com Fri Oct 28 18:38:14 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <1130345074.5978.4.camel@fsol> References: <435E370B.4060807@rawflow.com> <1130345074.5978.4.camel@fsol> Message-ID: On 10/26/05, Antoine Pitrou wrote: > > How do A and B know their counterpart's public keys for sure? > And if they do, then why reinvent the wheel? Traditional public key > signing works well for these cases. I wanted to revisit this, since I didn't address it previously. Signing alone is insufficient for identity verification due to replay attacks. You could use a nonce, but then the recipient has to guarantee that no nonce is ever reused, which usually reduces either to a massive database lookup problem, or a clock synchronization problem -- neither of which are easily solvable in an untrusted p2p environment (let alone in a trusted network application, where suppress-replay attacks are likely still possible). Of course, if you aren't worried about replay attacks (and certainly the severity of such attacks varies widely depending on the protocol), then this isn't an issue and you might be able to get by with simple signatures. As far as I can tell, the rudimentary scheme I outlined previously eliminates man-in-the-middle and replay attacks using challenge/response, but it does introduce a certain amount of hand-shaking overhead. (there is actually still one replay attack possible by a man-in-the-middle in what I sketched, but it is solvable by withholding Ra until the data response is sent, and signing it as part of that payload). Expensive for short messages? yeah. But it doesn't require any centrality. Alen From matthew at matthew.at Fri Oct 28 20:57:58 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: Message-ID: <200510282056.j9SKu4U19818@where.matthew.at> Alen Peacock: > Signing alone is insufficient for identity verification due > to replay attacks. You could use a nonce, but then the > recipient has to guarantee that no nonce is ever reused, > which usually reduces either to a massive database lookup > problem, or a clock synchronization problem -- neither of > which are easily solvable in an untrusted p2p environment > (let alone in a trusted network application, where > suppress-replay attacks are likely still possible). Actually the only two things that are required to protect against reply are: 1) if A wants to know that B is who he says he is, then A has to choose the nonce that B signs 2) when A chooses the nonce, A needs to choose a nonce that hasn't been used previously with a probability sufficient to make A "certain enough" that B is who he says he is. The probability in #2 should be of the same order as the certainty that the signature itself is valid, and since signature collision is the collision problem for the hash algorithm in use, you can calculate those odds to determine the number of strongly random bits required for the nonce. Matthew Kaufman matthew@matthew.at www.amicima.com Ps. The important thing is to remember what you're actually protecting against when you implement cryptographic security... And more important, that all you're doing is shifting what the easiest attack vector is. Encrypted P2P VOIP just reduces the market for network sniffers and increases the market for concealable voice bugs, after all... It doesn't mean nobody can hear what you're saying. From dbarrett at quinthar.com Sun Oct 30 20:54:35 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art References: <1130705315.2E8D17C1@bb12.dngr.org> Message-ID: <1130705681.9817024@dl11.dngr.org> We've talked at length about massively scalable file transfer, but we've generally presumed fixed-length, pre-recorded files (ie, the file is available in entirety before sharing). I'm curious if you have experience or ideas around "live" streaming of content simultaneous to its recording/creation. Clearly, this isn't a new field, and streaming architectures abound. But while there has been extensive innovation in file sharing (DHTs, merkle trees, swarming downloads), I haven't heard much innovation with live streaming content. So far as I know (but I'm asking you to prove me wrong), the state of the art in audio/video streaming is still a classic "hierarchy of repeaters", where the broadcaster sends to N receivers, each of which sends to N receivers, and so on. There are obvious variations on this theme (adaptive fan out, topology optimizations, re-request of dropped data, jitter buffers, etc) but I'm looking for the next major innovation (such as was taken between Napster and Gntella for file sharing). With this in mind, do you know of any proven techniques (or new research) in grid/swarming delivery of live video? Which research, projects, or products would you say are demonstrating the state of the art in scalable, adaptive, high-quality video streaming? -david From mgp at ucla.edu Sun Oct 30 21:13:12 2005 From: mgp at ucla.edu (Michael Parker) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art In-Reply-To: <1130705681.9817024@dl11.dngr.org> References: <1130705315.2E8D17C1@bb12.dngr.org> <1130705681.9817024@dl11.dngr.org> Message-ID: <20051030131312.malnj73y8w4ow0o8@mail.ucla.edu> Hi David, Recently I came across CoolStreaming at http://www.cs.sfu.ca/~jcliu/Papers/CoolStreaming.pdf, which actually utilizes a swarming algorithm with aggressive scheduling to deliver content, as opposed to the traditional multicast tree you cite. As for being "proven", in the academic paper there they cite that they've had up to 4000 users simultaneously use their prototype implementation. That was in 2004; from what I have heard, this then went on to be commercialized, simply streaming live feeds straight from television networks. This didn't go over so well with the networks, which then shut the venture down, and now the commercialized project remains in limbo. It was mainly popular in Europe, used to stream feeds of soccer games live. (This is all again hearsay -- if any Europeans could set the record straight, that would be nice. In the meantime, Google "coolstreaming" to see its remnants.) I think a few months back I actually e-mailed the paper authors, trying to get the Python prototype they used on PlanetLab... I didn't get a response, perhaps I should try again. - Mike Quoting David Barrett : > We've talked at length about massively scalable file transfer, but > we've generally presumed fixed-length, pre-recorded files (ie, the > file is available in entirety before sharing). I'm curious if you > have experience or ideas around "live" streaming of content > simultaneous to its recording/creation. > > Clearly, this isn't a new field, and streaming architectures abound. > But while there has been extensive innovation in file sharing (DHTs, > merkle trees, swarming downloads), I haven't heard much innovation > with live streaming content. > > So far as I know (but I'm asking you to prove me wrong), the state of > the art in audio/video streaming is still a classic "hierarchy of > repeaters", where the broadcaster sends to N receivers, each of which > sends to N receivers, and so on. There are obvious variations on > this theme (adaptive fan out, topology optimizations, re-request of > dropped data, jitter buffers, etc) but I'm looking for the next major > innovation (such as was taken between Napster and Gntella for file > sharing). > > With this in mind, do you know of any proven techniques (or new > research) in grid/swarming delivery of live video? Which research, > projects, or products would you say are demonstrating the state of > the art in scalable, adaptive, high-quality video streaming? > > -david > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From matthew at matthew.at Sun Oct 30 21:45:44 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art In-Reply-To: <1130705681.9817024@dl11.dngr.org> Message-ID: <200510302143.j9ULhqU31605@where.matthew.at> I assume you've already seen and surveyed the current "state of the art" in running application-level-multicast projects like: CMU's ESM http://esm.cs.cmu.edu/ SCRIBE SplitStream Bayeux And papers on pbcast, lpbcast, and bimodal-multicast, which while assuming an existing unreliable multicast transport, give some insight as to how to improve the application-level performance. We have work in this area in progress here at amicima as well, but no promises of release dates or capabilities yet. Matthew Kaufman matthew@matthew.at www.amicima.com From vyzo at media.mit.edu Sun Oct 30 23:48:58 2005 From: vyzo at media.mit.edu (Dimitris Vyzovitis) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art In-Reply-To: <1130705681.9817024@dl11.dngr.org> Message-ID: On Sun, 30 Oct 2005, David Barrett wrote: > With this in mind, do you know of any proven techniques (or new > research) in grid/swarming delivery of live video? Which research, > projects, or products would you say are demonstrating the state of the > art in scalable, adaptive, high-quality video streaming? You might be interested in VidTorrent, which is a protocol we are working on for real time video streaming (the name is more of a tribute to BitTorrent, than anything else. We are simply using similar ideas and we write in python, but other than that it doesnt have much to do with bt). http://viral.media.mit.edu/index.php?page=vidtorrent We are in early prototype stage, as in it works inside the lab and we can demo it. We are planning to release the code under the GNU GPL in early December, but we have already released Peers, the low level distributed programming environment that we use to develop it. You can check it out at http://viral.media.mit.edu/peers Feel free to contact me or ibmirkin@gmail.com directly if you are interested in it. There are no papers yet, we'll do that after we get the code out. -- vyzo From cefn.hoile at bt.com Mon Oct 31 04:04:55 2005 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art Message-ID: <91A1302378CDCE41A2B8229D0BA7E5D576CF53@I2KM11-UKBR.domain1.systemhost.net> In contrast to the single-source, multiple recipients model, tvoon in Germany have been exploring a multiple-source, multiple recipients model for live streams. Where live streams are distributed by a broadcaster they are then decodable at multiple locations (e.g. satellite and digital TV DVB cards). These locations can cooperate to provide an always-on service to relay the signal regardless of your reception of the original RF. As with many of these projects I understand they ran into some issues around copyright, and I don't know how these panned out in the end. http://www.tvoon.de/ctv/ BT's also got some activities in the P2P multicast space, including Dimitris' work on VidTorrent (BT Fellow at the MIT Media Lab). Hoping to develop a broader collaboration to trial ESM, VidTorrent and other multicast frameworks. Would welcome suggestions for other systems which we should be looking at. Cefn http://cefn.com BT Labs http://labs.bt.com -----Original Message----- From: p2p-hackers-bounces@zgp.org on behalf of David Barrett Sent: Sun 10/30/2005 8:54 PM To: p2p-hackers@zgp.org Subject: [p2p-hackers] Live P2P Video State of the Art We've talked at length about massively scalable file transfer, but we've generally presumed fixed-length, pre-recorded files (ie, the file is available in entirety before sharing). I'm curious if you have experience or ideas around "live" streaming of content simultaneous to its recording/creation. Clearly, this isn't a new field, and streaming architectures abound. But while there has been extensive innovation in file sharing (DHTs, merkle trees, swarming downloads), I haven't heard much innovation with live streaming content. So far as I know (but I'm asking you to prove me wrong), the state of the art in audio/video streaming is still a classic "hierarchy of repeaters", where the broadcaster sends to N receivers, each of which sends to N receivers, and so on. There are obvious variations on this theme (adaptive fan out, topology optimizations, re-request of dropped data, jitter buffers, etc) but I'm looking for the next major innovation (such as was taken between Napster and Gntella for file sharing). With this in mind, do you know of any proven techniques (or new research) in grid/swarming delivery of live video? Which research, projects, or products would you say are demonstrating the state of the art in scalable, adaptive, high-quality video streaming? -david _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4154 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20051031/ea42fc4f/attachment.bin From dbarrett at quinthar.com Mon Oct 31 08:11:37 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art In-Reply-To: <91A1302378CDCE41A2B8229D0BA7E5D576CF53@I2KM11-UKBR.domain1.systemhost.net> References: <91A1302378CDCE41A2B8229D0BA7E5D576CF53@I2KM11-UKBR.domain1.systemhost.net> Message-ID: <4365D1B9.1020206@quinthar.com> cefn.hoile@bt.com wrote: > In contrast to the single-source, multiple recipients model, tvoon in > Germany have been exploring a multiple-source, multiple recipients > model for live streams. Ahh, interesting, do you have any links to more technical information on how it works? The website stays fairly high level. I like the idea of multiple sources / multiple recipients, but I'm curious if the complexity pays for itself in the real world. For example: - Can a node simultaneously receive and broadcast the same stream, or need I receive the whole thing before I broadcast? - Are the streams "live" in the sense that they have no predefined length, or is it merely "streaming" pre-recorded (fixed-length) video? - How does a node splice feeds from multiple sources together in realtime to produce a single unified feed for playback? Basically, is anyone doing anything like this, is it possible, and is it worth the effort? -david From gwendal.simon at gmail.com Mon Oct 31 09:20:56 2005 From: gwendal.simon at gmail.com (Gwendal Simon) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Live P2P Video State of the Art In-Reply-To: References: Message-ID: <4365E1F8.3050705@gmail.com> The following page may be of interest for you: http://pulse.netofpeers.net/wiki/index.php/Publications In his master thesis document, Fabio makes a rigorous bibliographic work on P2P live streaming. He also gives some hints of the system he is currently conceiving. This project, namely Pulse, considers live "infinite" data streams, very sensitive to delay. In the "netofpeers" initiative, such studies usually result in free python softwares (see Solipsis and Maay). Obviously, comments are welcomed ! -------------------------------------- Gwendal Simon http://solipsis.netofpeers.net David Barrett wrote: > cefn.hoile@bt.com wrote: > > In contrast to the single-source, multiple recipients model, tvoon in > > Germany have been exploring a multiple-source, multiple recipients > > model for live streams. > > Ahh, interesting, do you have any links to more technical information on > how it works? The website stays fairly high level. I like the idea of > multiple sources / multiple recipients, but I'm curious if the > complexity pays for itself in the real world. For example: > > - Can a node simultaneously receive and broadcast the same stream, or > need I receive the whole thing before I broadcast? > > - Are the streams "live" in the sense that they have no predefined > length, or is it merely "streaming" pre-recorded (fixed-length) video? > > - How does a node splice feeds from multiple sources together in > realtime to produce a single unified feed for playback? > > Basically, is anyone doing anything like this, is it possible, and is it > worth the effort? > > -david > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From francis.moore at rawflow.com Mon Oct 31 13:05:33 2005 From: francis.moore at rawflow.com (Frank Moore) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <200510280215.j9S2FiU14582@where.matthew.at> References: <200510280215.j9S2FiU14582@where.matthew.at> Message-ID: <4366169D.5030104@rawflow.com> 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. From francis.moore at rawflow.com Mon Oct 31 13:12:51 2005 From: francis.moore at rawflow.com (Frank Moore) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Testing scalability on a P2P network Message-ID: <43661853.7000609@rawflow.com> Hi, Can anyone give me some pointers on scalability testing a P2P network? In theory if a P2P network works with N users, it should be possible to scale up to larger numbers i.e. N*10, N*100 etc.... But is there any way of actually testing this and if so how have other people done it? Thanks, Frank. From kerry at vscape.com Mon Oct 31 15:25:20 2005 From: kerry at vscape.com (Kerry Bonin) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] P2P Authentication In-Reply-To: <4366169D.5030104@rawflow.com> References: <200510280215.j9S2FiU14582@where.matthew.at> <4366169D.5030104@rawflow.com> Message-ID: <43663760.2060204@vscape.com> 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 > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > From gbildson at limepeer.com Mon Oct 31 15:57:06 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Testing scalability on a P2P network In-Reply-To: <43661853.7000609@rawflow.com> Message-ID: Run it in the wild with a few million users and see if network performance degrades. ;-) Seriously, sometimes that is what you have to do. Obviously, some beta testing can help but it is not true that certain features can scale indefinitely. You need to make your app have limits that it won't go beyond. For example, you can't hold 1 million alternate locations in memory for a file in a file sharing network. You certainly can't ping them all via UDP. Being able to remotely turn off some features or settings (again with boundary limits) can be useful. There are some fancy simulators around for basic testing. Thanks -greg > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of Frank Moore > Sent: Monday, October 31, 2005 8:13 AM > To: Peer-to-peer development. > Subject: [p2p-hackers] Testing scalability on a P2P network > > > Hi, > > Can anyone give me some pointers on scalability testing a P2P network? > In theory if a P2P network works with N users, it should be possible to > scale up to larger numbers i.e. N*10, N*100 etc.... > But is there any way of actually testing this and if so how have other > people done it? > > Thanks, > Frank. > > > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From faried at gmail.com Mon Oct 31 21:04:38 2005 From: faried at gmail.com (Faried Nawaz) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Testing scalability on a P2P network In-Reply-To: <43661853.7000609@rawflow.com> References: <43661853.7000609@rawflow.com> Message-ID: <4065dd020510311304w5bd3de37p225e499684fbce94@mail.gmail.com> On 10/31/05, Frank Moore wrote: > Can anyone give me some pointers on scalability testing a P2P network? > In theory if a P2P network works with N users, it should be possible to > scale up to larger numbers i.e. N*10, N*100 etc.... > But is there any way of actually testing this and if so how have other > people done it? Will a simulation help? There's p2psim -- http://pdos.csail.mit.edu/p2psim/ From alenlpeacock at gmail.com Mon Oct 31 22:14:15 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:03 2006 Subject: [p2p-hackers] Non-transitivity in DHTs In-Reply-To: References: Message-ID: On 10/28/05, Michael J. Freedman wrote: > Hi, > > At the risk of changing the active topic of DHTs and authentication, I > wanted to point out a recent paper that we've just posted, which will > appear at the upcoming WORLDS '05: > > Non-Transitive Connectivity and DHTs > M. J. Freedman, K. Lakshminarayanan, S. Rhea, and I. Stoica > http://www.scs.stanford.edu/mfreed/docs/ntr-worlds05.pdf Mike, This is a really nice paper, as it points out some problems that are non-obvious to those of us in early stages of implementing DHTs (without yet a lot of experience running them in large environments). For example, I've implemented a version of the Kademlia DHT based on the original paper. From your paper, I gather that I don't need to worry about routing loops or broken return paths. I do need to make minor mods to deal with invisible nodes (unreachable cache and eliminate blind trust). I'm not sure if I fully understand inconsistent roots as it relates to kademlia. Parallel iterative queries seem to make the probability of getting an incorrect response from inconsistent roots less severe, and implementing some sort of simple consensus easy -- since S directs the routing process, it can compare the results from multiple responses. Does that seem right, or am I overlooking something more essential to the problem? Alen