From elathan at ics.forth.gr Mon Aug 1 10:34:41 2005 From: elathan at ics.forth.gr (Elias Athanasopoulos) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Gnutella Simulator In-Reply-To: References: Message-ID: Hello! On Sun, 31 Jul 2005, Aaron Harwood wrote: > We are just about to release a package called VPDNS which, among other > things, will provide instructions for applying the gnutella patches > to pdns-2.27. It will be very interesting. Do you plan to announce it, when it's ready, via p2p-hackers@zgp.org? Regards, -- Elias Athanasopoulos Distributed Computing Systems (DCS) Institute of Computer Science (ICS/FORTH) Heraklion, Crete A bug can become a feature by documenting it. From chris at chris-edwards.org Mon Aug 1 13:01:28 2005 From: chris at chris-edwards.org (Chris Edwards) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Gnutella Simulator In-Reply-To: References: Message-ID: <42EE1D28.1070902@chris-edwards.org> Elias Athanasopoulos wrote: > Hello! > > On Sun, 31 Jul 2005, Aaron Harwood wrote: > >>We are just about to release a package called VPDNS which, among other >>things, will provide instructions for applying the gnutella patches >>to pdns-2.27. > > > It will be very interesting. Do you plan to announce it, when it's > ready, via p2p-hackers@zgp.org? Absolutely, you'll hear about it here! Expect something in a couple of days. -- Chris Edwards http://www.chris-edwards.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050801/5796879e/signature.pgp From gbildson at limepeer.com Mon Aug 1 15:49:21 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] UDP file transfer link speed identification In-Reply-To: <42EB130B.6070906@quinthar.com> Message-ID: > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of David Barrett > Sent: Saturday, July 30, 2005 1:42 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] UDP file transfer link speed identification > > > Greg Bildson wrote: > > This certainly worked but suffered from fairly poor performance given > > that there is an ack for each packet. > > Thanks for the overview, Greg, I understand now. But I'm curious about > your ack/packet performance statement. Do you mean it consumes an > unnecessary amount of upstream bandwidth, or do you mean it actually > obtrains lower throughput? > Our acks were consuming ~ 10% of upstream bandwidth before we started reducing them. That is partially due to some message padding overhead that I didn't mention which adds to each messages size. Thanks -greg From chris at chris-edwards.org Wed Aug 3 07:41:56 2005 From: chris at chris-edwards.org (Chris Edwards) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Release of VPDNS Message-ID: <42F07544.1070506@chris-edwards.org> Hi All, I'm pleased to announce the first release of our network simulation tool, VPDNS. VPDNS stands for Virtualisation for PDNS, and is some modifications to the well-known network simulator, PDNS, which is in turn built on NS2. A separate library is also supplied, to attach applications to the simulator. VPDNS allows you to run simulations using real applications. The network traffic generated by applications is transparently captured by our library, and sent over the simulated network. Both the simulator (actually, patches against standard NS) and the library can be downloaded at: http://p2p.cs.mu.oz.au/software/vpdns/ You will need to follow the patching instructions given - they're a little more complicated than we'd like, since we haven't been able to clarify the licensing of the other patches we use. The compilation of the library should be straightforward. Please note this is still a work-in-progress, and has not been widely tested. However we welcome feedback and contributions. The software is made available under a BSD style license. Some current limitations: - No UDP support (but we welcome patches!) - A slight problem in handling of select(2) in some cases - fork/exec don't work (but it is thread-safe) We'll soon have a program to generate scripts (for large networks) and some example scripts. Please don't hesitate to email me at caedwa@cs.mu.OZ.AU if you have any problems - as I said, it's still being worked on, so we want to fix any bugs you find! -- Chris Edwards http://www.chris-edwards.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050803/02c9a301/signature.pgp From eugen at leitl.org Wed Aug 3 09:30:46 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] [jrandom@i2p.net: [i2p] weekly status notes [aug 2]] Message-ID: <20050803093046.GE2259@leitl.org> ----- Forwarded message from jrandom ----- From: jrandom Date: Tue, 2 Aug 2005 13:44:48 -0700 To: i2p@i2p.net Subject: [i2p] weekly status notes [aug 2] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, belated notes today, * Index: 1) 0.6 status 2) PeerTest 3) SSU introductions 4) I2PTunnel web interface 5) mnet over i2p 6) ??? * 1) 0.6 status As you've all seen, we pushed out the 0.6 release a few days ago, and on the whole, things have been going fairly well. Some of the transport improvements since 0.5.* have exposed issues with the netDb implementation, but fixes for much of that is in testing now (as the 0.6-1 build) and will be deployed as 0.6.0.1 fairly shortly. We've also run into some problems with different NAT and firewall setups, as well as MTU issues with some users - issues that weren't present in the smaller test network due to fewer testers. Workarounds have been added in for the worst offenders, but we've got a long term solution coming up soon - peer tests. * 2) PeerTest With 0.6.1, we're going to deploy a new system to collaboratively test and configure the public IPs and ports. This is integrated within the core SSU protocol and will be backwards compatible. Essentially what it does is lets Alice ask Bob what her public IP and port number is, and then in turn have Bob get Charlie to confirm her proper configuration, or to find out what the limitation preventing properation is. The technique is nothing new on the net, but is a new addition to the i2p codebase and should remove most common configuration error. * 3) SSU introductions As described in the SSU protocol spec, there is going to be functionality to let people behind firewalls and NATs participate fully in the network, even if they couldn't otherwise receive unsolicited UDP messages. It won't work for all potential situations, but will address most. There are similarities between the messages described in the SSU spec and the messages necessary for the PeerTest, so perhaps when the spec is be updated with those messages, we'll be able to piggyback the introductions with the PeerTest messages. In any case, we'll deploy these introductions in 0.6.2, and that too will be backwards compatible. * 4) I2PTunnel web interface Some people have noticed and filed reports regarding various quirks on the I2PTunnel web interface, and smeghead has started putting together the fixes necessary - perhaps he can explain those updates in more detail, as well as an ETA on those? * 5) mnet over i2p While I haven't been around on the channel when the discussions were going on, from reading the logs it seems icepick has been doing some hacking to get mnet running on top of i2p - allowing the mnet distributed data store to offer resilient content publishing with anonymous operation. I don't know too much about the progress on this front, but it sounds like icepick is making good progress tying in with I2P through SAM and twisted, but perhaps icepick can fill us in further? * 6) ??? Ok, lots more going on than the above, but I'm already running late so I suppose I should stop typing and push this message out there. I'll be able to get online for a bit this evening, so if anyone is around we could have a meeting around 9:30p or so (whenever you get this ;) in #i2p on the usual irc servers {irc.duck.i2p, irc.postman.i2p, irc.freenode.net, irc.metropipe.net}. Thanks for your patience and help moving things forward! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC7+LCWYfZ3rPnHH0RAimUAJ9gMqGtl6huPkIkd8P1prbkSqrdpQCdF8L+ jRueb/0QtxGouKlYVM6C1Ms= =LRI4 -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050803/702ba922/attachment.pgp From aconrad.tlv at magic.fr Thu Aug 4 15:30:53 2005 From: aconrad.tlv at magic.fr (Alexandre CONRAD) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P in Python and file synchronization Message-ID: <42F234AD.2010705@magic.fr> Hello, I'm new to P2P. I very much like the concept of P2P decentralization and the part about "hashing" the files (cut a file in chunks so the propagation of the file starts when the 1st chunk is transfered to the next client, not having to wait for the full file to be completed). I'm thinking about using P2P for the management of my 250 PCs I have to keep up-to-date. So the P2P application I'm looking for would be able to: - connect to a server (which puts clients in relation and keeps track of the shared files maybe using XML-RPC for keeping a journal of available files ?) using a login/password. - synchronize files between clients automaticly. So when a client comes up with a new file(or changed/updated), other clients would automaticly start downloading that file and propagating it to other clients until all clients have that new file. - crypt while exchanging files. - handle file hashing. - handle users/groups so a client can be part of a group and only download files in which it's interested into. - use simple command line (eg. ./p2p_client.py :@:) and start sharing/synchronizing. Such an application would allow me to keep my 250 PCs network (and growing) up-to-date with the latest file versions without worrying about "who is up-to-date and who's not ?". And I want a P2P system (not FTP or similar) because I don't have much bandwidth. So I though maybe someone here could gimme some ideas about what's already existing in that open source jungle and what I could start with. Thanks for the hints ! ;) Regards, -- Alexandre CONRAD - TLV Research & Development tel : +33 1 30 80 55 05 fax : +33 1 30 80 55 06 6, rue de la plaine 78860 - SAINT NOM LA BRETECHE FRANCE From Arnaud.Legout at sophia.inria.fr Thu Aug 4 16:12:35 2005 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P in Python and file synchronization In-Reply-To: <42F234AD.2010705@magic.fr> References: <42F234AD.2010705@magic.fr> Message-ID: <42F23E73.8050700@sophia.inria.fr> Hi Alexandre CONRAD wrote: > So I though maybe someone here could gimme some ideas about what's > already existing in that open source jungle and what I could start with. > you can have a look at http://www.bittorrent.com/index.html and download the sources of the mainline client 4.1.3. It implements decentralized tracker. This is far from the complete solution you expect, but it is a starting point and it is written in python. Regards, Arnaud. -- Arnaud Legout, Ph.D. INRIA Sophia Antipolis - Plan?te Phone : 00.33.4.92.38.78.15 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 06902 Sophia Antipolis CEDEX E-mail: arnaud.legout@sophia.inria.fr FRANCE Web : http://www-sop.inria.fr/planete/Arnaud.Legout/index.html From m.rogers at cs.ucl.ac.uk Fri Aug 5 13:04:17 2005 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P in Python and file synchronization In-Reply-To: <42F234AD.2010705@magic.fr> References: <42F234AD.2010705@magic.fr> Message-ID: <42F363D1.5010504@cs.ucl.ac.uk> Hi Alexandre, You might want to check out Groove (http://www.groove.net), Grouper (http://grouper.com) and Shinkuro (http://shinkuro.com). They all allow you to create encrypted groups for file sharing and messaging. Groove has a pretty sophisticated way of propagating changes to files etc, but I'm not sure whether it can be scripted or used to synchronize the filesystem (you might want to look at rsync over ssh for that). Hope this helps, Michael Alexandre CONRAD wrote: > Hello, > > I'm new to P2P. I very much like the concept of P2P decentralization > and the part about "hashing" the files (cut a file in chunks so the > propagation of the file starts when the 1st chunk is transfered to the > next client, not having to wait for the full file to be completed). > I'm thinking about using P2P for the management of my 250 PCs I have > to keep up-to-date. > > So the P2P application I'm looking for would be able to: > - connect to a server (which puts clients in relation and keeps track > of the shared files maybe using XML-RPC for keeping a journal of > available files ?) using a login/password. > - synchronize files between clients automaticly. So when a client > comes up with a new file(or changed/updated), other clients would > automaticly start downloading that file and propagating it to other > clients until all clients have that new file. > - crypt while exchanging files. > - handle file hashing. > - handle users/groups so a client can be part of a group and only > download files in which it's interested into. > - use simple command line (eg. ./p2p_client.py > :@:) and start sharing/synchronizing. > > Such an application would allow me to keep my 250 PCs network (and > growing) up-to-date with the latest file versions without worrying > about "who is up-to-date and who's not ?". > > And I want a P2P system (not FTP or similar) because I don't have much > bandwidth. > > So I though maybe someone here could gimme some ideas about what's > already existing in that open source jungle and what I could start with. > > Thanks for the hints ! ;) > > Regards, From douwen at yahoo.com Fri Aug 5 15:01:18 2005 From: douwen at yahoo.com (Dou Wen) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] amicima's MFP - source code released In-Reply-To: <200507312332.j6VNW5U92198@where.matthew.at> Message-ID: <20050805150118.33653.qmail@web40614.mail.yahoo.com> > After MFPNet is released, we plan to release the > source code to a demo > peer-to-peer VOIP + file transfer application for > Windows which uses MFP and > MFPNet. is MFPNet based on DHT?? Best regards ------- Skype me at: or ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From whg988 at gmail.com Mon Aug 8 07:49:42 2005 From: whg988 at gmail.com (Hong Guang Wang) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P streaming and DRM? Message-ID: <5173d3b405080800496e9dae1b@mail.gmail.com> I read an article about supporting DRM streaming upon P2P which is written in 2003. Does anyone know which p2p streaming software support this function? many thanks david wang From whg988 at gmail.com Tue Aug 9 05:58:36 2005 From: whg988 at gmail.com (Hong Guang Wang) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Any opensource p2p for wmv streaming? Message-ID: <5173d3b405080822582d216aa8@mail.gmail.com> i am interested in the reresearch of streaming upon P2P. any ideas or open source project on this topic? David From evantsang at gmail.com Tue Aug 9 06:31:28 2005 From: evantsang at gmail.com (Evan Tsang) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Any opensource p2p for wmv streaming? In-Reply-To: <5173d3b405080822582d216aa8@mail.gmail.com> References: <5173d3b405080822582d216aa8@mail.gmail.com> Message-ID: Take a look at this paper. http://www.cs.sfu.ca/~jcliu/Papers/47_01.pdf. They support wmv. -evan On 8/8/05, Hong Guang Wang wrote: > > i am interested in the reresearch of streaming upon P2P. any ideas or > open source project on this topic? > > 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 -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050808/0de4ebeb/attachment.html From thorsten.strufe at tu-ilmenau.de Tue Aug 9 11:34:17 2005 From: thorsten.strufe at tu-ilmenau.de (Thorsten Strufe) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Any opensource p2p for wmv streaming? In-Reply-To: <5173d3b405080822582d216aa8@mail.gmail.com> References: <5173d3b405080822582d216aa8@mail.gmail.com> Message-ID: <42F894B9.4050500@tu-ilmenau.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, there are as many p2p-streaming (aka end-system-multicast, aka host-based-multicast, aka application-layer-multicast, aka overlay-multicast, aka cooperative streaming) papers and projects as there are stars in the universe. Most of the solutions/ideas are only suitable for Video-on-Demand (as opposed to life-streaming or video-conferencing) though. Many papers/systems focus on a certain part (location of resources, bandwidth measurement, nat-traversal, locality-awareness, scheduling, routing [aka construction of the multicast tree/mesh], admission control, load balancing, ), which has to be implemented for a 'fully fledged coop-streaming-system'. Some very promising systems from my point of view are: esm (for small environments, with under 1000 viewers) ~ --> http://esm.cs.cmu.edu/ PROMISE/CollectCast (not continued, I think?) ~ --> http://www.cs.purdue.edu/homes/mhefeeda/ and maybe a few more. Good surveys on the topic can be found at: http://www.ieee-icnp.org/2003/papers/2-2.pdf http://www.ncassr.org/projects/multicast/papers/cabadspie04.pdf http://networks.cs.ucdavis.edu/~lizhi/papers/ECS289.pdf http://www.cs.kent.ac.uk/pubs/2003/1679/ We are currently at the starting point of building an open source framework, which will be able to plugin any of the stated algorithms (for whichever part of the system) in the real world for the use of analyzing and testing (and, maybe, productive overlay streaming, sometimes in the future). Some load-balancing-, routing-, location-, scheduling- and admission control mechanisms as well as different locality models (Vivaldi e.g.) have actually already been implemented and tested 'in the wild'. The name of the project is IlmStream the current incarnation of the framework is called 'ekStream' and some information can be found at: http://ekstream.org (very rudimental at the moment, sorry - but implementing and testing is, as always, more interesting and thrilling than documentation... :-/) Interesting topics (from my point of view) of this area of research at the moment are probably * resilience to faults/attacks * scalability to high numbers of 'users' in combination with stability * accountability (if at all possible) and maybe * secure group communciation * analytical proof (Loads of simulations have been done, some real-world-measurements as well, but analytical proof is hardly ever found). HTH, best, Thorsten - -- Dipl.-Inf. Thorsten Strufe +49(0)3677-694552, CC 440 Fachgebiet Telematik Institut Praktische Informatik Technische Universit?t Ilmenau http://www-ia.tu-ilmenau.de/IPI/FGT Sartre:Begehe keine Dummheit zweimal, die Auswahl ist doch gro? genug! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+JS5OQ9e8ojbqFYRAkUBAJwP8x7ANiwsvgvFy/huk9rjimLycgCfQK1G ovr+lYlfWthJtB0tCIDTg+c= =yOG/ -----END PGP SIGNATURE----- From whg988 at gmail.com Tue Aug 9 11:35:41 2005 From: whg988 at gmail.com (Hong Guang Wang) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Any opensource p2p for wmv streaming? In-Reply-To: References: <5173d3b405080822582d216aa8@mail.gmail.com> Message-ID: <5173d3b4050809043557bb47b0@mail.gmail.com> many thanks. any source code for simulation? regards On 8/8/05, Evan Tsang wrote: > Take a look at this paper. > http://www.cs.sfu.ca/~jcliu/Papers/47_01.pdf. > They support wmv. > > -evan > > On 8/8/05, Hong Guang Wang wrote: > > > > i am interested in the reresearch of streaming upon P2P. any ideas or > > open source project on this topic? > > > > 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 me at pixelcort.com Tue Aug 9 18:28:50 2005 From: me at pixelcort.com (Cortland Klein) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Any opensource p2p for wmv streaming? In-Reply-To: <5173d3b405080822582d216aa8@mail.gmail.com> References: <5173d3b405080822582d216aa8@mail.gmail.com> Message-ID: <5A0AB2D5-581C-4EB8-8E2A-9344E10423BF@pixelcort.com> Checkout Peercast . "PeerCast is an open source streaming media multicast tool. PeerCast uses peer to peer technology to minimize the necessary upload bandwidth for the original multicastor. See also Peercasting." - PeerCast, English Wikipedia On 2005 Aug 8, at 10:58 PM, Hong Guang Wang wrote: > i am interested in the reresearch of streaming upon P2P. any ideas or > open source project on this topic? > -- Cortland Klein +1 408 506 9791 Mac Specialist, Apple Store Valley Fair http://www.apple.com/retail/valleyfair/ Journal - http://pixelcort.com/ From dzq898 at 163.com Wed Aug 10 01:27:12 2005 From: dzq898 at 163.com (Zhiqun Deng) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Questions about the paper "Weighted Consistent Hashing" from SPAA 2005 Message-ID: <20050810012731.9E5F43FD02@capsicum.zgp.org> ICAgIEhlbGxvLCAgZXZlcnlib2R5DQogICAgTm93LCBJIGFtIHJlYWRpbmcgeW91ciBwYXBlciAi V2VpZ2h0ZWQgQ29uc2lzdGVudCBIYXNoaW5nIiAuIER1ZSB0byB0aGUgcHJvZm91bmQgdGhlb3J5 LCBJIGNhbm5vdCB1bmRlcnN0YW5kIHRoZSBwYXBlciBjbGVhcmx5LCBmb3IgZXhhbXBsZSwgSSBj YW5ub3QgdW5kZXJzdGFuZCB0aGUgbGluZWFyIG1ldGhvZCBjbGVhcmx5IGFuZCBob3cgY2FuIHRo ZSBhdXRob3IgZ2V0IHRoZSBmaWd1cmUgMSBpbiBwYWdlIHRocmVlIGFuZCBmaWd1cmUgNyBpbiBw YWdlIHNldmVuPw0KICAgIElmIHlvdSBoYXZlIHJlYWQgdGhpcyBwYXBlciwgd291bGQgeW91IG1p bmQgaGVscGluZyBtZT8gDQogICAgVGhhbmsgeW91IHZlcnkgbXVjaCENCg0KCQ0KDQogICAgQmVz dCByZWdhcmRzLA0KoaGhoaGhoaGhoaGhoaGhoQ0KLS0tDQpaaGlxdW4NCg0KRS1tYWlsOmR6cTg5 OEAxNjMuY29tDQoNCiAJCQkJDQoNCqGhoaGhoaGhoaGhoaGhDQo= From dzq898 at 163.com Wed Aug 10 01:30:39 2005 From: dzq898 at 163.com (Zhiqun) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Questions about the paper "Weighted Consistent Hashing" from SPAA 2005 Message-ID: <20050810013046.4D0453FD02@capsicum.zgp.org> Hello, everybody Now, I am reading your paper "Weighted Consistent Hashing" . Due to the profound theory, I cannot understand the paper clearly, for example, I cannot understand the linear method clearly and how can the author get the figure 1 in page three and figure 7 in page seven? If you have read this paper, would you mind helping me? Thank you very much! Best regards, --- Zhiqun E-mail:dzq898@163.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050810/8083947f/attachment.htm From mgp at ucla.edu Wed Aug 10 02:04:31 2005 From: mgp at ucla.edu (Michael Parker) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Questions about the paper "Weighted Consistent Hashing" from SPAA 2005 In-Reply-To: <20050810013046.4D0453FD02@capsicum.zgp.org> References: <20050810013046.4D0453FD02@capsicum.zgp.org> Message-ID: <42F960AF.7040000@ucla.edu> If anyone is interested, it isn't on the conference web site, but through some Googling I found the paper here: http://wwwcs.uni-paderborn.de/fachbereich/AG/agmadh/WWW/schindel/pubs/WDHT.pdf - Mike Zhiqun wrote: > Hello, everybody > Now, I am reading your paper "Weighted Consistent Hashing" . Due to > the profound theory, I cannot understand the paper clearly, for > example, I cannot understand the linear method clearly and how can the > author get the figure 1 in page three and figure 7 in page seven? > If you have read this paper, would you mind helping me? > Thank you very much! > Best regards, > ???????? > --- > Zhiqun > E-mail:dzq898@163.com > ??????? > ??????? > >------------------------------------------------------------------------ > >_______________________________________________ >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 srhea at cs.berkeley.edu Wed Aug 10 15:39:36 2005 From: srhea at cs.berkeley.edu (Sean Rhea) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] WORLDS CFP Message-ID: All, Sorry if you've already seen this, but I think it will be of interest to many here: Second Workshop on Real, Large Distributed Systems (WORLDS '05) December 13, 2005 San Francisco, California, USA PC Chairs: Vivek Pai and Brad Karp http://www.usenix.org/events/worlds05/cfp/ The deadline is this coming Monday, August 15. Sean -- Everyone chooses his or her own instrument for rebellion. I don't know what my son's will be, but my only hope for him is this: That by sharing my passions with him, I have planted the seeds of defiance that will someday be turned against me. -- Soo Lee Young -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050810/9030839a/PGP.pgp From trep at cs.ucr.edu Sat Aug 13 00:13:25 2005 From: trep at cs.ucr.edu (Thomas Repantis) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Distributed Snapshots In-Reply-To: References: <20050725181120.GA1902@angeldust.chaos> <8C6E6CD1-E0D0-4594-89FC-164AA672465A@cs.mu.oz.au> Message-ID: <20050813001325.GA2351@angeldust.chaos> Hi Lei Ni, Many thanks for your reply. I think the snapshot of A, B, and C will not be consistent, since it is unknown which of the messages exchanged with D should be included in it. Thomas On Mon, Aug 01, 2005 at 08:04:46PM +1000, Lei Ni wrote: > Dear Thomas, > > According to my understanding for the Chandy-Lamport algorithm, you > are correct. > > If you don't save and restore the state for D that means the state for > D is simply lost and your snapshot is no longer global snapshot. > > > > > Cheers, > > Lei Ni > > > ---------- Forwarded message ---------- > From: Aaron Harwood > Date: Jul 31, 2005 11:11 PM > Subject: Fwd: [p2p-hackers] Distributed Snapshots > To: Lei Ni > > > you may want to answer this email. > --aaron > > Begin forwarded message: > > From: Thomas Repantis > Date: 26 July 2005 4:11:20 AM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] Distributed Snapshots > Reply-To: "Peer-to-peer development." > > > Hi all, > > Can someone verify whether I am correct in my understanding of the following: > The Chandy-Lamport algorithm [1] can produce a distributed snapshot of a > system only if *all* nodes are running the algorithm. > > In other words, I am looking for a way to get a global snapshot of a system > of nodes say A, B, and C. The caveat is that they might exchange messages > with node D, which will not run a snapshot algorithm. I am not interested in > the state of D, but I need a consistent global snapshot of A, B, and C. > > Am I correct in my understanding that Chandy-Lamport cannot help in this case? > > Is there any other way to get a consistent global snapshot of such a > distributed system? > > Many thanks! > Thomas > > [1] > Distributed Snapshots: Determining Global States of a Distributed System > K. Mani Chandy, Leslie Lamport > ACM Transactions on Computer Systems 3, 1 (February, 1985), 63-75. > http://research.microsoft.com/users/lamport/pubs/chandy.pdf > > > -- > http://www.cs.ucr.edu/~trep > _______________________________________________ > 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 -- http://www.cs.ucr.edu/~trep From decapita at dti.unimi.it Sun Aug 14 10:51:19 2005 From: decapita at dti.unimi.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] ESORICS 2005 - Call for Participarion Message-ID: <45A7CD1F-3B94-4F74-A4DD-D4C8EA68251F@dti.unimi.it> [Apologies if you receive multiple copies of this message] CALL FOR PARTICIPATION -- ESORICS 2005 10TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY Milan, Italy - September 12-14, 2005 http://esorics05.dti.unimi.it/ AIMS AND SCOPE Organized in a series of European countries, ESORICS is confirmed as the European research event in computer security. The symposium started in 1990 and has been held on alternate years in different European countries and attracts an international audience from both the academic and industrial communities. From 2002 it has been held yearly. The Symposium has established itself as one of the premiere, international gatherings on information assurance. PROGRAM MONDAY SEPTEMBER 12, 2005 09:15 - 09:30 Welcome and Opening 09:30 - 10:30 Invited talk Computerized Voting Machines: A View from the Trenches B. Simons 10:30 - 11:00 Coffee break 11:00 - 12:30 Session 1: Access control XML Access Control with Policy Matching Tree N. Qi, M. Kudo Semantic Access Control Model: A Formal Specification M. I. Yague, M. Gallardo, A. Mana A Generic XACML Based Declarative Authorization Scheme for Java R. Gupta, M. Bhide 12:30 - 14:00 Lunch 14:00 - 15:30 Session 2: Advanced Authorization Specifications Specification and Validation of Authorisation Constraints Using UML and OCL K. Sohr, G. Ahn Unified Index for Mobile Object Data and Authorizations V. Atluri, Q. Guo On Obligations M. Hilty, D. Basin, A. Pretschner 15:30 - 16:00 Coffe break 16:00 - 17:30 Session 3: Cryptographic Schemes A Practical, Voter-Verifiable Election Scheme D. Chaum, P.Y.A. Ryan, S.Schneider Machine-Checked Security Proofs of Cryptographic Signature Schemes S. Tarento Sanitizable Signatures G. Ateniese, D. Chou, B. de Medeiros, G. Tsudik TUESDAY SEPTEMBER 13, 2005 09:00 - 10:30 Session 4: Cryptographic Protocols Limits of the Cryptographic Realization of Dolev-Yao-style XOR M. Backes, B. Pfitzmann Secure Implementation of Cryptographic Protocols: A Case Study Of Mutual Distrust A. Askarov, A. Sabelfeld Augmented oblivious Polynomial Evaluation Protocol and Its Applications H. Zhu 10:30 - 11:00 Coffee break 11:00 - 12:30 Session 5: Intrusion detection Using Attack Trees to Identify Malicious Attacks from Authorized Insiders I. Ray, N. Poolsapassit An Efficient and Unified Approach to Correlating, Hypothesizing, and Predicting Network Intrusion Alerts L. Wang, A. Liu, S. Jajodia Towards a Theory of Intrusion Detection G. Di Crescenzo, A. Ghosh, R. Talpade 12:30 - 14:00 Lunch 14:00 - 15:30 Session 6: Network security On Scalability and Modularisation in the Modelling of Network Security Systems J. de Albuquerque, H. Krumm, P. de Geus Sybil resistant DHT routing G. Danezis, C. Lesniewski-Laas, M. Frans Kaashoek, R. Anderson Botnet Tracking: Exploring a Root-Cause Methodology to Prevent Distributed Denial-of-Service Attacks F.C. Freiling, T. Holz, G. Wicherski 15:30 - 16:00 Coffee break 16:00 - 17:30 Session 7: Information Flow and Formal Security Properties Quantifying Probabilistic Information Flow in Computational Reactive Systems M. Backes Enforcing Non-safety Security Policies with Program Monitors J. Ligatti, L. Bauer, D. Walker Soundness of Formal Encryption in the Presence of Key-Cycles P. Adao, G. Bana, J. Herzog, A. Scedrov WEDNESDAY SEPTEMBER 14, 2005 09:00 - 10:30 Session 8: Privacy and Data Protection Privacy Preserving Clustering S. Jha, L. Kruger, P. McDaniel Abstractions Preserving Parameter Confidentiality S. Gurgenas, P. Ochsenschlaeger, C. Rudolpah Minimal Disclosure in Hierarchical Hippocratic Databases with Delegation F. Massacci, J. Mylopoulos, N. Zannone 10:30 - 11:00 Coffee break 11:00 - 12:30 Session 9: Security for protocols and devices Security Notions for Disk Encryption K. Gjosteen Local View Attack on Anonymous Communication M. Gogolewski, M. Klonowski, M. Kutylowski Browser Model for Security Analysis of Browser-Based Protocols T. Gross, B. Pfitzmann, A. Sadeghi REGISTRATION Online registration is available on the conference web page: http://esorics05.dti.unimi.it/registration.php ADDITIONAL INFORMATION On the web pages (http://esorics05.dti.unimi.it), you will find information about the program, the conference hotel and venue, and some travel and tourist information. We look forward to seeing you in Milan at ESORICS 2005. From codewarrior at cuseeme.de Sun Aug 14 10:57:31 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] ESORICS 2005 - Call for Participarion In-Reply-To: <45A7CD1F-3B94-4F74-A4DD-D4C8EA68251F@dti.unimi.it> References: <45A7CD1F-3B94-4F74-A4DD-D4C8EA68251F@dti.unimi.it> Message-ID: <41E0DEA4-EF90-48BA-BAAB-83E633A439AB@cuseeme.de> morning , seems like girls just call for partzipation;-),,,, are they really coding girls around ? i wish i could meet one. cheers and have a great day marc On Aug 14, 2005, at 12:51 PM, Sabrina De Capitani di Vimercati wrote: From dbarrett at quinthar.com Thu Aug 18 00:40:57 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Unidirectional or Bidirectional Manual Port Forwarding? Message-ID: <4303D919.4080705@quinthar.com> I'm experimenting with a particular user, and I'm experiencing unexpected behavior with regard to UDP port forwarding. I'm not sure if something is broken, or if I just misunderstand how it's supposed to work. Can you offer me any clarity on what should occur in this situation? Specifically, a user has configured his NAT (some DLink, address-restricted filtering model) to manually forward external traffic sent to a given port a specific internal IP:port. And this works fine -- traffic sent to the external endpoint X is in fact forwarded without trouble to internal endpoint Y. This this works great when a remote host is initiating a UDP session to the internal host. However, the reverse doesn't work so great. What I *expected* would happen is that all UDP sessions initiated from internal endpoint Y would be advertised to remote users as coming from external endpoint X. ie, I expected internally-initiated connections would "go out" through the manually-configured port-forwarded mapping. Thus regardless of which side initiated the connection, the remote side would see and use external endpoint X. But in practice, it appears the NAT ignores the port mapping when the internal machine initiates the connection, and instead establishes a new external mapping -- with the very address-restricted filtering properties I was hoping to avoid. So I guess what I'm asking is: 1) Are manually-forwarded NAT port mappings typically unidirectional or bidirectional? Does this depend on the NAT model? 2) Is it possible to manually configure the outbound mapping (ie, force all traffic originating from an internal endpoint to use a specific external endpoint)? 2) What type of mapping does UPnP attempt to establish? Thanks, and sorry for the meandering question -- I don't know enough to phrase it more succinctly! -david From dbarrett at quinthar.com Thu Aug 18 03:52:30 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Announcing: iGlance Open Alpha Message-ID: <430405FE.9080805@quinthar.com> I'm happy to report the closed alpha has been going so well, I've decided to open it up to public participation. Please visit the iGlance website at for details, or jump straight to the installer with these links: http://www.iglance.com/wiki http://www.iglance.com/installers/iglance.exe To give a quick rundown of the current featureset: - Push-to-talk voice/video (like a video walkie-talkie) - "Always on" video presence (ie live video, not away messages) - Per-buddy configurable hotkeys for gaming and from within other apps - VNC-style screen sharing (experimental) - File transfer - Text chat - NAT and firewall penetration for all features - Custom skinning engine In the pipeline: - High-performance Win32 screen sharing - Linux, MacOS, Windows Mobile 2003 portability - Secure group file sharing - .. what else do you want? Though performance optimizations haven't begun in earnest, the underlying technology seems to be shaping up nicely. Thus for now I'm primarily looking for people to give feedback on the overall usefulness of the featureset, with an eye for what my priorities should be going forward. And finally, this'll all be open source (once I sort out some licensing issues), so if you're looking for a NAT-piercing, VoIP, streaming-video, screen-sharing, file-sharing application that you can dig in and call your own, now's the time to jump on board and let me know where you want to take it. So download and sign up, and be sure to join the mailing to keep up on the latest developments by emailing: iglance-subscribe@yahoogroups.com Thanks for all your help on the list, and I invite you to come see what I've done with it! -david From tutschku at informatik.uni-wuerzburg.de Thu Aug 18 16:13:18 2005 From: tutschku at informatik.uni-wuerzburg.de (Kurt Tutschku) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] CFP: 3rd IEEE International Workshop on Mobile Peer to Peer Computing MP2P 06, (conjunction with the 4th IEEE PerCom 06) Message-ID: <20050818161833.C1C226F58E@nero.informatik.uni-wuerzburg.de> (Please apologize multiple copies) --------------------------------------------------------------------- 3rd IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'06) http://www-info3.informatik.uni-wuerzburg.de/mp2p2006 Pisa, Italy, March 17, 2006 In conjunction with the 4th IEEE International Conference on Pervasive Computing and Communications (PerCom?06) http://www.percom.org/ ---------------------------------------------------------------------- Peer-to-Peer (P2P) computing is a networking and distributed computing paradigm which allows the sharing of computing resources and services by direct, symmetric interaction between computers. The advance in mobile wireless communication technology and the increasing number of mobile users, extend the arena of P2P computing to encompass mobile devices and wireless networks. The special characteristics of mobile environments, such as highly variable connectivity, disconnection, location-dependency, resource contraints, and diversity in wireless networks as well as carrier-grade performance requirements bring new challenges for research in mobile P2P computing. MP2P?06 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of mobile P2P computing. It will address the challenges, technologies, and architectures leading to real-world solutions that provide users with direct access and control of their critical peer-based information and services, regardless of location or device. The principal theme of MP2P?06 is the development of protocols, systems and architectures of mobile P2P architectures and the evaluation of their performance. Topics of particular interest include, but are not limited to: - Architecture and platforms for mobile P2P computing - Measurement studies on mobile P2P systems - Performance of mobile P2P services - Resource and service discovery in mobile P2P computing - Resource exchange mechanisms in mobile P2P application - Mobile P2P over different kinds of bearer services: 2.5/3G (GPRS/UMTS) / 802.11 (WLAN) - Mobile P2P & operator/provider requirements - Reliability and carrier-gradeness of mobile P2P services - Mobile P2P & fixed P2P system interworking - Issues of combining P2P services with mobility (mobile IP / MANET) - Peer access and control in mobile environment - Location dependent mobile P2P services - Data exchange and rendering techniques for mobile devices - Secure communication protocols for mobile P2P computing - Mobile P2P messaging systems - Peer-to-peer broadband wireless communications - Applications of mobile P2P - Nature-inspired algorithms for mobile P2P computing - Theoretical issues on mobile information diffusion - Mobile P2P video games - Stimulating cooperation in mobile computing Paper Submission: ----------------- Papers must be written in English and should not exceed 6 pages in IEEE proceedings style. Authors MUST submit their papers through the EDAS web site (http://www.edas.info/) in three steps: * Creation of a personal account on EDAS (if the author does not already have one) * Registration of the paper (requiring a short abstract of up to 150 words) * Upload of the paper. Only in pdf format Submission implies the willingness of at least one of the authors to register and present the paper. All submissions will be reviewed and selected based on their originality of the paper. Accepted papers must be presented at the workshop and will appear in a combined PerCom 2006 workshop proceedings published by IEEE Computer Society Press. Authors that present a system in their paper are highly encouraged to demonstrate also the system in the demo session of the workshop. Important Dates: ---------------- Papers due: 5pm EST, September 15, 2005 Notification of acceptance November 15, 2005 Camera-ready papers due December, 2005 Organizing Committee, Program Co-chairs: ---------------------------------------- - Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany. - Frank-Uwe Andersen, Siemens Communications, Berlin, Germany. - Li Li, Communications Research Center Canada, Canada. - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill, USA Steering Board -------------- - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University. - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University - Cecilia Mascolo, Department of Computer Science, University College London - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill Publicity Chair --------------- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany Program Committee Members: -------------------------- - Frank-Uwe Andersen, Siemens Communications, Germany. - Christian Bettstetter, DoCoMo Euro-Labs,Germany. - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University. - Luca Caviglione, CNIT - University of Genoa Research Unit, University of Genova, Italy. - Geoff Coulson, Computing Department, University of Lancaster, UK. - Hermann de Meer, Department of Computer Networks & Computer Communications, University of Passau, Germany. - Babak Esfandiari, Carleton University, Canada. - Stephen Hailes, Department of Computer Science, University College of London, UK - Felix Hernandez-Campos, Department of Computer Science, University of North Carolina at Chapel Hill, USA - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University - Valerie Issarny, INRIA, France. - Wolfgang Kellerer, DoCoMo DoCoMo Communications Laboratories Europe, Germany. - Thomas Kunz, Dept. of Systems and Comp. Engineering, Carleton University. Canada. - Luciano Lenzini, University of Pisa, Pisa, Italy. - Li Li, Communications Research Center Canada, Canada. - Christoph Lindemann, FB Informatik IV, University of Dortmund , Germany. - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill - Rudolf Riedi, Department of Statistics, Rice University, USA - Pablo Rodriguez, Microsoft Research Ltd, Cambridge, UK. - George Roussos, School of Computer Science and Information Systems, Birkbeck College, University of London, UK - Shervin Shirmohammadi, School of Information Technology and Engineering (SITE), University of Ottawa, Canada. - Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany --- Dr. Kurt Tutschku, Assistant Professor University of Wuerzburg Department of Distributed Systems Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641 FAX.: +49-931-8886632 mailto:tutschku@informatik.uni-wuerzburg.de or mailto:kurttutschku@hotmail.com http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku From coderman at gmail.com Thu Aug 18 18:21:22 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Unidirectional or Bidirectional Manual Port Forwarding? In-Reply-To: <4303D919.4080705@quinthar.com> References: <4303D919.4080705@quinthar.com> Message-ID: <4ef5fec6050818112122416271@mail.gmail.com> On 8/17/05, David Barrett wrote: > 1) Are manually-forwarded NAT port mappings typically unidirectional or > bidirectional? Does this depend on the NAT model? This is NAT specific behavior / implementation dependant. What you describe is not uncommon, since UDP is stateless many NAT's lazily assume that port forwards operate in one direction. > 2) Is it possible to manually configure the outbound mapping (ie, force > all traffic originating from an internal endpoint to use a specific > external endpoint)? You can do this with Linux NAT's and probably others, but I doubt D-Link will be cooperative. Just to verify, the internal IP:port is using the same port as the one configured in the nat to forward traffic to, correct? > 2) What type of mapping does UPnP attempt to establish? UPnP tends to make a mapping more in line with that you except. That is to say, if UDP traffic exits from an internal IP:Port that matches a UPnP static mapping rule, it will exit from the public endpoint defined in the mapping. I believe I tried this with a Linksys router and it worked ok; I have no idea about D-Link. You may want to dig around on some game sites about UDP port forwards with the D-Link device you are using. There are some multi-player games which rely on loose UDP NAT or port forwards and they may have some insight into the particular problem you are experiencing. From dbarrett at quinthar.com Thu Aug 18 21:41:15 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Unidirectional or Bidirectional Manual Port Forwarding? In-Reply-To: <4ef5fec6050818112122416271@mail.gmail.com> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> Message-ID: <4305007B.8060102@quinthar.com> coderman wrote: > On 8/17/05, David Barrett wrote: > >>1) Are manually-forwarded NAT port mappings typically unidirectional or >>bidirectional? Does this depend on the NAT model? > > This is NAT specific behavior / implementation dependant. What you > describe is not uncommon, since UDP is stateless many NAT's lazily > assume that port forwards operate in one direction. Gotcha. Good to know; I'll redesign with that in mind. >>2) Is it possible to manually configure the outbound mapping (ie, force >>all traffic originating from an internal endpoint to use a specific >>external endpoint)? > > You can do this with Linux NAT's and probably others, but I doubt > D-Link will be cooperative. Just to verify, the internal IP:port is > using the same port as the one configured in the nat to forward > traffic to, correct? That's correct. > You may want to dig around on some game sites about UDP port forwards > with the D-Link device you are using. There are some multi-player > games which rely on loose UDP NAT or port forwards and they may have > some insight into the particular problem you are experiencing. Ahh, that's a good tip. Thanks! -david From p2phack at cilux.org Thu Aug 18 23:29:02 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Which open protocols support private group sharing/chat? In-Reply-To: <4305007B.8060102@quinthar.com> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> Message-ID: <430519BE.9010509@cilux.org> Does anyone here know which open protocols support private group sharing/chat? IOW, FOAF-style peering: like private group chatrooms with file sharing just amongst friends. I know this is intended to be a feature of Waste and maybe GNUnet? Does anyone know if any other open protocols support this? Thanks in advance, folks! Duncan B. Cragg From ap at hamachi.cc Fri Aug 19 15:15:31 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Which open protocols support private group sharing/chat? In-Reply-To: <430519BE.9010509@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> Message-ID: <4305F793.5000807@hamachi.cc> You can achieve privacy by constructing VPN between trusted parties first and then using existing protocols for whatever activity you'd like to have in the group. Protocol layering carries all the same benefits as a modular design does in a software. So I would strongly suggest to look for a right combination of existing (possibly somewhat customized) protocols rather than at something that has it all under one roof. This way you can, for example, have Jabber for chat and BitTorrent for file- sharing. Alex Duncan B. Cragg wrote: > Does anyone here know which open protocols support private group > sharing/chat? > > IOW, FOAF-style peering: like private group chatrooms with file sharing > just amongst friends. > > I know this is intended to be a feature of Waste and maybe GNUnet? > > Does anyone know if any other open protocols support this? > > > Thanks in advance, folks! > > > Duncan B. Cragg > > _______________________________________________ > 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 p2phack at cilux.org Fri Aug 19 22:45:19 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Which open protocols support private group sharing/chat? In-Reply-To: <4305F793.5000807@hamachi.cc> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> Message-ID: <430660FF.9090701@cilux.org> Alex Pankratov wrote: > You can achieve privacy by constructing VPN between trusted parties > first and then using existing protocols for whatever activity you'd > like to have in the group. > > Protocol layering carries all the same benefits as a modular design > does in a software. So I would strongly suggest to look for a right > combination of existing (possibly somewhat customized) protocols > rather than at something that has it all under one roof. This way > you can, for example, have Jabber for chat and BitTorrent for file- > sharing. > > OK - this seems to be how I2P sees things, but I was really hoping for pointers to all-in-one protocols. I suppose what I'm asking anyone on this list to tell me is: Is there an open protocol that would support the functionality of Imeem? http://www.imeem.com - just released this week Ants is another similarish sort of thing. I've discovered the phrase is 'F2F', btw, not 'FOAF'! Duncan B. Cragg >> Does anyone here know which open protocols support private group >> sharing/chat? >> >> IOW, FOAF-style peering: like private group chatrooms with file >> sharing just amongst friends. >> >> I know this is intended to be a feature of Waste and maybe GNUnet? >> >> Does anyone know if any other open protocols support this? >> >> From aharwood at cs.mu.OZ.AU Sat Aug 20 01:17:27 2005 From: aharwood at cs.mu.OZ.AU (Aaron Harwood) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] OPeN Library Software Release Message-ID: Dear P2P hackers, OPeN stands for Open Peer-to-Peer Network. The OPeN library allows developers to build peer-to-peer applications with pluggable services and protocols. The OPeN architecture defines a Connectivity layer, a Core Services layer and an Applications layer. Applications make use of services, while services make use of protocols. Both services and protocols follow a generic API which allows them to be readily reused in a variety of applications. The goal is to bring together peer-to-peer protocol, service and application developers while abstracting their implementation and problem details from each other. This integration allows complex peer- to-peer applications to be built and promotes interoperability across different applications. The distribution includes two protocols, one protocol is based on the Chord algorithm and the other protocol is a connection caching protocol called Floc. The distribution also includes a data service for reading and writing data objects. The software and more information is found here: http://p2p.cs.mu.oz.au/software/OPeN Information about the Peer-to-Peer Networks and Applications Research Group is found here: http://www.cs.mu.oz.au/p2p We have a wiki to collect experience with use of the software: http://p2p.cs.mu.oz.au/wiki Please feel free to contribute to the OPeN project. We would be very happy to assist you to get started. -- Aaron - - - - - - - - - - - - - - - - - Aaron Harwood Department of Computer Science and Software Engineering. The University of Melbourne. http://www.cs.mu.oz.au/~aharwood/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050820/ad5243b3/attachment.htm From p2phack at cilux.org Sun Aug 21 18:59:43 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Which open protocols support private group sharing/chat? In-Reply-To: <430660FF.9090701@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> Message-ID: <4308CF1F.6010504@cilux.org> >>> Does anyone here know which open protocols support private group >>> sharing/chat? >>> IOW, [F2F]-style peering: like private group chatrooms with file >>> sharing just amongst friends. >>> I know this is intended to be a feature of Waste .. >>> Does anyone know if any other open protocols support this? > Is there an open protocol that would support the > functionality of Imeem? > http://www.imeem.com - just released this week Righto - since there is nothing out there that does it (deduced through 'negation by failure'): Would anyone on this list be interested in collaborating on (or at least discussing) an open source/open protocol application such as Imeem, and the like?? Duncan Cragg PS Please will someone also tell me if, as I am rapidly beginning to suspect, I'm yaddering away on completely the wrong list, here!? =0) Perhaps a new list is called for. PPS I have also been pointed to KDrive as a similar, commercial, example, by David Barret (thanks), in case anyone is interested. From enzomich at gmail.com Mon Aug 22 01:00:17 2005 From: enzomich at gmail.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) Message-ID: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> Glad to see that someone else is thinking about it: http://voxilla.com/voxstory170.html However, I suspect that SIP is too NAT-unfriendly for this job, and IAX would represent a much better open alternative. There is already a portable library to handle IAX protocol and audio I/O (http://iaxclient.sourceforge.net/ ) and work is currently being done to add a security layer (http://lists.digium.com/pipermail/asterisk-security/2005-January/000011.h tml ) so the only two pieces missing to the puzzle would be relatively easy to add: a P2P distributed registry and a NAT hole-punching mechanism (or, in difficult cases, full media relaying) through non-NATted middleman nodes. Enzo From dbarrett at quinthar.com Mon Aug 22 01:13:10 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) In-Reply-To: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> Message-ID: <430926A6.9030806@quinthar.com> I wrote some comments on Eric's blog (sipthat.com) detailing why I disagree: http://sipthat.com/archives/000351.html Aswath has another relevant article: http://www.mocaedu.com/mt/archives/000168.html Basically, I think P2P is useful to reduce legal vulnerability, obtain high security, minimize bottlenecks, and distribute computation. None of these applies to SIP proxies, which are essentially directory-based "rendezvous" services. That said, all of these certainly apply to the actual media components (audio, video, etc). But these are generally RTP. The SIP part is very low cost, low CPU, low bandwidth, and benefits from centralization. My original comments to Eric's article follow: -----Original Message----- From: David Barrett [mailto:dbarrett@quinthar.com] Sent: Tuesday, August 02, 2005 3:11 AM To: erik@sipthat.com Subject: Re: P2P VoIP using SIP and Open Standards Hi, sorry for the late reply to your July 25th posting about P2P SIP, but you posed the question: >> Everyone is looking for a new solution for P2P VoIP, I think P2P >> SIP is the answer, do you? My answer is no, I don't believe P2P SIP is the key to P2P VoIP. More specifically, I don't think an IETF standard for decentralized SIP proxies will gain traction because it solves problems that nobody has, while complicating the problems that we do. Now, I recognize VoIP will grow, and the actual media components will migrate to P2P. But I do not believe the SIP proxy component of the global architecture gains anything by being decentralized in this way. My reasoning is based on the observation that P2P is primarily useful in two situations: a) When a centralized solution is too costly b) When a centralized solution is legally vulnerable Consider the case of Napster. A kid in a college dorm room was able to host a global rendezvous service (akin to a SIP proxy) for millions of simultaneous users, for free. Obviously, he didn't suffer from (a). But (b) was what took him down, and thus gave rise to Gnutella (et al). But had (b) not occurred (ie, had the courts ruled in favor of Napster), I offer that Gnutella simply would not exist because it offers precisely zero incremental value. It is slower, less reliable, and less comprehensive than Napster could have been. Had Napster been allowed to grow, it could have offered better services, evolved faster, and been superior in every measurable way. SIP proxies are today like Napster was then. But VoIP isn't illegal, and thus a SIP proxy is not a legal vulnerability. Thus I see no reason to believe that a decentralized alternative to a SIP proxy would warrant the resulting complexity cost inherent in any "pure"-P2P solution. All that said, I do believe that P2P is the future of VoIP, and near-free services will be the business model. I merely think that the SIP proxy part of the equation is best left centralized. -david Posted by: David Barrett at August 6, 2005 01:01 AM So again, I'm still not sold on the benefits of P2P SIP. I think it's cool, don't get me wrong. And the idea of setting up an instant P2P network in the middle of a desert or in a disaster area is appealing, certainly. But you have to admit those are rather extreme circumstances. For the remaining 99.999% of actual real world users, this is not the case. Furthermore, I agree that the servers at Free World Dialup and other free SIP services cost money. But not much, else they wouldn't be free. For under $100/mo you can get a dedicated server right on the backbone. The cost of deploying and maintaining hardware is virtually negligible these days. The real costs come in managing the network, and this is where centralized services come in handy. So P2P SIP is cool, certainly. And it might be handy the extreme situations you offer. But by the time the intrinsic decentralized problems have been hammered out, a centralized alternative will already dominate the landscape. And when it comes to competition, the decentralized solution offers no significant real world advantage (cost, reliability, performance) to anyone (user, administrator), while offering significant drawbacks in terms of complexity and the overall uncontrolled nature of P2P. Would you disagree? I mean, except for disaster areas and deserts, and except for saving $100/mo for a million users, what's the benefit? Furthermore, do you acknowledge the disadvantages in terms of reliability and performance (ie, global distributed search versus database lookup) of a P2P solution? How would you argue the benefits outweigh the detriments? -david From enzomich at gmail.com Mon Aug 22 02:27:30 2005 From: enzomich at gmail.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> Message-ID: <07e201c5a6c1$2ca77c80$0200a8c0@em.noip.com> Well, you say that VoIP is not illegal. A lot of thing used not to be, and were criminalized by statute; some, like encryption for the masses, managed to escape only because it was too late to enforce prohibition. And in some countries, VoIP _is_, or may become, illegal, either for political reasons (especially secure VoIP: ever heard of CALEA?) or just to protect inefficient government monopolies (see e.g. http://www.techweb.com/wire/networking/60403862 ). In the end, unenforceability is Liberty's best friend. And then, there is the issue of ease of use: centralized solutions need a multiplicity of providers, because nobody wants to see a FWD or Sipphone close down or go commercial and start charging annual fees. But multiple providers means multiple accounts, and, often, balkanized user bases unable to cross provider borders (as each provider likes to protect its flock from other shepherds -- or, with a probably more fitting metaphor, its harem from other sultans ;-) ). This results in complications in the setup and smallish user communities. The proof of the pudding is in the making: Skype, despite being far from ideal in terms of openness, certifiable security and interoperability, has 50 million users. How many do FWD or Sipphone have? Actually, a system of centralized but open and interoperable telephone directories (based on the DNS) already exists, and it's called ENUM: essentially it allows to convert an E.164 telephone number into a (SIP, IAX, H.323...) URI. There is at least one independent and free registrar offering ENUM service to the public: www.e164.org . Due to the distributed caching operated by the DNS, the load on the actual registrar is quite small, further reducing its operating costs (it's like running a conventional authoritative DNS server). However, the DNS is by itself vulnerable to attacks: in Mainland China, for example, all the DNS queries to foreign servers are transparently rerouted to internal servers that return answers with random RR's if the domain name is blacklisted (I've recently had to abandon em.no-ip.com because all the subdomains of no-ip.com were blacklisted, and so are dyndns.org's). A really robust directory service must be fully distributed (e.g., DHT based) and port-flexible, rather than relying upon well-known ports. Grafting these characteristics over a DNS-based mechanism is also possible, although not very convenient for non-technical users: see e.g. my namecache daemon (http://kadc.sourceforge.net/apps.html#namecache ), which however is presently limited to A records, and can't yet handle the NAPTR records used by ENUM. Cheers -- Enzo P.S. ----- Original Message ----- From: "David Barrett" To: "Peer-to-peer development." Sent: Monday, August 22, 2005 9:13 AM Subject: Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) > I wrote some comments on Eric's blog (sipthat.com) detailing why I disagree: > > http://sipthat.com/archives/000351.html > > Aswath has another relevant article: > > http://www.mocaedu.com/mt/archives/000168.html > > Basically, I think P2P is useful to reduce legal vulnerability, obtain > high security, minimize bottlenecks, and distribute computation. None > of these applies to SIP proxies, which are essentially directory-based > "rendezvous" services. > > That said, all of these certainly apply to the actual media components > (audio, video, etc). But these are generally RTP. The SIP part is very > low cost, low CPU, low bandwidth, and benefits from centralization. > > My original comments to Eric's article follow: > > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Tuesday, August 02, 2005 3:11 AM > To: erik@sipthat.com > Subject: Re: P2P VoIP using SIP and Open Standards > > Hi, sorry for the late reply to your July 25th posting about P2P SIP, but > you posed the question: > > > >> Everyone is looking for a new solution for P2P VoIP, I think P2P > >> SIP is the answer, do you? > > > My answer is no, I don't believe P2P SIP is the key to P2P VoIP. More > specifically, I don't think an IETF standard for decentralized SIP proxies > will gain traction because it solves problems that nobody has, while > complicating the problems that we do. > > Now, I recognize VoIP will grow, and the actual media components will > migrate to P2P. But I do not believe the SIP proxy component of the global > architecture gains anything by being decentralized in this way. > > My reasoning is based on the observation that P2P is primarily useful in two > situations: > > a) When a centralized solution is too costly > b) When a centralized solution is legally vulnerable > > Consider the case of Napster. A kid in a college dorm room was able to host > a global rendezvous service (akin to a SIP proxy) for millions of > simultaneous users, for free. Obviously, he didn't suffer from (a). > But (b) was what took him down, and thus gave rise to Gnutella (et al). > > But had (b) not occurred (ie, had the courts ruled in favor of Napster), I > offer that Gnutella simply would not exist because it offers precisely zero > incremental value. It is slower, less reliable, and less comprehensive than > Napster could have been. Had Napster been allowed to grow, it could have > offered better services, evolved faster, and been superior in every > measurable way. > > SIP proxies are today like Napster was then. But VoIP isn't illegal, and > thus a SIP proxy is not a legal vulnerability. Thus I see no reason to > believe that a decentralized alternative to a SIP proxy would warrant the > resulting complexity cost inherent in any "pure"-P2P solution. > > All that said, I do believe that P2P is the future of VoIP, and near-free > services will be the business model. I merely think that the SIP proxy part > of the equation is best left centralized. > > -david > Posted by: David Barrett at August 6, 2005 01:01 AM > > So again, I'm still not sold on the benefits of P2P SIP. I think it's > cool, don't get me wrong. And the idea of setting up an instant P2P > network in the middle of a desert or in a disaster area is appealing, > certainly. But you have to admit those are rather extreme circumstances. > For the remaining 99.999% of actual real world users, this is not the case. > > Furthermore, I agree that the servers at Free World Dialup and other > free SIP services cost money. But not much, else they wouldn't be free. > For under $100/mo you can get a dedicated server right on the backbone. > The cost of deploying and maintaining hardware is virtually negligible > these days. > > The real costs come in managing the network, and this is where > centralized services come in handy. > > So P2P SIP is cool, certainly. And it might be handy the extreme > situations you offer. But by the time the intrinsic decentralized > problems have been hammered out, a centralized alternative will already > dominate the landscape. And when it comes to competition, the > decentralized solution offers no significant real world advantage (cost, > reliability, performance) to anyone (user, administrator), while > offering significant drawbacks in terms of complexity and the overall > uncontrolled nature of P2P. > > Would you disagree? I mean, except for disaster areas and deserts, and > except for saving $100/mo for a million users, what's the benefit? > > Furthermore, do you acknowledge the disadvantages in terms of > reliability and performance (ie, global distributed search versus > database lookup) of a P2P solution? How would you argue the benefits > outweigh the detriments? > > -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 coderman at gmail.com Mon Aug 22 05:40:27 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) In-Reply-To: <430926A6.9030806@quinthar.com> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> Message-ID: <4ef5fec6050821224053c04ca1@mail.gmail.com> On 8/21/05, David Barrett wrote: > ... > My reasoning is based on the observation that P2P is primarily useful in two > situations: > > a) When a centralized solution is too costly > b) When a centralized solution is legally vulnerable i think there is an important third aspect that Enzo hints at: c) When a centralized solution doesn't provide enough privacy. this is the driving force i see behind future growth of friend nets (private group networks) and dark nets. CALEA for VoIP is one example of how privacy may become more important and large, centralized SIP proxies unattractive. there are better examples. Best regards, From aconrad.tlv at magic.fr Mon Aug 22 08:38:57 2005 From: aconrad.tlv at magic.fr (Alexandre CONRAD) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P in Python and file synchronization In-Reply-To: <20050808054542.GA4820@dt4.ira.uka.de> References: <42F234AD.2010705@magic.fr> <20050808054542.GA4820@dt4.ira.uka.de> Message-ID: <43098F21.6060701@magic.fr> >>So the P2P application I'm looking for would be able to: >>- connect to a server (which puts clients in relation and keeps track of >>the shared files maybe using XML-RPC for keeping a journal of available >>files ?) using a login/password. > > > do you really need a p2p way to manage your clients? Sounds like > ssh+rsync would work better for you. (sorry for long response, back from holidays :]) Well, of course, I thought about that, but the problem is that I don't have much bandwidth at my office (that's where the updates would be available from). So using P2P would alow me to set a client at my office sharing new files and that client would only upload these new files to a few remote clients. After that, the update would be available from other clients, helping me to upgrade the rest of my network and using my other remote client's bandwidth. Regards, -- Alexandre CONRAD - TLV Research & Development tel : +33 1 30 80 55 05 fax : +33 1 30 80 55 06 6, rue de la plaine 78860 - SAINT NOM LA BRETECHE FRANCE From dbarrett at quinthar.com Mon Aug 22 09:23:23 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) References: <1124702566.E92A750@di11.dngr.org> Message-ID: <1124702611.35AC0309@dj11.dngr.org> Yes, you are right. I didn't mean to dispute the possible security/privacy/law-evading advantages of a pure-decentralized solution for extreme users. I mearly meant to question the practical advantages for the ultra-majority of real-world users who are not in disaster zones, deserts, evading law enforcement, at risk of corporate espionage, participating in organized crime or terrorist cells, freedom fighting, politically agitating, or otherwise overtly distrustful of the powers that be. After all, current telephones have virtually no security, but are widely popular with literally billions of users. I'd rather the IETF focus on the billions of mainstream users (simplifying the use of federated SIP servers based on DNS records, just like email), who have rather uniform and simple needs, than get caught up worrying too much about the diverse and complex needs of the hard-core fringe. In the end, the hard-core fringe will certainly take care of itself, for better and for worse, and probably by those who don't give a damn what the IETF thinks. For example, you rightly pointed out the difficulty of getting SIP to work in NAT'd environments. I'd prefer the IETF: - Put more weight behind its BEHAVE recommedations, as well as - Totally rethink/simplify/unify the STUN/TURN/ICE standards (possibly just create a SIP 2 standard that iterates on the whole protocol suite into one integrated, stramlined whole), Before addressing the nonexistent need for a new P2P SIP standard. The IETF can't do everything, so I want it to focus on what brings the greatest joy to the greatest number. Anyway, with all that said, you mentioned NAPTR isn't widely deployed. I don't know much about it, but I do know SIP was envisioned to use it for looking up the proxy that manages a given SIP address (just like looking up the email server for an email address). What can be done to accelerate its spread, or compensate for its absence? -david On Sun, 21 Aug 2005 7:52 pm, Enzo Michelangeli wrote: > Well, you say that VoIP is not illegal. A lot of thing used not to be, > and > were criminalized by statute; some, like encryption for the masses, > managed to escape only because it was too late to enforce prohibition. > And > in some countries, VoIP _is_, or may become, illegal, either for > political > reasons (especially secure VoIP: ever heard of CALEA?) or just to > protect > inefficient government monopolies (see e.g. > http://www.techweb.com/wire/networking/60403862 ). In the end, > unenforceability is Liberty's best friend. > > And then, there is the issue of ease of use: centralized solutions need > a > multiplicity of providers, because nobody wants to see a FWD or > Sipphone > close down or go commercial and start charging annual fees. But > multiple > providers means multiple accounts, and, often, balkanized user bases > unable to cross provider borders (as each provider likes to protect its > flock from other shepherds -- or, with a probably more fitting > metaphor, > its harem from other sultans ;-) ). This results in complications in > the > setup and smallish user communities. The proof of the pudding is in the > making: Skype, despite being far from ideal in terms of openness, > certifiable security and interoperability, has 50 million users. How > many > do FWD or Sipphone have? > > Actually, a system of centralized but open and interoperable telephone > directories (based on the DNS) already exists, and it's called ENUM: > essentially it allows to convert an E.164 telephone number into a (SIP, > IAX, H.323...) URI. There is at least one independent and free > registrar > offering ENUM service to the public: www.e164.org . Due to the > distributed > caching operated by the DNS, the load on the actual registrar is quite > small, further reducing its operating costs (it's like running a > conventional authoritative DNS server). However, the DNS is by itself > vulnerable to attacks: in Mainland China, for example, all the DNS > queries > to foreign servers are transparently rerouted to internal servers that > return answers with random RR's if the domain name is blacklisted (I've > recently had to abandon em.no-ip.com because all the subdomains of > no-ip.com were blacklisted, and so are dyndns.org's). A really robust > directory service must be fully distributed (e.g., DHT based) and > port-flexible, rather than relying upon well-known ports. Grafting > these > characteristics over a DNS-based mechanism is also possible, although > not > very convenient for non-technical users: see e.g. my namecache daemon > (http://kadc.sourceforge.net/apps.html#namecache ), which however is > presently limited to A records, and can't yet handle the NAPTR records > used by ENUM. > > Cheers -- > > Enzo > > P.S. > > > ----- Original Message ----- > From: "David Barrett" > To: "Peer-to-peer development." > Sent: Monday, August 22, 2005 9:13 AM > Subject: Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? > (Voxilla) > > >> I wrote some comments on Eric's blog (sipthat.com) detailing why I > disagree: >> >> http://sipthat.com/archives/000351.html >> >> Aswath has another relevant article: >> >> http://www.mocaedu.com/mt/archives/000168.html >> >> Basically, I think P2P is useful to reduce legal vulnerability, obtain >> high security, minimize bottlenecks, and distribute computation. None >> of these applies to SIP proxies, which are essentially directory-based >> "rendezvous" services. >> >> That said, all of these certainly apply to the actual media components >> (audio, video, etc). But these are generally RTP. The SIP part is >> very >> low cost, low CPU, low bandwidth, and benefits from centralization. >> >> My original comments to Eric's article follow: >> >> -----Original Message----- >> From: David Barrett [mailto:dbarrett@quinthar.com] >> Sent: Tuesday, August 02, 2005 3:11 AM >> To: erik@sipthat.com >> Subject: Re: P2P VoIP using SIP and Open Standards >> >> Hi, sorry for the late reply to your July 25th posting about P2P SIP, > but >> you posed the question: >> >> >> >> Everyone is looking for a new solution for P2P VoIP, I think P2P >> >> SIP is the answer, do you? >> >> >> My answer is no, I don't believe P2P SIP is the key to P2P VoIP. More >> specifically, I don't think an IETF standard for decentralized SIP > proxies >> will gain traction because it solves problems that nobody has, while >> complicating the problems that we do. >> >> Now, I recognize VoIP will grow, and the actual media components will >> migrate to P2P. But I do not believe the SIP proxy component of the > global >> architecture gains anything by being decentralized in this way. >> >> My reasoning is based on the observation that P2P is primarily useful >> in > two >> situations: >> >> a) When a centralized solution is too costly >> b) When a centralized solution is legally vulnerable >> >> Consider the case of Napster. A kid in a college dorm room was able to > host >> a global rendezvous service (akin to a SIP proxy) for millions of >> simultaneous users, for free. Obviously, he didn't suffer from (a). >> But (b) was what took him down, and thus gave rise to Gnutella (et >> al). >> >> But had (b) not occurred (ie, had the courts ruled in favor of >> Napster), > I >> offer that Gnutella simply would not exist because it offers precisely > zero >> incremental value. It is slower, less reliable, and less comprehensive > than >> Napster could have been. Had Napster been allowed to grow, it could >> have >> offered better services, evolved faster, and been superior in every >> measurable way. >> >> SIP proxies are today like Napster was then. But VoIP isn't illegal, >> and >> thus a SIP proxy is not a legal vulnerability. Thus I see no reason to >> believe that a decentralized alternative to a SIP proxy would warrant > the >> resulting complexity cost inherent in any "pure"-P2P solution. >> >> All that said, I do believe that P2P is the future of VoIP, and > near-free >> services will be the business model. I merely think that the SIP proxy > part >> of the equation is best left centralized. >> >> -david >> Posted by: David Barrett at August 6, 2005 01:01 AM >> >> So again, I'm still not sold on the benefits of P2P SIP. I think it's >> cool, don't get me wrong. And the idea of setting up an instant P2P >> network in the middle of a desert or in a disaster area is appealing, >> certainly. But you have to admit those are rather extreme >> circumstances. >> For the remaining 99.999% of actual real world users, this is not the > case. >> >> Furthermore, I agree that the servers at Free World Dialup and other >> free SIP services cost money. But not much, else they wouldn't be >> free. >> For under $100/mo you can get a dedicated server right on the >> backbone. >> The cost of deploying and maintaining hardware is virtually negligible >> these days. >> >> The real costs come in managing the network, and this is where >> centralized services come in handy. >> >> So P2P SIP is cool, certainly. And it might be handy the extreme >> situations you offer. But by the time the intrinsic decentralized >> problems have been hammered out, a centralized alternative will >> already >> dominate the landscape. And when it comes to competition, the >> decentralized solution offers no significant real world advantage >> (cost, >> reliability, performance) to anyone (user, administrator), while >> offering significant drawbacks in terms of complexity and the overall >> uncontrolled nature of P2P. >> >> Would you disagree? I mean, except for disaster areas and deserts, and >> except for saving $100/mo for a million users, what's the benefit? >> >> Furthermore, do you acknowledge the disadvantages in terms of >> reliability and performance (ie, global distributed search versus >> database lookup) of a P2P solution? How would you argue the benefits >> outweigh the detriments? >> >> -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 >> > > _______________________________________________ > 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 aconrad.tlv at magic.fr Mon Aug 22 11:04:03 2005 From: aconrad.tlv at magic.fr (Alexandre CONRAD) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P in Python and file synchronization In-Reply-To: <20050822085227.GD23365@dt4.ira.uka.de> References: <42F234AD.2010705@magic.fr> <20050808054542.GA4820@dt4.ira.uka.de> <43098F21.6060701@magic.fr> <20050822085227.GD23365@dt4.ira.uka.de> Message-ID: <4309B123.2050803@magic.fr> Kendy Kutzner wrote: > On 2005-08-22T10:38:57+0200, Alexandre CONRAD wrote: > >>>do you really need a p2p way to manage your clients? Sounds like >>>ssh+rsync would work better for you. >> >>(sorry for long response, back from holidays :]) >> >>Well, of course, I thought about that, but the problem is that I don't >>have much bandwidth at my office (that's where the updates would be >>available from). So using P2P would alow me to set a client at my office >>sharing new files and that client would only upload these new files to a >>few remote clients. After that, the update would be available from other >>clients, helping me to upgrade the rest of my network and using my other >>remote client's bandwidth. > > > And the problem in doing the rsync+ssh from client to client is? Using rsync+ssh would mean that a client connects to an other client (so it has to know the IP, and my clients have dynamic IPs) scan the remote files to see if new files are available. But this is not very efficient because it could take time between the 1st upgraded client and the last one. And what if a client is down ? AFAIK, you need a server somewhere to centralize and hold a list of available files and keep track of which client is actualy connected/authentified and ready to share the file (or part). As most of my clients are on ISDN, they don't have constant internet access. So clients would be scheduled to connect once everyday at the same time to check if any new files are available for update. Only my client holding the upgrades (at my office) would be always connected. Regards, -- Alexandre CONRAD - TLV Research & Development tel : +33 1 30 80 55 05 fax : +33 1 30 80 55 06 6, rue de la plaine 78860 - SAINT NOM LA BRETECHE FRANCE From sg266 at cornell.edu Mon Aug 22 11:25:47 2005 From: sg266 at cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) In-Reply-To: <4ef5fec6050821224053c04ca1@mail.gmail.com> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> <4ef5fec6050821224053c04ca1@mail.gmail.com> Message-ID: <1124709947.18653.17.camel@mazinger.u.cs.cornell.edu> On Mon, 2005-08-22 at 01:40 -0400, coderman wrote: > On 8/21/05, David Barrett wrote: > > My reasoning is based on the observation that P2P is primarily useful in two > > situations: > > i think there is an important third aspect that Enzo hints at: > c) When a centralized solution doesn't provide enough privacy. IMHO, privacy and the centralized vs. p2p debate is completely orthogonal. If you mean privacy of the conversation -- centralized data proxies are just as secure as P2P as long as you encrypt the data stream end-to- end. If you mean privacy in terms of figuring out what parties are communicating (and not necessarily what is being said) -- then P2P does not provide any more privacy than a centralized approach [1]. [1] http://news.com.com/Feds+fund+VoIP+tapping +research/2100-7348_3-5825932.html?tag=nl -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050822/c45184f3/attachment.pgp From solipsis at pitrou.net Mon Aug 22 11:52:28 2005 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) In-Reply-To: <1124702611.35AC0309@dj11.dngr.org> References: <1124702566.E92A750@di11.dngr.org> <1124702611.35AC0309@dj11.dngr.org> Message-ID: <1124711548.29527.19.camel@p-dvsi-395-20.rd.francetelecom.fr> Hi, > I mearly meant to question the practical advantages for the > ultra-majority of real-world users who are not in disaster zones, > deserts, evading law enforcement, at risk of corporate espionage, > participating in organized crime or terrorist cells, freedom fighting, > politically agitating, or otherwise overtly distrustful of the powers > that be. I don't want to get in a political rant, but if you include emerging countries like esp. China, clearly the "ultra-majority of real-world users" are not free from privacy concerns... (not to mention the mess in Russia and nearby countries) And even in democratic countries, there could be some legitimate concerns. After all MacCarthyism happened in the US. http://en.wikipedia.org/wiki/McCarthyism The bottom line is that in many situations, you can have legitimate reasons to distrust the powers that be without being part of the "hard-core fringe". Regards Antoine. From adam at cypherspace.org Mon Aug 22 13:51:19 2005 From: adam at cypherspace.org (Adam Back) Date: Sat Dec 9 22:13:01 2006 Subject: signalling level voip privacy & p2p (Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype?) In-Reply-To: <1124709947.18653.17.camel@mazinger.u.cs.cornell.edu> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> <4ef5fec6050821224053c04ca1@mail.gmail.com> <1124709947.18653.17.camel@mazinger.u.cs.cornell.edu> Message-ID: <20050822135119.GA14618@bitchcake.off.net> You are talking about current protocols -- and even with current protocols I think p2p does because without a central server it is harder to tap -- you have to tap enough points to catch the call negotiation you are interested in. But I think one could design a p2p SIP alternative that does protect privacy. There has been some work on replyable untraceable email like nym servers, and mixminion SURBs. Also at zero-knowledge systems they had a pseudonymous mail system. Related PET techniques could be used for pseudonymous signaling of call attempts, without revealing who is intending to call who at the signalling level. Adam On Mon, Aug 22, 2005 at 07:25:47AM -0400, Saikat Guha wrote: > > i think there is an important third aspect that Enzo hints at: > > c) When a centralized solution doesn't provide enough privacy. > > IMHO, privacy and the centralized vs. p2p debate is completely > orthogonal. > > If you mean privacy in terms of figuring out what parties are > communicating (and not necessarily what is being said) -- then P2P does > not provide any more privacy than a centralized approach [1]. From enzomich at gmail.com Mon Aug 22 14:49:10 2005 From: enzomich at gmail.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) References: <1124702566.E92A750@di11.dngr.org> <1124702611.35AC0309@dj11.dngr.org> Message-ID: <0a6f01c5a728$c61dcf60$0200a8c0@em.noip.com> ----- Original Message ----- From: "David Barrett" To: Sent: Monday, August 22, 2005 5:23 PM Subject: Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla) [...] > After all, current telephones have virtually no security, but are widely > popular with literally billions of users. I'd rather the IETF focus on > the billions of mainstream users (simplifying the use of federated SIP > servers based on DNS records, just like email), who have rather uniform > and simple needs, than get caught up worrying too much about the diverse > and complex needs of the hard-core fringe. Actually, as I said, this is possible right now with ENUM. [...] > For example, you rightly pointed out the difficulty of getting SIP to > work in NAT'd environments. I'd prefer the IETF: > > - Put more weight behind its BEHAVE recommedations, as well as > - Totally rethink/simplify/unify the STUN/TURN/ICE standards (possibly > just create a SIP 2 standard that iterates on the whole protocol suite > into one integrated, stramlined whole), Such an alternative is already here, now: it's called IAX... > Before addressing the nonexistent need for a new P2P SIP standard. The > IETF can't do everything, so I want it to focus on what brings the > greatest joy to the greatest number. > > Anyway, with all that said, you mentioned NAPTR isn't widely deployed. > I don't know much about it, but I do know SIP was envisioned to use it > for looking up the proxy that manages a given SIP address (just like > looking up the email server for an email address). NAPTR is a type of Resource Records mainly used by the ENUM number-to-URI service (and also by similar private numbering systems). You may get the necessary background e.g. at http://enum.nic.at/documents/Diverse/Background_to_NAPTR.html . If popular User Agents just bothered to support it, it could be used immediately: the existing DNS infrastructure is all is needed. To get a taste of it, just try this: use dig (or host, or any other DNS client tool) to resolve "*.0.9.9.9.2.8.8.e164.org", i.e. the number "8829990*" reversed and used as subdomain of e164.org, you get: ----------------- 8< ----------------- $ dig '*.0.9.9.9.2.8.8.e164.org' NAPTR ; <<>> DiG 8.3 <<>> *.0.9.9.9.2.8.8.e164.org NAPTR ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 0 ;; QUERY SECTION: ;; *.0.9.9.9.2.8.8.e164.org, type = NAPTR, class = IN ;; ANSWER SECTION: *.0.9.9.9.2.8.8.e164.org. 10M IN NAPTR 100 10 "u" "E2U+HTTP" \ "!.*!HTTP://www.freeworlddialup.com!" . *.0.9.9.9.2.8.8.e164.org. 10M IN NAPTR 100 10 "u" "E2U+SIP" \ "!^\\+8829990(.*)$!sip:\\1@fwd.pulver.com!" . ;; AUTHORITY SECTION: e164.org. 1D IN NS ns1.e164.org. e164.org. 1D IN NS ns2.e164.org. e164.org. 1D IN NS ns3.bcwireless.net. e164.org. 1D IN NS apollo.bcwireless.net. e164.org. 1D IN NS mutual.bcwireless.net. e164.org. 1D IN NS alberta.bcwireless.net. e164.org. 1D IN NS alberta-2.bcwireless.net. ;; Total query time: 476 msec ;; FROM: em.no-ip.com to SERVER: default -- 192.168.0.1 ;; WHEN: Mon Aug 22 18:39:52 2005 ;; MSG SIZE sent: 42 rcvd: 329 ----------------- 8< ----------------- The line containing "E2U+SIP" (folded in the listing for better visibility) contains in its last parameter an expression that, apart from minor differences in the backlash quoting syntax, is a 'sed' expression to convert numbers starting by "+8829990..." into their equivalent SIP URI's. For instance, after massaging the expression in a sed-friendly way let's apply it to +8829990123456 through the sed editor: $ echo '+8829990123456' | sed 's!^\+8829990\(.*\)$!sip:\1@fwd.pulver.com!' sip:123456@fwd.pulver.com Voila! this tells you that the number expressed in E.164 format as "+8829990123456" can be reached with SIP as user "123456" through the proxy fwd.pulver.com . (There are also "iax2:" URI's, "h323:" URI's and, for POTS lines on the PSTN, "tel:" URI's. And you can also register "http:" or "mailto:" URI's, if you like to associate a telephone number to non-telephonic resources. So how does the "e164.org" domain name come into the picture? Well, when the ENUM standard was agreed upon, the idea was that all the telcos, who "own" the E.164 telephone number address space, would have registered their numbers under e164.arpa . That registry, however, is a kind of "big boys club": forget about your applications being accepted if you are not a big telco affiliated to the ITU. So the good folks of www.e164.org decided to set up a free alternative ENUM registry that everybody is welcome to join. Of course, the resolvers will have to be configured to search not only for DNS records under e164.arpa, but also under e164.org (and any other similar registry). Collisions are not a problem, as long as the applications understand that more than one URI, even with the same protocol, may be returned for a given number. > What can be done to > accelerate its spread, or compensate for its absence? The real reason behind the scarce deployment is that providers, as I said in my previous message, are jealous custodians of their customers, and just hate the idea of them being reachable and capable of placing calls without their intervention. Think about it: once a user has a reasonably intelligent SIP phone or ATA, and can publish the relative URI through ENUM, what keeps him or her tied to his/her provider? Read the interesting article at http://www.vonmag.com/issue/2005/jul/features/enum.htm , particularly this part: [...] "We're also attempting to figure out a way to modify the current ENUM as it's defined, to include something that called 'Carrier ENUM' or 'infrastructure ENUM'," says McGarry. "ENUM was originally envisioned as a consumer service. I, Tom McGarry, can register my phone number with the ENUM registry and I can point those records to my SIP server on my PC in my basement that's connected to my DSL line. Therefore, I could be my own VoIP service provider. That's basically the concept. Typically, things that come out of the IETF have a 'grass roots' aspect to them. But carriers such as SBC, Verizon, AT&T and MCI have a need to provision ENUM information to facilitate the routing of VoIP calls, when they finally roll out VoIP. These carriers are trying to set up ENUM in such a way so that there's a space within ENUM where they control the records. Today, the consumer controls the records. It has always been expected that the majority of the ENUM records would be controlled by carriers as agents of the consumer." "But carriers want more control over the situation," says McGarry. "They want to control access to the records, because they don't want their network node addresses available on the public Internet. So they've been working on a way they can modify ENUM to include something called Carrier ENUM, which gives the carriers-the companies that were assigned telephone numbers by the number administrator-some greater control over the records in this section of ENUM. They're still in the middle of trying to figure out how to get that done." [...] So, it seems to me the right thing to do is what e164.org did: create unofficial registries not subject to the carriers'policies and schemes, and therefore the ITU's authority. Or, even better, take the plunge and devise P2P replacements of DNS and other centralized protocols... Cheers -- Enzo From wesley at felter.org Mon Aug 22 15:23:05 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P SIP tangent: phone numbers vs. user@host In-Reply-To: <0a6f01c5a728$c61dcf60$0200a8c0@em.noip.com> References: <1124702566.E92A750@di11.dngr.org> <1124702611.35AC0309@dj11.dngr.org> <0a6f01c5a728$c61dcf60$0200a8c0@em.noip.com> Message-ID: <4309EDD9.3060403@felter.org> ENUM is interesting, but I think it's a waste of time for computer-to-computer calls (not to mention terrible usability). I think numbers should be used for dialing only when they're *real* E.164 phone numbers (issued by NANPA or some international equivalent). For computer-to-computer VoIP, let's just use user@host, like email, Jabber, etc. This also eliminates the "walled garden" problem, because user@host is a context-free, explicitly hierarchical namespace. Fake "phone numbers" are a mess, because you have to remember to "dial" *279603722 before a FWD number, and #9586739205 before a Gizmo number, etc. Wes Felter - wesley@felter.org From enzomich at gmail.com Mon Aug 22 23:29:55 2005 From: enzomich at gmail.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] P2P SIP tangent: phone numbers vs. user@host References: <1124702566.E92A750@di11.dngr.org> <1124702611.35AC0309@dj11.dngr.org><0a6f01c5a728$c61dcf60$0200a8c0@em.noip.com> <4309EDD9.3060403@felter.org> Message-ID: <0b7401c5a771$75d40760$0200a8c0@em.noip.com> ----- Original Message ----- From: "Wes Felter" Sent: Monday, August 22, 2005 11:23 PM > ENUM is interesting, but I think it's a waste of time for > computer-to-computer calls (not to mention terrible usability). I think > numbers should be used for dialing only when they're *real* E.164 phone > numbers (issued by NANPA or some international equivalent). For > computer-to-computer VoIP, let's just use user@host, like email, Jabber, > etc. Oh, I agree. But the fact is, for voice communications phones are far better than computers, and phones have numeric keyboards where entering alphanumeric characters is awkward (or at least so it seems to an old geezer like me with scarce familiarity with SMS ;-) ). Let's face it: apart from us computer addicts, the rest of the population like to talk over a phone, just as they like watching movies in front of a proper TV set... That's why in these days USB handsets and cordless adapters for Skype sell like hot cakes: the computer that they still require, unlike "real" VoIP ATA's based on open protocols, is at least pushed in the background. Enzo From sg266 at cornell.edu Tue Aug 23 02:46:14 2005 From: sg266 at cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:01 2006 Subject: signalling level voip privacy & p2p (Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype?) In-Reply-To: <20050822135119.GA14618@bitchcake.off.net> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> <4ef5fec6050821224053c04ca1@mail.gmail.com> <1124709947.18653.17.camel@mazinger.u.cs.cornell.edu> <20050822135119.GA14618@bitchcake.off.net> Message-ID: <1124765174.30571.25.camel@localhost.localdomain> On Mon, 2005-08-22 at 09:51 -0400, Adam Back wrote: > You are talking about current protocols -- and even with current > protocols I think p2p does because without a central server it is > harder to tap -- you have to tap enough points to catch the call > negotiation you are interested in. Agreed. Although in some cases, as few as two tap-points can be enough (as demonstrated in the article I linked earlier). > Also at zero-knowledge systems they had a pseudonymous mail system. On the topic of anonymity, the only p2p network that is immune to packet correlations that I am aware of is P5 [1] -- where peers send noise (that models real data) when they don't have real data to send. The same approach can be extended to centralized approaches where endpoints randomly initiate fake calls and send noise to hide the real calls. Both approaches trade off level of anonymity for communication efficiency and have equivalent privacy properties. Barring the # of taps argument (which is mitigated by recent techniques as pointed out earlier), I'd appreciate pointers to p2p systems that represent a genuine security/privacy/anonymity advantage that cannot be applied to centralized ones. [1] http://www.cs.cornell.edu/People/egs/615/p5.pdf -- Saikat From adam at cypherspace.org Tue Aug 23 09:59:43 2005 From: adam at cypherspace.org (Adam Back) Date: Sat Dec 9 22:13:01 2006 Subject: signalling level voip privacy & p2p (Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype?) In-Reply-To: <1124765174.30571.25.camel@localhost.localdomain> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> <4ef5fec6050821224053c04ca1@mail.gmail.com> <1124709947.18653.17.camel@mazinger.u.cs.cornell.edu> <20050822135119.GA14618@bitchcake.off.net> <1124765174.30571.25.camel@localhost.localdomain> Message-ID: <20050823095943.GA4807@bitchcake.off.net> In [2] Anton Stiglic, Ulf Moeller and I describe both Wei Dai's pipenet, and zero-knowledge systems freedom network and how they stand up to various attacks. Certainly these systems, like the ones cited in the p5 paper you reference (and the p5 algorithm itself) benefits from the fact that with a p2p system there are multiple actors. ie The user intentionally does not have to trust a single anonymity provider (as would be the case eg with something more centralized, like anonymizer.com's web browsing system.) Wei Dai in pipenet for example proposes mixing connection establishment packets. Also cebolla [3] has a related passive adversary view (though not global passive adversary as in p5). However our observation in [2] is that perhaps the passive adversary is not that realistic a model. When even regular users can introduce latency etc, it seems reasonable to assume that someone with the resources to mount a network global passive attack, can also inject in-protocol noise. (I have not read the p5 paper properly yet, but I see it has some descriptions of such attacks and how it resists, but I find it unlikely that it resists both the DoS/starvation attack we describe applying to pipenet and the cheap timing correlation attacks we describe as applying to systems like the freedom network). An interesting area tho I think for signalling because it is low bandwidth, and somewhat tolerant of latency is to use concepts like PIR (private information retrieval), where it is possible for example to implement computationally secure single database PIR. That together with per caller handles -- eg if receivers have different call identifiers for different callers, established by prior arrangement, perhaps they can signal via a PIR like system even with a single central server. Adam [2] Apr 01 - "Traffic Analysis Attacks and Trade-Offs in Anonymity Providing systems", Information Hiding 2001, Adam Back, Ulf M?ller and Anton Stiglic http://www.cypherspace.org/adam/pubs/traffic.pdf [3] http://www.cypherspace.org/cebolla/ On Mon, Aug 22, 2005 at 10:46:14PM -0400, Saikat Guha wrote: > On Mon, 2005-08-22 at 09:51 -0400, Adam Back wrote: > > You are talking about current protocols -- and even with current > > protocols I think p2p does because without a central server it is > > harder to tap -- you have to tap enough points to catch the call > > negotiation you are interested in. > > Agreed. Although in some cases, as few as two tap-points can be enough > (as demonstrated in the article I linked earlier). > > > Also at zero-knowledge systems they had a pseudonymous mail system. > > On the topic of anonymity, the only p2p network that is immune to packet > correlations that I am aware of is P5 [1] -- where peers send noise > (that models real data) when they don't have real data to send. The same > approach can be extended to centralized approaches where endpoints > randomly initiate fake calls and send noise to hide the real calls. Both > approaches trade off level of anonymity for communication efficiency and > have equivalent privacy properties. > > Barring the # of taps argument (which is mitigated by recent techniques > as pointed out earlier), I'd appreciate pointers to p2p systems that > represent a genuine security/privacy/anonymity advantage that cannot be > applied to centralized ones. > > [1] http://www.cs.cornell.edu/People/egs/615/p5.pdf From coderman at gmail.com Tue Aug 23 17:50:01 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: signalling level voip privacy & p2p (Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype?) In-Reply-To: <20050823095943.GA4807@bitchcake.off.net> References: <07af01c5a6b4$eb527160$0200a8c0@em.noip.com> <430926A6.9030806@quinthar.com> <4ef5fec6050821224053c04ca1@mail.gmail.com> <1124709947.18653.17.camel@mazinger.u.cs.cornell.edu> <20050822135119.GA14618@bitchcake.off.net> <1124765174.30571.25.camel@localhost.localdomain> <20050823095943.GA4807@bitchcake.off.net> Message-ID: <4ef5fec605082310506c908bac@mail.gmail.com> On 8/23/05, Adam Back wrote: > ... > An interesting area tho I think for signalling because it is low > bandwidth, and somewhat tolerant of latency is to use concepts like > PIR (private information retrieval), where it is possible for example > to implement computationally secure single database PIR. the pynchon gate is a PIR technique that may be of interest: http://www.abditum.com/~rabbi/pynchon.pdf also, reencryption mix networks may be useful for low bandwidth signalling communication. (though you significantly raise bandwidth requirements as you scale such a network) http://www.syverson.org/univrenc-ctrsa.pdf best regards, From p2phack at cilux.org Fri Aug 26 18:54:40 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <4308CF1F.6010504@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> Message-ID: <430F6570.90408@cilux.org> I Googled, but neither 'F2F' (friend-to-friend) nor 'Darknet' are discussed in the P2P-hackers archives. Are P2P-hackers just not interested in them? -------------------------------------- Putting Darknets into context, private-to-public is a continuum: -: data owned by just me (total privacy - not our concern in P2P) -: data owned by me and you (not P2P either: encrypted email) -: data owned by a group (F2F/Darknet) -: data owned by a larger group (!) -: data owned by everyone; i.e. no-one (anonymous P2P) The bigger the group, the less private (more public) is something published within the group, when everyone is potentially identified, and the more anonymous is anything published in the name of the group to people outside it. People inside the group are also part of the potential recipients when publishing in the name of the group, so, through appropriate technology, it is possible to achieve anonymity in the eyes of everyone in proportion to the size of the group. If the group is everyone, it is possible to achieve complete anonymity when the technology supports it. Anonymous P2P such as Freenet, AntsP2P, MUTE, I2P, Napshare and GNUnet are technologies supporting that, completely public, end of the scale. If you want to use a Darknet technology, then clearly you have to be able to trust it, both to keep your private activities private, and, where this functionality is required, to support publishing in the name of the group without others being able to trace it back to you. Normally, we trust open technologies more than closed or commercial ones. -------------------------------------- So, what open F2F Darknets are there? I found two that seemed to fit the description and that had published information: WASTE and 'Freenet 2'. WASTE is only private in a group because the network itself is downscaled physically to the members of the group. Not the general-purpose, scalable solution we seek for our ambitions of global domination, um, that is, for the obvious goal of being able to choose an arbitrary degree of privacy or publicity, of anonymity, dynamically and on a file-by-file or chat-by-chat basis. So, on to 'Freenet 2': Ian Clarke and Oskar Sandberg's DEFCON slides: http://www.math.chalmers.se/%7eossa/defcon13/vegas1_print.pdf But, and this is where I may have misread the slides or there may be more to it than I got from the slides: this /isn't/ about a Darknet - in spite of the starting and ending slides' assertions - it seems to be about the same small-world P2P that's all the rage in PDF-research-land (and much discussed on this list) - unstructured (non-DHT) P2P network query and routing optimisation. Out-of-band peer introduction was mentioned, including needing a trusted rendezvous for NAT-ed peers. But limiting connections to trusted friends in itself creates a small WASTE-like network - otherwise, how do you prevent leakage, without adding the enforcement of ACLs (which was not mentioned in the slides)? In other words, the goals of the Darknet (privacy for small groups) are opposite to those of both of Freenet and seemingly also 'Freenet 2' (anonymity, public publishing and querying). I hope more details will come out to clarify this issue. In the meantime, I'm still left with the surprising conclusion that no-one is implementing the global Darknet (or 'Friendnet') in an open way!! Duncan B. Cragg Footnote: Closed or commercial approaches that apparently implement some kind of Darknet: I've mentioned Imeem before, and there's also WiredReach, NodeZilla, Groove, KDrive, KDX and SpinXpress. WiredReach is actually a possibility now that it's been opened up (wiredreach.org). It uses JXTA and XMPP rather than a special protocol, but I'm not sure how it does Darknet functions: certainly XMPP doesn't do group chat (even if Jabber may). WiredReach is a commercial entity, but that needn't mean it's not trustworthy... NodeZilla is closed (the 'Network Agent' isn't open even though the client is), but apparently achieves 'ACL' functionality through sharing so-called 'magnet' keys to allow access to data. From lgonze at panix.com Fri Aug 26 19:40:13 2005 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] cellcash Message-ID: <430F701D.7000100@panix.com> http://www.nytimes.com/2005/08/25/technology/circuits/25pogue.html?pagewanted=2 ... To prevent spammers and other abusers from snapping up Gmail accounts by the thousands, Google has designed a clever safeguard: when you apply for a Gmail account, you must provide a cellphone number. Google sends a code to your phone, which you use to complete the registration. ... This is hashcash, almost, except that what it uses for a backstop isn't CPU time but the fact that cell calls are always metered. Those Google fellows sure are clever. - Lucas From wesley at felter.org Fri Aug 26 20:02:50 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F6570.90408@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> Message-ID: <430F756A.8080908@felter.org> Duncan B. Cragg wrote: > > I Googled, but neither 'F2F' (friend-to-friend) nor 'Darknet' are > discussed in the P2P-hackers archives. Are P2P-hackers just not > interested in them? Some people seem to have the definitions a little mixed up IMO. Darknet: "a collection of networks and technologies used to share digital content" -- Biddle, England, Peinado, and Willman. The "dark" aspect connotes that they're really talking about sharing content *illegally*, against the wishes of its owner. Friendnet: "a network topology where every TCP/IP connection is backed up by a meatspace connection" -- Gonze (synonyms: F2F, small-world network) The darknet is really a legal construction, not a technical one. For whatever reason, politics doesn't come up much on this list. (I'm happy to see it remain that way.) But why haven't friendnets taken off? I don't know. Maybe because they're really hard, and their primary beneft is to resist attacks that are not yet commonplace. Wes Felter - wesley@felter.org From p2phack at cilux.org Fri Aug 26 20:06:25 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] cellcash In-Reply-To: <430F701D.7000100@panix.com> References: <430F701D.7000100@panix.com> Message-ID: <430F7641.1060803@cilux.org> Lucas Gonze wrote: > > http://www.nytimes.com/2005/08/25/technology/circuits/25pogue.html?pagewanted=2 > > ... > To prevent spammers and other abusers from snapping up Gmail accounts by > the thousands, Google has designed a clever safeguard: when you apply > for a Gmail account, you must provide a cellphone number. Google sends a > code to your phone, which you use to complete the registration. > ... > > This is hashcash, almost, except that what it uses for a backstop isn't > CPU time but the fact that cell calls are always metered. > > Those Google fellows sure are clever. > - Lucas > This may seem innocent and shallow, but maybe there's a deeper Google strategy at work: http://blogs.thedeal.com/2005/08/google_quietly_.html I'm no conspiracy theorist, but getting all those mobile phone numbers sure looks like another juicy pile of data for their mining algorithms... Duncan From wesley at felter.org Fri Aug 26 20:07:09 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] cellcash In-Reply-To: <430F701D.7000100@panix.com> References: <430F701D.7000100@panix.com> Message-ID: <430F766D.6090607@felter.org> Lucas Gonze wrote: > > http://www.nytimes.com/2005/08/25/technology/circuits/25pogue.html?pagewanted=2 > > ... > To prevent spammers and other abusers from snapping up Gmail accounts by > the thousands, Google has designed a clever safeguard: when you apply > for a Gmail account, you must provide a cellphone number. Google sends a > code to your phone, which you use to complete the registration. > ... > > This is hashcash, almost, except that what it uses for a backstop isn't > CPU time but the fact that cell calls are always metered. (I didn't read the article or try this out myself. Sorry.) Is it a call or an SMS? SMSes are pretty cheap and can be processed automatically. Can you sign up for multiple Gmail accounts using the same cell number? My guess would be no, in which case Google is imposing a much larger cost than just an SMS. (Looking at the Web page answers some of these questions. It is an SMS, and "Phone numbers are also stored to manage the number of accounts created per phone.") Wes Felter - wesley@felter.org From codewarrior at cuseeme.de Fri Aug 26 20:13:46 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:13:01 2006 Subject: Fwd: [p2p-hackers] cellcash References: <430F7641.1060803@cilux.org> Message-ID: <4EE52D16-CE2F-484A-A3CD-14CBA5084CA1@cuseeme.de> someone brainfarted >> Those Google fellows sure are clever. > looks like another juicy pile of data for their > mining algorithms... was my first thought too;-) cheers marc -- "Fernsehen ist Kaugummi f?r die Augen. "(Orson Welles) Les Enfants Terribles www.let.de From p2phack at cilux.org Fri Aug 26 20:20:16 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F756A.8080908@felter.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <430F756A.8080908@felter.org> Message-ID: <430F7980.1050306@cilux.org> Wes Felter wrote: >> >> I Googled, but neither 'F2F' (friend-to-friend) nor 'Darknet' are >> discussed in the P2P-hackers archives. Are P2P-hackers just not >> interested in them? > > > Some people seem to have the definitions a little mixed up IMO. > > Darknet: "a collection of networks and technologies used to share > digital content" -- Biddle, England, Peinado, and Willman. > The "dark" aspect connotes that they're really talking about sharing > content *illegally*, against the wishes of its owner. > Well, I also took my definition from four sources: Wikipedia, Microsoft's original Darknet .doc, the website of the Darknet book, and Ian Clarke's slides, where it is defined roughly as, well, this: > Friendnet: "a network topology where every TCP/IP connection is backed > up by a meatspace connection" -- Gonze (synonyms: F2F, small-world network) BTW, I thought I'd made up 'friendnet' as I was typing the email! And I normally Google everything before I eat it.. =0) And there is definitely some confusion in the use of 'small world network': P2P researchers use it one way (for optimising the topology), F2F-ers another (apparently, then, as a synonym for F2F) - this may be the source of the apparent mix-up in the 'Freenet 2' slides. > The darknet is really a legal construction, not a technical one. For > whatever reason, politics doesn't come up much on this list. (I'm happy > to see it remain that way.) Me too. >:-/ > But why haven't friendnets taken off? I don't know. Maybe because > they're really hard, and their primary beneft is to resist attacks that > are not yet commonplace. Really hard? Some of the stuff I've seen in P2P generally looks really hard to me.. And there's more to P2P than resisting attacks, like being a useful technology for sharing photos.. =0) (I know that's not the /raison d'etre/ of this list, but there are a lot of subscribers here involved in 'civil' applications). Cheers! Duncan From lgonze at panix.com Fri Aug 26 20:37:05 2005 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F756A.8080908@felter.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <430F756A.8080908@felter.org> Message-ID: <430F7D71.8060100@panix.com> Wes Felter wrote: > But why haven't friendnets taken off? I don't know. Maybe because > they're really hard, and their primary beneft is to resist attacks > that are not yet commonplace. Also because they're invisible, so they don't generate publicity. I have been a member of several ad-hoc friendnets using email, HTTP, etc. This is useless to me for the filesharing aspects, since I don't touch unauthorized distribution, but I value it a lot for the privacy. - Lucas From wesley at felter.org Fri Aug 26 20:38:52 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F7980.1050306@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <430F756A.8080908@felter.org> <430F7980.1050306@cilux.org> Message-ID: <430F7DDC.6040504@felter.org> Duncan B. Cragg wrote: > Wes Felter wrote: >> But why haven't friendnets taken off? I don't know. Maybe because >> they're really hard, and their primary beneft is to resist attacks >> that are not yet commonplace. > > Really hard? Some of the stuff I've seen in P2P generally looks really > hard to me.. And there's more to P2P than resisting attacks, like being > a useful technology for sharing photos.. =0) (I know that's not the > /raison d'etre/ of this list, but there are a lot of subscribers here > involved in 'civil' applications). I think just about any P2P app (e.g. private photo sharing within groups) could be built with some combination of DHTs, FEC, crypto, capabilities, and pet names. (Consider ePOST as an example.) The only additional benefit of a friendnet IMO is attack-resistance. (And in the post-Grokster climate, *all* of us Americans are working on legitimate P2P applications... :-) ) Wes Felter - wesley@felter.org From ap at hamachi.cc Fri Aug 26 22:41:18 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] cellcash In-Reply-To: <430F7641.1060803@cilux.org> References: <430F701D.7000100@panix.com> <430F7641.1060803@cilux.org> Message-ID: <430F9A8E.8020002@hamachi.cc> Duncan B. Cragg wrote: > I'm no conspiracy theorist, but getting all those mobile phone > numbers sure looks like another juicy pile of data for their > mining algorithms... Agreed. Their services are getting more and more intrusive with every new offering. Spam protection sounds like an incredibly lame excuse given that they are using very strong captchas on the same signup page. Alex From coderman at gmail.com Fri Aug 26 23:59:29 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F6570.90408@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> Message-ID: <4ef5fec60508261659b5b8cbd@mail.gmail.com> On 8/26/05, Duncan B. Cragg wrote: > > I Googled, but neither 'F2F' (friend-to-friend) nor 'Darknet' are > discussed in the P2P-hackers archives. Are P2P-hackers just not > interested in them? i think the interest is here; perhaps terminology is more a culprit :) i am working on these types of networks with a few friends but we don't have any public details available yet. my rambling commentary instead: > Putting Darknets into context, private-to-public is a continuum: > > -: data owned by just me (total privacy - not our concern in P2P) this is a critical component of secure identities (or pseudonyms) within a F2F or dark net. some secrets must be strongly protected. i'm thinking of loop-AES protected filesystems here. as a side note, we recently setup a secure wireless vpn at defcon to show that strong authentication and privacy for wireless networks is possible without esoteric and complicated technology. the IPsec vpn server has a dead man's trigger connected to the reset switch on both boards - if your hardware is in jeopardy you can release the trigger to flush all key information from memory rendering the aes encrypted filesystems opaque as well as terminating all active network sessions immediately: peertech.org/janus/defcon.html good session management for authenticated communication is important; while of very little practical utility the dead man's trigger shows how you can make authenticated session duration an explicitly defined state subject to your continued affirmation of system integrity. > -: data owned by me and you (not P2P either: encrypted email) this could also encompass shared secrets used for authentication and/or encryption between two peers in a larger network. > -: data owned by a group (F2F/Darknet) > -: data owned by a larger group (!) > -: data owned by everyone; i.e. no-one (anonymous P2P) > > The bigger the group, the less private (more public) is something > published within the group, when everyone is potentially identified, and > the more anonymous is anything published in the name of the group to > people outside it. People inside the group are also part of the > potential recipients when publishing in the name of the group, so, > through appropriate technology, it is possible to achieve anonymity in > the eyes of everyone in proportion to the size of the group. If the > group is everyone, it is possible to achieve complete anonymity when > the technology supports it. this is a difficult problem. what do you consider a trustworthy group size to ensure adequate anonymity? how does latency of anonymous interactions affect the type and scope of communication performed over it? (for example, universal reencryption mix networks are usable for smaller networks with small payloads, they do not scale well, etc) the Freehaven project (freehaven.net) covers a lot of this well. making the boundary between the different levels/types of pseudonymity/anonymity well defined and robust is really tricky. > If you want to use a Darknet technology, then clearly you have to be > able to trust it, both to keep your private activities private, and, > where this functionality is required, to support publishing in the name > of the group without others being able to trace it back to you. > Normally, we trust open technologies more than closed or commercial > ones. yes; strong privacy requires strong security which is difficult on many different levels. an open source implementation allows independent validation of the security controls built into the network and encourages more oversight of the design and operation of the network than is usually possible with a closed source product hindered by profit motives and press relations. but that is just my unbiased opinion. ;) > So, on to 'Freenet 2': Ian Clarke and Oskar Sandberg's DEFCON slides: > ... > Out-of-band peer introduction was mentioned, including needing a trusted > rendezvous for NAT-ed peers. But limiting connections to trusted friends > in itself creates a small WASTE-like network - otherwise, how do you > prevent leakage, without adding the enforcement of ACLs (which was not > mentioned in the slides)? there are two methods for initial and transitive introduction of peers in a dark/F2F network we are developing: - trusted initial introduction with meatspace key exchange. i like the use of shared secrets / OTP for master keys on such a network (used to exchange session keys for secure channels between peers). sometimes cumbersome key management is a feature, as it can provide additional constraints on the topology of connections between users of the network (if that makes sense). our darknet is live linux ISO based so that a large amount of encrypted key material can be included when you master an ISO for a friend you want to key into the network. this is another aspect of open source implementations that is useful: they can be freely and pervasively copied. various resources (files, metadata, etc) can also be cached on DVD ISO images as there is usually plenty of space on a linux live DVD. aggressive caching is important for these types of networks but i'm already straying off topic here... - transitive introduction using arbitrary peer grouping and implicit feedback / profiling. i don't have information on alpine available (perhaps archive.org kept a copy?) that describes how implicit feedback in user defined peer groups is useful for transitive introduction. the basic premise is that you ask peers who are useful to you for other peers who may be useful in turn, where 'useful' is an attribute defined by implicit feedback from your interaction with that peer and the resources the peer has provided. if you continue to "cultivate" your peer groups over time by removing peers who are not helpful and adding new peers referred to you from those who are helpful the effectiveness of resource discovery can be continually improved, even for rare / obscure domains of search where exhaustive/complete search is usually required to be effective. feedbackfs is an example of the type of implicit feedback desired to evaluate peer "utility" and also highlights the need for strong privacy of your own domain due to the detailed usage statistics gathered about your use of file resources obtained via the network. - transitive introduction using an external network with specific constraints. as an example we intend to use wireless broadcast to support transitive introduction of peers located in your vicinity. in this way you could add peers and resources located close by which may be useful. > In the meantime, I'm still left with the surprising conclusion that > no-one is implementing the global Darknet (or 'Friendnet') in an open > way!! i tend to agree with Wes; these networks are difficult and of limited interest right now. a lot of people are working on the various pieces that would be needed to build it. like Wes mentioned: "just about any P2P app could be built with some combination of DHTs, FEC, crypto, capabilities, and pet names." and speaking of pet names, i'm anticipating using sfs or equivalent as the underlying store for all darknet data while a user friendly view (the usual paths and such) are overlaid on top of the secure sfs identifiers via pet names shared among trusted peers. each peer can share a signed pet name index with others and your interaction with the pet name space on top of the secure ID filesystem (sfs/etc) another good source of implicit feedback. best regards, --- looks like archive.org has some old copies of the alpine pages: http://web.archive.org/web/20041013082304/peertech.org/alpine/ and google still has a cached copy of the feedbackfs post on implicit file system feedback applied to resource discovery: http://www.google.com/search?hl=en&lr=&q=peertech.org+implicit+feedback From paul at ref.nmedia.net Sun Aug 28 18:30:31 2005 From: paul at ref.nmedia.net (Paul Campbell) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Oblivious information dispersal? Message-ID: <20050828183031.GA22375@ref.nmedia.net> I'm not sure what the terminology is here but I've been thinking about the whole concept of PIR and that got me going on a different tangent. As I see it, PIR looks to be somewhat useless right now. The reason is simple. The idea is to obscure (anonymize) the receiver of the file/information. So PIR does this by exchanging packets in plain view. It is easy to identify the fact that communication is occurring but not easy to identify what the transaction is all about. The alternative is to cloak the actual source of the transaction but the nature of the transaction is pretty clear. That's exactly what the various proxying schemes do. Whether implementing via the more bandwidth demanding Dining Cryptographers route or simply via tunneling (onion routing) doesn't really matter. The issue at hand is that proxying only takes about 3 "hops" to cloak the potential source as I understand it from a relatistic point of view. So since each "hop" increases the communication by one packet, then for instance a 3-hop system increases bandwidth by 3 times. And if we consider the reverse path (obviously we must), then double that, or 2N-fold increase in bandwidth usage. PIR also adds significant computational overhead and I just haven't seen a similar head-on comparison which doesn't get into really ridiculous amounts of bandwidth, although potentially it could be competitive. Either way, the other issue is to obscure the "publisher" side of things... the source of information. There is a "PIS" form of things but I'm not sure how much it would be valid in this situation. The goal here is to disguise the source of say a file in the database. This is again easy to do with proxying but again adds a factor of 2N in cloaking the path to the publisher where the endpoint of the path points to a proxy. But even having said all that, here's where I'm going with this. Consider the database across which the PIR or proxying shceme is operating. At some point, we have to have a "public" part of the database...the part where you map a query onto some piece of data. I can see a scenario where for instance a node is accused of being an accessory to piracy...because you could easily do a search for say "Star Wars" or "Britney Spears" and see if any of the queries pop up your own IP address. What I'm interested in is much further along. How can we successfully hide database references "in plain site"? In other words, so that say the Britney Spears file (or pointer information) is distributed out over multiple nodes such that even if you can determine that some fraction of a bit contains a reference to the "bad seed", the local node database does not contain a substantial amount of information in and of itself. Thus, even if you did determine that a piece of the offending data is somehow present, it is pointless to delete it since redundancy gaurantees that enough of the information is still out there that your contribution does little to nothing. And on top of that, that plausible deniability is still maintained at some meaningful level. In my mind, this could potentially do two things. First, it would be yet another route to do PIR...users could directly make queries but since the nature of the query is spread out over a dozen or more nodes, and the bits by themselves are fractional, it's still not possible to tell computationally what the goal of the query is. Second, it makes plausible deniability very easy to achieve...the database itself can't really tell what's in it's own data since it is colluded with lots of other unrelated data and it would be necessary to have ALL the keys to the mixed data to determine what is there. This really only leaves an issue of disguising the tracks of the publishers since they are the only ones who can potentially be aware of what data is present in a given location at a given time when they mix the new information into the system...and they can be covered again with proxying although I hope that the query volume outstrips the publishing volume. Anyways...is there such an animal? Does what I'm trying to say make sense? From mfreed at cs.nyu.edu Sun Aug 28 21:19:44 2005 From: mfreed at cs.nyu.edu (Michael J. Freedman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Oblivious information dispersal? In-Reply-To: <20050828183031.GA22375@ref.nmedia.net> References: <20050828183031.GA22375@ref.nmedia.net> Message-ID: On Sun, 28 Aug 2005, Paul Campbell wrote: > PIR also adds significant computational overhead and I just haven't seen a > similar head-on comparison which doesn't get into really ridiculous amounts of > bandwidth, although potentially it could be competitive. The main goal of PIR schemes is o(n) bandwidth overhead, where n is the size of the database. (Otherwise, a linear-bandwidth PIR solution is trivial: send the entire database.) In '99, Cachin, Micali, and Stadler presented the first polylog PIR scheme. http://citeseer.ist.psu.edu/cachin99computationally.html Much more recently (ICALP 2005), Gentry and Ramzan presented a PIR scheme with constant bandwidth. Still, a *costly* part of PIR schemes is the computation overhead (which is generally linear in the size of the database), not the communication overhead which protocols have mostly sought to minimize. > In my mind, this could potentially do two things. First, it would be yet > another route to do PIR...users could directly make queries but since the > nature of the query is spread out over a dozen or more nodes, and the bits > by themselves are fractional, it's still not possible to tell computationally > what the goal of the query is. Second, it makes plausible deniability very > easy to achieve...the database itself can't really tell what's in it's own All of these protocols above, and actually what I think this thread has centered about, are about computationally-secure single-server PIR. In fact, most work in PIR has focused on info-theoretically-secure multi-server PIR, in which databases are replicated across multiple servers, and the protocol is effectively taking XORs of various shares of the servers to recombine into the original data. Still, the best results to date are not yet really practical. http://www.cs.technion.ac.il/~yuvali/pubs/BIKR02.ps What I think you are proposing is a more ad-hoc technique that these protocols: Given a file, break it up into shares (by a secret sharing scheme, for instance, or just XORing random bits) and spread those shares across servers. Or, to add more "plausible deniability" by making those shares not linked to any specific file, mix the shares from various files together, so that Britney and the Declaration of Independence can both be regenerated from some share s_i. Some examples of such systems include: Private message service http://www.inf.fu-berlin.de/~berthold/publ/BCKP_02.pdf Tangler http://www.cs.nyu.edu/~waldman/tangler.ps See the related work in these papers for more citations. However, the general difference between these proposals and PIR---and similarly between MIX/proxy-based schemes and PIR as well---is that the latter's security is formally provable via traditional reduction-based techniques, while the former's security is ad-hoc and ill-defined. Of course, this formal security comes at the cost of performance. --mike ----- www.michaelfreedman.org www.coralcdn.org From m.rogers at cs.ucl.ac.uk Sun Aug 28 22:48:49 2005 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F6570.90408@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> Message-ID: <43123F51.5060102@cs.ucl.ac.uk> Hi Duncan, > But, and this is where I may have misread the slides or there may > be more to it than I got from the slides: this /isn't/ about a Darknet - I think "darknet" can refer to the visibility of the network as well as the visibility of content. Freenet 0.7 is a darknet in the sense that only your friends know you're part of the network. Users can see all the content in the network, but they can't see all the participants. > limiting connections to trusted friends > in itself creates a small WASTE-like network - otherwise, how do you > prevent leakage, without adding the enforcement of ACLs (which was not > mentioned in the slides)? Sorry, what do you mean by leakage? Freenet's aim is to prevent publishers and readers from discovering one another's identities, not to restrict the propagation of files. > In other words, the goals of the Darknet (privacy for small groups) are > opposite to those of both of Freenet and seemingly also 'Freenet 2' > (anonymity, public publishing and querying). I don't agree that anonymity is the opposite of privacy. If only your friends know you're part of the network, and even your friends don't know which files you read and publish, then how does that undermine the goal of privacy for small groups? > In the meantime, I'm still left with the surprising conclusion that > no-one is implementing the global Darknet (or 'Friendnet') in an open > way!! I've been working on a scalable, robust, anonymous F2F communication network for the last three years - but as for "implementing", it might be a while yet. :-) Cheers, Michael From m.rogers at cs.ucl.ac.uk Sun Aug 28 23:22:08 2005 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <430F7980.1050306@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <430F756A.8080908@felter.org> <430F7980.1050306@cilux.org> Message-ID: <43124720.5070904@cs.ucl.ac.uk> Duncan B. Cragg wrote: > And there is definitely some confusion in the use of 'small world > network': P2P researchers use it one way (for optimising the topology), > F2F-ers another (apparently, then, as a synonym for F2F) - this may be > the source of the apparent mix-up in the 'Freenet 2' slides. As far as I know, both camps are referring to the same thing. A network is called a small world if it has a small diameter relative to its size (like a random network) and a high degree of clustering (unlike a random network). Social networks seem to have these characteristics, so we might expect F2F networks to have them too. The routing algorithm in Freenet 0.7 is based on Kleinberg's much more specific definition of a small world [1] - a regular lattice with a few additional random links that follow a certain probability distribution - but there are other kinds of network with small world characteristics, eg scale-free networks [2]. Cheers, Michael [1] http://www.cs.cornell.edu/home/kleinber/nat00.pdf [2] http://arxiv.org/pdf/cond-mat/9910332 From fxcabral at yahoo.com.br Mon Aug 29 03:08:47 2005 From: fxcabral at yahoo.com.br (=?ISO-8859-1?Q?Fabr=EDcio?= Barros Cabral) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] Caches solutions to P2P file-sharing systems Message-ID: <1125284927.8471.29.camel@hades.no-ip.org> Hello people! I'm searching about caches solutions to P2P file-sharing systems (KaZaA, eDonkey, BitTorrent) and basically I found two commercial solutions: 1) JoltId PeerCache [1] PeerCache is a P2P cache system based in a modified client (it uses a plugin) and a cache server. Using DNS requisitions, the client locates the cache server and it will send file requests to the cache, which works like a proxy system, getting the file and repass this file to the client. 2) CacheLogic Cachepliance [2] The CacheLogic solution is based in payload packet inspection, which recognize the P2P protocol (through a payload analisys) and perform a "transparent" cache to the clients. So, I'd like know if anyone has more information about these systems, mainly the CacheLogic solution, because the web system is very poor about it operation details. Thanks in advance, --fx [1] http://www.joltid.com/index.php/peercache/ [2] http://www.cachelogic.com/ _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ From p2phack at cilux.org Mon Aug 29 09:27:24 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <43123F51.5060102@cs.ucl.ac.uk> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <43123F51.5060102@cs.ucl.ac.uk> Message-ID: <4312D4FC.8030309@cilux.org> Michael: Is 'Freenet 2' as I have been referring to it, 'Freenet 0.7' officially? Sorry to Freenet if I missed that... >> But, and this is where I may have misread the slides or there may >> be more to it than I got from the slides: this /isn't/ about a Darknet > > I think "darknet" can refer to the visibility of the network as well as > the visibility of content. Freenet 0.7 is a darknet in the sense that > only your friends know you're part of the network. Users can see all the > content in the network, but they can't see all the participants. > >> limiting connections to trusted friends >> in itself creates a small WASTE-like network - otherwise, how do you >> prevent leakage, without adding the enforcement of ACLs (which was >> not mentioned in the slides)? > > Sorry, what do you mean by leakage? Freenet's aim is to prevent > publishers and readers from discovering one another's identities, > not to restrict the propagation of files. > So - 'Darknet' (this reminds me of those endless arguments that boil down to defining 'Object', by which time you've forgotten what you were arguing about!). Darknet privacy is: 1. only your friends know you're in, content 100% public ..or.. 2. content restricted by some form of access control. I was going for number 2., Freenet for number 1. It's all becoming clearer, now! Both are enabled by WASTE through limited physical topology, although 'content 100% public' is limited to the 'public' in the WASTE network. >> In other words, the goals of the Darknet (privacy for small groups) >> are opposite to those of both of Freenet and seemingly also >> 'Freenet 2'(anonymity, public publishing and querying). > > I don't agree that anonymity is the opposite of privacy. If only your > friends know you're part of the network, and even your friends don't > know which files you read and publish, then how does that undermine > the goal of privacy for small groups? > I'm using 'privacy for small groups' to mean the ability to publish freely within that group (with or without that group knowing it was you), but (this is the difference) /not at all outside/ the group. Now, if something /were/ published in the name of the group, the anonymity is proportional to the size of the group when its members are known: perhaps an academic concept rather than a practical one (OK, it was me that started it, with my 'private to public continuum'!). The purpose of my version of privacy is to allow social interaction to oil the wheels of exchange: -: we do know each other and know our common interests. -: we can talk privately about them and exchange materials within our group without anyone else knowing anything at all about these activities. -: we form part of many groups in the 'global darknet' -: we can choose the diameter of our groups down to a file-by-file or chat-by-chat basis. -: we can publish to a group, or to everyone (the biggest group), with or without identifying ourselves. -: stuff can propagate out by jumping from group to group (as postulated in the MS Darknet paper). Getting down to practical concerns, I'm looking for a starting point for my application: I need an open protocol (or open research on techniques) that support my number 2. above: privacy of content, not of participation! Glad we've got that cleared up (hopefully!) Duncan PS If you're the UCL Michael Rogers, thanks for the P2P links: http://www.cs.ucl.ac.uk/staff/mrogers/bibliography.html And say hi to UCL for me: I did EE/CS there, 83-86! From p2phack at cilux.org Mon Aug 29 10:28:24 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <43124720.5070904@cs.ucl.ac.uk> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <430F756A.8080908@felter.org> <430F7980.1050306@cilux.org> <43124720.5070904@cs.ucl.ac.uk> Message-ID: <4312E348.3000508@cilux.org> >> And there is definitely some confusion in the use of 'small world >> network': P2P researchers use it one way (for optimising the topology), >> F2F-ers another (apparently, then, as a synonym for F2F) - this may be >> the source of the apparent mix-up in the 'Freenet 2' slides. > > As far as I know, both camps are referring to the same thing. A network > is called a small world if it has a small diameter relative to its size > (like a random network) and a high degree of clustering (unlike a random > network). Social networks seem to have these characteristics, so we > might expect F2F networks to have them too. > > The routing algorithm in Freenet 0.7 is based on Kleinberg's much more > specific definition of a small world [1] - a regular lattice with a few > additional random links that follow a certain probability distribution - > but there are other kinds of network with small world characteristics, > eg scale-free networks [2]. > We could say an F2F network arises from meatspace connections being replicated in the P2P network. So an F2F network exists /a priori/ and can't be jiggled around much for the sake of routing, whereas our P2P algorithms can do what they like to reap the small-diameter benefits of small-world networks, perhaps using coderman-style implicit hints, from the social activity visible, to help. The point, though, was what Freenet is up to, and here we seem to have both: we definitely have an overlay network topology optimisation (nodes around the ring swapping position), but we also seem to have an F2F aspect, with a reference to out-of-band friendly connections. It may /have/ both, but I'm struggling to see the connection, as the slides seem to jump from F2F to Kleinberg... It doesn't explain what 'long' or 'short' connections mean in the F2F context. Please help by explaining, as I think I'm handicapped by only seeing slides and not having been at Defcon! Or perhaps I'm just dim... =0( Duncan From m.rogers at cs.ucl.ac.uk Mon Aug 29 11:48:34 2005 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <4312E348.3000508@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <430F756A.8080908@felter.org> <430F7980.1050306@cilux.org> <43124720.5070904@cs.ucl.ac.uk> <4312E348.3000508@cilux.org> Message-ID: <4312F612.60507@cs.ucl.ac.uk> Duncan B. Cragg wrote: > The point, though, was what Freenet is up to, and here we seem to have > both: we definitely have an overlay network topology optimisation (nodes > around the ring swapping position), but we also seem to have an F2F > aspect, with a reference to out-of-band friendly connections. I don't think Freenet is optimising the topology, strictly speaking, because no links are added or removed. What it's doing is arranging the nodes in the identifier space so that greedy routing is possible over the given topology. > It doesn't explain what 'long' or 'short' connections mean in the F2F > context. Again, this refers to the identifier space - the length of a link is the arithmetic distance between the identifiers of its endpoints (as in Chord). Cheers, Michael From m.rogers at cs.ucl.ac.uk Mon Aug 29 12:18:27 2005 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <4312D4FC.8030309@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <43123F51.5060102@cs.ucl.ac.uk> <4312D4FC.8030309@cilux.org> Message-ID: <4312FD13.9030200@cs.ucl.ac.uk> Duncan B. Cragg wrote: > So - 'Darknet' (this reminds me of those endless arguments that boil > down to defining 'Object', by which time you've forgotten what you > were arguing about!). :-) > Darknet privacy is: > > 1. only your friends know you're in, content 100% public > > ..or.. > > 2. content restricted by some form of access control. Maybe we can reconcile the two definitions: a darknet is an invitation-only network, or an invitation-only group within a larger network, where communication taking place inside the darknet is invisible to outsiders. (Or is that too vague?) > I'm using 'privacy for small groups' to mean the ability to > publish freely within that group (with or without that group knowing > it was you), but (this is the difference) /not at all outside/ the > group. It sounds like you're using the word "group" in the same sense that Freenet and WASTE use the word "network". How is a single network containing multiple groups different from multiple networks each containing a single group? Shared infrastructure maybe? > -: we can choose the diameter of our groups down to a file-by-file or > chat-by-chat basis. This sounds tricky to me - if any member of the group can invite another member, isn't access control out of the hands of any individual member? > Getting down to practical concerns, I'm looking for a starting > point for my application: I need an open protocol (or open research > on techniques) that support my number 2. above: privacy of content, not > of participation! So, just to clarify (sorry), you're looking for an open protocol to create invitation-only groups within larger content-sharing networks, as opposed to invitation-only networks (like WASTE)? > And say hi to UCL for me: I did EE/CS there, 83-86! I'll give them a wave - the new CS building is next to engineering (we like to pretend). :-) Cheers, Michael From coderman at gmail.com Mon Aug 29 14:06:23 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <4312D4FC.8030309@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <43123F51.5060102@cs.ucl.ac.uk> <4312D4FC.8030309@cilux.org> Message-ID: <4ef5fec605082907065ec3a58a@mail.gmail.com> On 8/29/05, Duncan B. Cragg wrote: > ... > I'm using 'privacy for small groups' to mean the ability to > publish freely within that group (with or without that group knowing > it was you), but (this is the difference) /not at all outside/ the > group. another way to think of this is distinct domains of resource visibility for 'private groups' within a much larger shared infrastructure. i like this approach because so many networks have to deal with the same issues over and over again, initial introduction to bootstrap into the network, transitive introduction to expand your horizon/group sizes. a sufficient pool of trusted users for decent anonymity, etc. sharing infrastructure in this manner (for example, an anonymizing mix network or PIR network) can provide significant improvements over a number of smaller, isolated subsets each providing their own. trust becomes more difficult though, which is why the delineation between what can and should be shared (a global GUID pseudonym), and what is private to a group (a signed filesystem archive) needs to be drawn carefully. > Now, if something /were/ published in the name of the group, > the anonymity is proportional to the size of the group when its > members are known: perhaps an academic concept rather than a > practical one (OK, it was me that started it, with my 'private to > public continuum'!). > > The purpose of my version of privacy is to allow social interaction > to oil the wheels of exchange: > > -: we do know each other and know our common interests. > -: we can talk privately about them and exchange materials within our > group without anyone else knowing anything at all about these > activities. > -: we form part of many groups in the 'global darknet' > -: we can choose the diameter of our groups down to a file-by-file or > chat-by-chat basis. > -: we can publish to a group, or to everyone (the biggest group), with > or without identifying ourselves. > -: stuff can propagate out by jumping from group to group (as postulated > in the MS Darknet paper). this is where the boundaries get interesting and i'm looking for additional resources on this subject. let me start off with a high level view of how we broke the distinct domains of peer organization into common types: at the root layer you have a personal space. this is where key management occurs and thus it is highly protected (the loop-AES file systems). at the mid layer you have group spaces. a group is simply an arbitrary collection of peers. all links between peers in a group are strongly authenticated. for example, it may consist of peers known in your F2F social network in meatspace. strongly authenticated means good key distribution, so mutually signed pub keys or out of band shared secret exchange may be necessary to establish such connections. the last layer is the public space, and your only interaction with public is via pseudonym or anonymously. this is due to the lack of strong authentication for peers discovered / communicated with in this realm. public is probably the easiest to understand intuitively as anything you might publish or do anonymously or as an opaque group would be a good candidate for shared infrastructure. when you get to group communication you need to address the roles peers will play in such groups. in our architecture we selected two distinct modes of group membership: group member, which means resources common to the group are available to you. this is like read only access. and group authority, which means you play a part in deciding the nature of resources available to the group and the membership within the group. the simplest authority would be a single peer who managed a particular group of interested member peers. an example of this configuration might be a newsletter with a single author. the members would constitute readers and the author the group authority. for multiple authorities we selected a quorum model requiring consensus for some or all of the group management functions. if you consider a software development team the quorum members or group authorities could be the developers with commit access. those who utilize the committed resources in the source tree could be the group members. consensus may be required to merge branches or build a release while any quorum member / group authority could commit their own changes to a working repository. one other aspect i will mention is that while groups support asymmetric membership/role types they are not required to be so. you could have a group where every peer is a quorum member, a fully decentralized organizational structure. to tie this back to our model a peer group performs the following functions: - manages peer membership within the group (this is obvious :). adding or removing peers requires consensus. (key management / distribution) - defines and distributes private resource collections. a resource collection in this case is a self-certifying collection of files identified by SHA hash and the authenticated pet names applied to these files to map them into a familiar namespace (like paths and vfolders, etc). this may or may not require consensus. - defines and provides public group resources to members outside of the group (the visibility of any resource would be subject to quorum approval, everything else is implicitly private to that group). someone will rightly note that requiring consensus among quorum members for certain operations will make large groups with many authorities potentially difficult to maintain. this is a feature! we wanted to avoid situations where a small trusted group of peers becomes a large untrusted group unintentionally. if a group cannot reach consensus (peer dies, meatspace drama, etc) then the state of the group is essentially frozen as no new directives related to private or public group resources (and membership) may be given. time to create a new group among those who can agree :) there are a lot of details missing here; documentation has taken a bit of a back seat to experimental design as getting the usability / intuitive interaction right is very difficult and distilling the already too complicated design down to bare essentials is taking longer than expected. in short, we define three domains of interaction between peers in the network (where 'network' is all shared infrastructure and all groups): - personal, where the secrets that define your identity are guarded. - group, where trusted peers act as quorum members to manage the group. - public, where any peer or group may distribute resources pseudonymous/anonymously. as one last note, i often mention the live linux DVD's as our chosen distribution mechanism. the reason for this is that exchange of the disc in meatspace can facilitate strong authentication between peers in arbitrary groups as part of the initial/transitive introduction process. it also is a convenient source of cache space for published group resources or other common information. this is a fun line of conversion; please keep us advised of additional resources you discover that are relevant to these types of relationships in large F2F/dark networks! From coderman at gmail.com Mon Aug 29 16:30:43 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] For fans of datagram Message-ID: <4ef5fec6050829093038cc0a78@mail.gmail.com> Datagram TLS now part of OpenSSL 0.9.8 - http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html From p2phack at cilux.org Mon Aug 29 17:59:58 2005 From: p2phack at cilux.org (Duncan B. Cragg) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <4ef5fec605082907065ec3a58a@mail.gmail.com> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <43123F51.5060102@cs.ucl.ac.uk> <4312D4FC.8030309@cilux.org> <4ef5fec605082907065ec3a58a@mail.gmail.com> Message-ID: <43134D1E.8020807@cilux.org> Martin: There's so much stuff in your emails that I haven't got time to digest it - thanks =0). > another way to think of this is distinct domains of resource > visibility for 'private groups' within a much larger shared > infrastructure. i like this approach because so many networks have to > deal with the same issues over and over again, initial introduction to > bootstrap into the network, transitive introduction to expand your > horizon/group sizes. a sufficient pool of trusted users for decent > anonymity, etc. > > sharing infrastructure in this manner (for example, an anonymizing mix > network or PIR network) can provide significant improvements over a > number of smaller, isolated subsets each providing their own. > > trust becomes more difficult though, which is why the delineation > between what can and should be shared (a global GUID pseudonym), and > what is private to a group (a signed filesystem archive) needs to be > drawn carefully. > Yup - I think we're both talking about the same 'global darknet' here. Let's assume that we are, and move on before anyone notices.. =0) > at the root layer you have a personal space. this is where key > management occurs and thus it is highly protected (the loop-AES file > systems). > > at the mid layer you have group spaces. a group is simply an > arbitrary collection of peers. all links between peers in a group are > strongly authenticated. for example, it may consist of peers known in > your F2F social network in meatspace. strongly authenticated means > good key distribution, so mutually signed pub keys or out of band > shared secret exchange may be necessary to establish such connections. > > the last layer is the public space, and your only interaction with > public is via pseudonym or anonymously. this is due to the lack of > strong authentication for peers discovered / communicated with in this > realm. public is probably the easiest to understand intuitively as > anything you might publish or do anonymously or as an opaque group > would be a good candidate for shared infrastructure. > Yup - sounds reasonable. What about when there is a chunk of data with a group or list of people who can share it - which is what I'm aiming for - then peer-to-peer crypto (link security) isn't enough? Isn't data encryption needed? Then it can be passed through intermediaries that aren't on the list. Of course, when the global network has a partition that is exactly those on the list, the data can be passed around 'in the clear' between them, just using link-level crypto. > when you get to group communication you need to address the roles > peers will play ..... peer is a quorum member, a fully > decentralized organizational structure. > > ... a peer group performs the following functions: > - manages peer membership within the group (this is obvious :). > adding or removing peers requires consensus. (key management / > distribution) > - defines and distributes private resource collections. a resource > collection in this case is a self-certifying collection of files > identified by SHA hash and the authenticated pet names applied to > these files to map them into a familiar namespace (like paths and > vfolders, etc). this may or may not require consensus. > - defines and provides public group resources to members outside of > the group (the visibility of any resource would be subject to quorum > approval, everything else is implicitly private to that group). > All this sounds very advanced, especially compared with what I'm doing - so I look forward to seeing it in action! Are pet names group-wide or individual? Zooko would probably say they were individual - presumably the reason for them (avoid clashes) isn't an issue in one of these groups. Did you say that each resource has a GUID/URL (opaque to human eyes)? My own plan has two kinds of reference: GUID/URLs (opaque) and a DAG structure (like a filesystem for humans to explore). > if a group cannot reach consensus (peer dies, meatspace drama, etc) > then the state of the group is essentially frozen as no new directives > related to private or public group resources (and membership) may be > given. time to create a new group among those who can agree :) > Oh - I love the phrase 'meatspace drama'!! Can I use it? =0) > there are a lot of details missing here; documentation has taken a bit > of a back seat to experimental design as getting the usability / > intuitive interaction right is very difficult and distilling the > already too complicated design down to bare essentials is taking > longer than expected. > Sounds like you've done what I've done: bitten off more than you can chew!! =0) I've been working full time on my own plans for eight months - and am nowhere near done. > in short, we define three domains of interaction between peers in the > network (where 'network' is all shared infrastructure and all groups): > - personal, where the secrets that define your identity are guarded. > - group, where trusted peers act as quorum members to manage the group. > - public, where any peer or group may distribute resources > pseudonymous/anonymously. > Cool. > this is a fun line of conversion; please keep us advised of additional > resources you discover that are relevant to these types of > relationships in large F2F/dark networks! > 'K.. Thanks for all the interesting material and concepts. I'm still pondering all that implicit semantics stuff... This bit: > transitive introduction using arbitrary peer grouping and implicit > feedback / profiling. .. ... implicit > feedback in user defined peer groups is useful for transitive > introduction. the basic premise is that you ask peers who are useful > to you for other peers who may be useful in turn, where 'useful' is an > attribute defined by implicit feedback from your interaction with that > peer and the resources the peer has provided. > > if you continue to "cultivate" your peer groups over time by removing > peers who are not helpful and adding new peers referred to you from > those who are helpful the effectiveness of resource discovery can be > continually improved, even for rare / obscure domains of search where > exhaustive/complete search is usually required to be effective. > Looking at the alpine archives (why did you wipe it? and also cubicmetercrystal?) and the NeuroGrid stuff, it looks like your petnames (and my DAG) are the key here: treat petnames as stuff that can be shared, then follow them around (or the peers that use them). Just a half-formed thought. I'll get back to you if any more neurons fire in this space... =0/ Cheers! Duncan From coderman at gmail.com Mon Aug 29 19:02:52 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:01 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <43134D1E.8020807@cilux.org> References: <4303D919.4080705@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <43123F51.5060102@cs.ucl.ac.uk> <4312D4FC.8030309@cilux.org> <4ef5fec605082907065ec3a58a@mail.gmail.com> <43134D1E.8020807@cilux.org> Message-ID: <4ef5fec6050829120221073f7d@mail.gmail.com> On 8/29/05, Duncan B. Cragg wrote: > ... > Yup - sounds reasonable. What about when there is a chunk of data with > a group or list of people who can share it - which is what I'm aiming > for - then peer-to-peer crypto (link security) isn't enough? there are a few ways to do this. what you want is called a broadcast key and part of group management is handling key distribution / pre distribution. in this case the key is known to the group so you are correct that end to end isn't sufficient. > Isn't > data encryption needed? Then it can be passed through intermediaries > that aren't on the list. it will be encrypted with a current group key, so only group members would be able to decipher it. since we are using wireless as part of our network the intermediary could simply be an eavesdropper :) > All this sounds very advanced, especially compared with what I'm > doing - so I look forward to seeing it in action! Are pet names > group-wide or individual? they are individual but you can inherit from the group. if you think of a resource collection as comprising two parts it might make better sense. the first part is a set of SHA->DATA mappings. this is what lies within a self certifying file system, when you read the data out you can verify that the hash is indeed what is expected. (substitute SHA for tiger trees, etc, depending on need - any suitable secure identifier will work). the second part is a signed (by quorum members) mapping of pet names to secure ID's. if you trust the group / quorum then inheriting their pet names for the associated ID's is not a problem. this does not prevent you from making your own mapping to either override or compliment their selection. [in fact, sharing delta's to the common group namespace is an important part of resource discovery but i'll have to think about how to describe this before i just confuse us both] so it is still individual but using inheritance from trusted parties to make it much less tedious to manage a large pet name space. a collaborative effort perhaps :) > Zooko would probably say they were > individual - presumably the reason for them (avoid clashes) > isn't an issue in one of these groups. Did you say that each > resource has a GUID/URL (opaque to human eyes)? My own plan > has two kinds of reference: GUID/URLs (opaque) and a DAG structure > (like a filesystem for humans to explore). yes, this works nicely! > Oh - I love the phrase 'meatspace drama'!! Can I use it? =0) it's a highly technical term for a messy real world case :) > Sounds like you've done what I've done: bitten off more than you > can chew!! =0) I've been working full time on my own plans for > eight months - and am nowhere near done. yes; i've resigned myself to the fact that it is inevitable. if you look at making the entire system complete and well founded you find yourself pulling in all sorts of hard problems like strong identifiers, reputation and trust metrics, explicit and implicit feedback, and then making it easy to use. this is another reason i am big on an infrastructure view of decentralized / peer networking services as i'd much rather reuse a well implemented component (like a tor onion router network or an achord DHT) that can be shared among multiple networks than build it all (poorly) myself. i'm crazy, but not _that_ crazy. > Looking at the alpine archives (why did you wipe it? and also > cubicmetercrystal?) cubicmetercrystal is a long story; it ended up in the hands of a domain speculator. peertech has just recently found a temporary home and i will be restoring content once i get it on a dedicated machine. i should have Verizon FiOS fiber in a few weeks (they promised this time :). physical security for my server has become a requirement due to some other issues that arose in previous contexts. > and the NeuroGrid stuff, it looks like your petnames > (and my DAG) are the key here: treat petnames as stuff that can be > shared, then follow them around (or the peers that use them). indeed; the attackers and cheaters can't forge self certifying resources so the only other option is trying to game the mapping from human descriptors to secure identifiers. if you can make that robust by employing reputation (the following around part, either implicit or explicit) then you can filter out the bad mappings from the peers who want to deceive and rely on trusted mappings from those in your peer groups who have shown themselves reliable. From wtracz at yahoo.co.uk Mon Aug 29 19:33:22 2005 From: wtracz at yahoo.co.uk (Will Tracz) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] Oblivious information dispersal? In-Reply-To: <20050828183031.GA22375@ref.nmedia.net> References: <20050828183031.GA22375@ref.nmedia.net> Message-ID: <43136302.2060205@yahoo.co.uk> From what I read you want to hide the fact a user may have access to certain data or know of its location based on keywords? I read what you requested and instantly thought that Bloom filters may provide a potential solution. Simply hash the keywords and add them to it and merge with your local neighbors to build a hashed version of your keyword set. Due to the way a Bloom filter works you can definitely say if something exists in a set but because it is probablisitic you may get false-positives. Because you can adjust the probability of false-positives occurring you could set it to around 50% and have a sort of deniability as it may be one of your neighbors or you or no one. Just my two cents. I doubt in practice it would work well though, the idea needs more thought than I have given Will ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From ian at locut.us Tue Aug 30 12:41:24 2005 From: ian at locut.us (Ian Clarke) Date: Sat Dec 9 22:13:02 2006 Subject: [p2p-hackers] In search of the Darknet.... In-Reply-To: <4312D4FC.8030309@cilux.org> References: <4303D919.4080705@quinthar.com> <4ef5fec6050818112122416271@mail.gmail.com> <4305007B.8060102@quinthar.com> <430519BE.9010509@cilux.org> <4305F793.5000807@hamachi.cc> <430660FF.9090701@cilux.org> <4308CF1F.6010504@cilux.org> <430F6570.90408@cilux.org> <43123F51.5060102@cs.ucl.ac.uk> <4312D4FC.8030309@cilux.org> Message-ID: <29B03088-C4C3-4BC1-9504-04688384B49B@locut.us> On 29 Aug 2005, at 10:27, Duncan B. Cragg wrote: > Michael: > Is 'Freenet 2' as I have been referring to it, 'Freenet 0.7' > officially? > Sorry to Freenet if I missed that... Yes, Freenet 0.7 will include the so-called "darknet" or "friend to friend" functionality. Ian.