July 2018 - cypherpunks-legacy

RE: [p2p-hackers] Why UDP and not TCP?
by Travis Kalanick 06 Jul '18

06 Jul '18

David, The main reason P2P is moving toward reliable-flow-controlled-UDP is that UDP allows for widely available straight forward techniques to route around NATs in NAT-to-NAT file delivery scenarios. I believe this was covered in the thread, but it may be such common knowledge by now that we only refer to it implicitly. Mangling TCP to implement similar traversal techniques is a substantially more difficult task. Though not impossible at all, it's a tricky bit of hacking you'll need to do to make it work. Travis -----Original Message----- From: p2p-hackers-bounces(a)zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of David Barrett Sent: Friday, November 26, 2004 5:45 PM To: P2P Hackers Subject: [p2p-hackers] Why UDP and not TCP? We've had a long-ranging discussion on how to overcome UDP's inherently unreliable nature, but I'm confused: what overwhelming benefits do you see to UDP that can't be found in TCP? Elsewhere, I've heard the general arguments: 1) UDP is faster (ie, lower latency) 2) UDP is more efficient (ie, lower bandwidth) 3) UDP is easier (ie, no TCP shutdown issues) 4) UDP is more scalable (ie, no inbound connection limits) However, it seems these arguments are only really true if in the application: (from http://www.atlasindia.com/multicast.htm) - Messages require no acknowledgement - Messages between hosts are sporadic or irregular - Reliability is implemented at the process level. Reliable file transfer (the impetus for our discussion, I think) doesn't seem to be a good match for the above criteria. Indeed, it would seem to me that in this situation: 1) Latency is less important than throughput 2) TCP/UDP are similarly efficient because the payload will likely dwarf any packet overhead 3) A custom reliability layer in software is harder than a standardized, worldwide, off-the-shelf reliability layer implemented in hardware 4) The user will run out of bandwidth faster than simultaneous TCP inbound connections. At least, that's what my view tells me. What am I missing? Is there another angle to the UDP/TCP protocol selection that I'm not seeing? I've seen mention of congestion -- does UDP somehow help resolve this? Alternatively, do you find yourself forced to use UDP against your will? I really don't want to start a religious war, but I would like to know what holes exist in my reasoning above. Thanks! -david _______________________________________________ p2p-hackers mailing list p2p-hackers(a)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(a)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 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Hey kids, come join the NSA!
by Eric Rescorla 06 Jul '18

06 Jul '18

Hey boys and girls! Want to help your country defeat that mean old Osama? Then check out the National Security Agency's CryptoKids web site (http://www.nsa.gov/kids/) On this site, you can learn all about codes and ciphers, play lots of games and activities, and get to know each of us - Crypto Cat, Decipher Dog, Rosetta Stone, Slate, Joules, T.Top, and, of course, our leader CSS Sam. You can also learn about the National Security Agency/Central Security Service - they're Americas real codemakers and codebreakers. Our Nation's leaders and warfighters count on the technology and information they get from NSA/CSS to get their jobs done. Without NSA/CSS, they wouldnt be able to talk to one another without the bad guys listening and they wouldnt be able to figure out what the bad guys were planning. We hope you have lots of fun learning about cryptology and NSA/CSS. You might be part of the next generation of Americas codemakers and codebreakers. The site comes complete with a bunch of material on making and breaking simple codes (cool), resources to teach kids about crypto (also cool), and detailed biographies of the CryptoKids characters (kind of creepy). Here's some of what CryptoCat does for fun: I'm usually hanging out with my friends at the mall or catching the latest movie. I love helping people so I find different ways to help out around the community. Right now, I volunteer as a swim coach for children with special needs. Its a lot of fun AND I get to spend extra time with my sister who has Downs Syndrome. The NSA Gifted and Talented program looks pretty cool, though. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [p2p-hackers] what would you like to see most in a p2p social network?
by Pierre St Juste 06 Jul '18

06 Jul '18

Currently when you run SocialVPN, you will connect to our global planetlab pool (essentially our bootstrap nodes). I would say that success rate is pretty high (95% to 99.999%, I think we have some numbers in our papers) if UDP is allowed on the network. We do support TCP as well, but not TCP NAT traversal (that is hard), I am not sure of success rate if you are on TCP only network. And of course, success rate is zero if you are behind a corporate firewall that only allows specific ports such as HTTP or SSH. Planetlab and most ISPs do not let users host services on these popular ports. I think our use of Planetlab (hence a static list of bootstrap nodes) made our solution much easier to implement. We also have a feature which allows peers to use the XMPP's STUN support to facilitate direct connections without having to depend on Planetlab. On Mon, 2011-01-17 at 23:58 -0800, David Barrett wrote: > Oh, is it possible to connect to the SocialVPN overlay on PlanetLab via > the Internet? Neat! As for the STUN approach, that sounds about right > -- have you measured the actual success rate of peers attempting to > connect with it? I know a few people on the list (including me) have > spent *A LOT* of energy on this topic, and it's really freakin' hard, > but super awesome. > > -david > > On 01/17/2011 11:49 PM, Pierre St Juste wrote: > > Here's some explanation about distributed NAT traversal. > > > > We currently run a structured P2P overlay on Planetlab, when you run > > SocialVPN you join that structured overlay, we usually have about 500 - > > 600 nodes running. If node A wants to connect to node B, the following > > happens: > > > > 1 - node A sends a ConnectToMe (CTM) message to node B by using node B's > > P2P address (160-bit randomly chosen address). > > > > 2 - The CTM message contains node A's public IP and UDP port. > > > > 3 - Node B replies through the overlay with his public IP and UDP port > > and simultaneous sends a UDP packet to node A's public IP and port. > > > > 4. When node A receives the reply with node B's IP and UDP port, node A > > sends a UDP packet to node B's public IP and UDP port. > > > > 5. If you have a friendly NAT (not symmetric), then node A's packet will > > make it to node B's machine since node B has already sent a packet to > > that IP and port. > > > > We call it a distributed STUN server because the Brunet P2P library > > allows for discovery of one's public IP address and port and it also > > provides an all-to-all messaging layer needed to signal the start of UDP > > hole punching. > > > > As we all know, direct P2P communication is not always possible, in this > > case, a node that is reachable by both parties is chosen as the relay > > nodes and peers communicate through that. > > > > Finally our NAT traversal is a bit slower than regular STUN because the > > initial message is routed through a structured overlay that takes log(N) > > hops on average, but you may have dropped UDP packets and retries, so it > > may take milliseconds or a few seconds to set up direct P2P connection. > > > > These papers explain in more detail > > > > http://byron.acis.ufl.edu/papers/ipdps06ipop.pdf > > > > http://byron.acis.ufl.edu/papers/hpdc145-ganguly.pdf > > > > http://byron.acis.ufl.edu/papers/cops08.pdf > > > > Hope this helps. I encourage anyone interesting to download SocialVPN > > and try it out, there is windows installer and debian package. It > > currently works with GoogleChat or by emailing each other your P2P address. > > > > On Tue, Jan 18, 2011 at 12:49 AM, David Barrett <dbarrett(a)quinthar.com > > <mailto:dbarrett@quinthar.com>> wrote: > > > > Wow, this looks really fantastic. I hadn't followed its progress but it > > sounds like it's come a long way really fast. I'd love to hear more > > about its distributed STUN service and NAT traversal. Do you have any > > data on its effectiveness, perhaps expressed as the likelihood that two > > arbitrary nodes will be able to connect directly via the internet? Is > > there a TURN or other relay service available as a fallback? Thanks! > > > > -david > > > > On 01/17/2011 08:13 PM, Pierre St Juste wrote: > > > I would like to point out the SocialVPN project > > > > > > http://socialvpn.org > > > > > > It is basically a P2P VPN which creates direct encrypted tunnels to > > > friends. It currently uses the XMPP protocol for friend discovery and > > > public key exchange. This VPN thus creates a social graph where edges > > > are IP links. This infrastructure can be used as an enabler for many > > > other social services. Here are a few examples > > > > > > 1 - Instead of using Skype, you can use Ekiga with Avahi, Avahi > > > extension for Ekiga will discover online friends through > > multicast over > > > the social virtual private network, you can then place SIP call > > directly > > > over IP link. > > > > > > 2. For instant messaging, you can use Empathy or Pidgin with > > > Bonjour/Avahi support, as concept as above. > > > > > > 3. For video stream, you can stream a video over HTTP or RTP > > using VLC > > > and your friends can connect directly. > > > > > > 4. For social networking, you can run a wordpress blog locally > > and have > > > your friends connect to that, or you can write an social networking > > > application that communicates with friends over SocialVPN using > > Berkeley > > > sockets API instead of having to deal with building P2P library that > > > deals with NAT traversal, peer search and so on. > > > > > > 5. All data sent between peers is encrypted and authenticated, > > basically > > > the same idea behind IPSec if you support PKI certificate exchanges. > > > > > > One of the hardest thing about building social P2P systems is having > > > with a user-friendly way to bootstrap these social links (or > > Darknets). > > > SocialVPN makes that step trivial so that developers can focus > > more on > > > making cool apps versus figuring out how to traverse NATs. > > > > > > I hope this helps. > > > > > > On Mon, 2011-01-17 at 18:57 -0800, David Barrett wrote: > > >> I'd suggest first figuring out why someone would pick a P2P social > > >> network over Facebook, from a perspective of legitimate > > functionality > > >> rather than just privacy (which as Facebook has demonstrated, > > isn't a > > >> killer feature). I'd suggest really emphasizing the fact that with > > >> P2P-Book, there is no "uploading" photos or videos: you can > > share entire > > >> folders of files, videos, documents, or whatever and their instantly > > >> available to your friends -- without first uploading them > > somewhere else. > > >> > > >> Furthermore, emphasize that you're not sharing *copies* of the > > videos, > > >> songs, and photos -- you're sharing the originals: change the > > original > > >> (crop, reorient, touch up, tag with metadata, etc) and its > > automatically > > >> updated. > > >> > > >> -david > > >> > > >> On 01/17/2011 12:51 PM, Jan DomaEski wrote: > > >>> Hey Michael, > > >>> > > >>> Thanks for the comments, they're helpful. > > >>> > > >>> A lot of this boils down to having two (or more) 'sides' of > > self. One > > >>> for general public, others for the rest; this is doable. > > >>> > > >>> Grudge-friendly and jackboot resistant, in ideal world, comes > > with the > > >>> 'distributed' and 'secure+encrypted'. But sure, seems to have > > been lost > > >>> in the implementation of at least one social network i can > > think of. > > >>> > > >>> As to the grandmother compatibility, at least to me, this is not > > >>> absolutely essential at first. > > >>> > > >>> Cherio, Jan > > >>> > > >>> 2011/1/16 Michael Rogers<m--(a)gmx.com > > <mailto:m--@gmx.com><mailto:m--@gmx.com <mailto:m--@gmx.com>>> > > >>> > > >>> Hi Jan, > > >>> > > >>> Here's a quick list of features I'd like to see in any > > social network > > >>> (not just P2P ones): > > >>> > > >>> * Grandmother-compatible. It should be possible to be > > friends with my > > >>> grandmother without her seeing the photo of the time I did > > that thing > > >>> with the grapes. > > >>> > > >>> * Alcohol-compatible. There should be something as easy to > > remember as > > >>> an email address that I can give to random people I > > befriend while > > >>> drunk. And if they look me up the next day, there should > > be a polite way > > >>> of not responding. > > >>> > > >>> * Schoolproof. People should not be able to find my > > profile just because > > >>> we went to school together 20 years ago. Similarly, people > > should not be > > >>> able to find my profile just because I applied for a job > > at their > > >>> company (or at least, they shouldn't be able to see the > > photo of the > > >>> thing with the grapes). > > >>> > > >>> * Grudge-friendly. It should be possible to move my data > > from one > > >>> provider to another when the current provider accuses me > > of lacking > > >>> integrity because I don't want my grandmother to see the > > photo etc etc. > > >>> > > >>> * Jackboot-resistant. The Tunisian government should not > > be able to > > >>> steal my password by setting up a fake login page. > > >>> > > >>> Cheers, > > >>> Michael > > >>> > > >>> On 15/01/11 20:35, Jan DomaEski wrote: > > >>> > Hello everybody out there interested in p2p social networking, > > >>> > > > >>> > I'm doing a (free) p2p social network (just a hobby, wonbt > > be big and > > >>> > professional like diaspora). It has been in the works since > > >>> summer, and > > >>> > begins to get some shape. I'd like any feedback on things people > > >>> > like/dislike in the idea of a p2p social network and how this is > > >>> solved > > >>> > by the little toy. > > >>> > > > >>> > I've currently written it in java, netty handles the networking, > > >>> Qt is > > >>> > used for GUI. Some yml for configs and db4o for storage. > > Non-blocking > > >>> > xml (XMPP) parser is a missing puzzle. The app has been run > > only on a > > >>> > single machine, but it's already practical and I'd like to > > know what > > >>> > features most people would want. Any suggestions are > > welcome, but I > > >>> > wonbt promise Ibll implement them :] > > >>> > > > >>> > Two demos (the top one is new) below, gitorious and blog > > links inside > > >>> > http://www.youtube.com/watch?v=0rAwCsYt16w > > >>> > http://www.youtube.com/watch?v=K1dujrhGvBQ > > >>> > > > >>> > Jan (jan.domanski(a)new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk><mailto:jan.domanski@new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk>> > > >>> <mailto:jan.domanski@new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk><mailto:jan.domanski@new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk>>>) > > >>> > > > >>> > PS. Yes - it's all my own work and done as a scientist not a > > >>> programmer, > > >>> > which has terrible implications for code ;) > > >>> > > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > p2p-hackers mailing list > > >>> > p2p-hackers(a)lists.zooko.com > > <mailto:p2p-hackers@lists.zooko.com><mailto:p2p-hackers@lists.zooko.com > > <mailto:p2p-hackers@lists.zooko.com>> > > >>> > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> p2p-hackers mailing list > > >>> p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > >>> http://lists.zooko.com/mailman/listinfo/p2p-hackers > > >> _______________________________________________ > > >> p2p-hackers mailing list > > >> p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > >> http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > _______________________________________________ > > > p2p-hackers mailing list > > > p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > > -- > > Pierre St Juste > > > > > > > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers(a)lists.zooko.com > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ > p2p-hackers mailing list > p2p-hackers(a)lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [p2p-hackers] what would you like to see most in a p2p social network?
by Pierre St Juste 06 Jul '18

06 Jul '18

Currently when you run SocialVPN, you will connect to our global planetlab pool (essentially our bootstrap nodes). I would say that success rate is pretty high (95% to 99.999%, I think we have some numbers in our papers) if UDP is allowed on the network. We do support TCP as well, but not TCP NAT traversal (that is hard), I am not sure of success rate if you are on TCP only network. And of course, success rate is zero if you are behind a corporate firewall that only allows specific ports such as HTTP or SSH. Planetlab and most ISPs do not let users host services on these popular ports. I think our use of Planetlab (hence a static list of bootstrap nodes) made our solution much easier to implement. We also have a feature which allows peers to use the XMPP's STUN support to facilitate direct connections without having to depend on Planetlab. On Mon, 2011-01-17 at 23:58 -0800, David Barrett wrote: > Oh, is it possible to connect to the SocialVPN overlay on PlanetLab via > the Internet? Neat! As for the STUN approach, that sounds about right > -- have you measured the actual success rate of peers attempting to > connect with it? I know a few people on the list (including me) have > spent *A LOT* of energy on this topic, and it's really freakin' hard, > but super awesome. > > -david > > On 01/17/2011 11:49 PM, Pierre St Juste wrote: > > Here's some explanation about distributed NAT traversal. > > > > We currently run a structured P2P overlay on Planetlab, when you run > > SocialVPN you join that structured overlay, we usually have about 500 - > > 600 nodes running. If node A wants to connect to node B, the following > > happens: > > > > 1 - node A sends a ConnectToMe (CTM) message to node B by using node B's > > P2P address (160-bit randomly chosen address). > > > > 2 - The CTM message contains node A's public IP and UDP port. > > > > 3 - Node B replies through the overlay with his public IP and UDP port > > and simultaneous sends a UDP packet to node A's public IP and port. > > > > 4. When node A receives the reply with node B's IP and UDP port, node A > > sends a UDP packet to node B's public IP and UDP port. > > > > 5. If you have a friendly NAT (not symmetric), then node A's packet will > > make it to node B's machine since node B has already sent a packet to > > that IP and port. > > > > We call it a distributed STUN server because the Brunet P2P library > > allows for discovery of one's public IP address and port and it also > > provides an all-to-all messaging layer needed to signal the start of UDP > > hole punching. > > > > As we all know, direct P2P communication is not always possible, in this > > case, a node that is reachable by both parties is chosen as the relay > > nodes and peers communicate through that. > > > > Finally our NAT traversal is a bit slower than regular STUN because the > > initial message is routed through a structured overlay that takes log(N) > > hops on average, but you may have dropped UDP packets and retries, so it > > may take milliseconds or a few seconds to set up direct P2P connection. > > > > These papers explain in more detail > > > > http://byron.acis.ufl.edu/papers/ipdps06ipop.pdf > > > > http://byron.acis.ufl.edu/papers/hpdc145-ganguly.pdf > > > > http://byron.acis.ufl.edu/papers/cops08.pdf > > > > Hope this helps. I encourage anyone interesting to download SocialVPN > > and try it out, there is windows installer and debian package. It > > currently works with GoogleChat or by emailing each other your P2P address. > > > > On Tue, Jan 18, 2011 at 12:49 AM, David Barrett <dbarrett(a)quinthar.com > > <mailto:dbarrett@quinthar.com>> wrote: > > > > Wow, this looks really fantastic. I hadn't followed its progress but it > > sounds like it's come a long way really fast. I'd love to hear more > > about its distributed STUN service and NAT traversal. Do you have any > > data on its effectiveness, perhaps expressed as the likelihood that two > > arbitrary nodes will be able to connect directly via the internet? Is > > there a TURN or other relay service available as a fallback? Thanks! > > > > -david > > > > On 01/17/2011 08:13 PM, Pierre St Juste wrote: > > > I would like to point out the SocialVPN project > > > > > > http://socialvpn.org > > > > > > It is basically a P2P VPN which creates direct encrypted tunnels to > > > friends. It currently uses the XMPP protocol for friend discovery and > > > public key exchange. This VPN thus creates a social graph where edges > > > are IP links. This infrastructure can be used as an enabler for many > > > other social services. Here are a few examples > > > > > > 1 - Instead of using Skype, you can use Ekiga with Avahi, Avahi > > > extension for Ekiga will discover online friends through > > multicast over > > > the social virtual private network, you can then place SIP call > > directly > > > over IP link. > > > > > > 2. For instant messaging, you can use Empathy or Pidgin with > > > Bonjour/Avahi support, as concept as above. > > > > > > 3. For video stream, you can stream a video over HTTP or RTP > > using VLC > > > and your friends can connect directly. > > > > > > 4. For social networking, you can run a wordpress blog locally > > and have > > > your friends connect to that, or you can write an social networking > > > application that communicates with friends over SocialVPN using > > Berkeley > > > sockets API instead of having to deal with building P2P library that > > > deals with NAT traversal, peer search and so on. > > > > > > 5. All data sent between peers is encrypted and authenticated, > > basically > > > the same idea behind IPSec if you support PKI certificate exchanges. > > > > > > One of the hardest thing about building social P2P systems is having > > > with a user-friendly way to bootstrap these social links (or > > Darknets). > > > SocialVPN makes that step trivial so that developers can focus > > more on > > > making cool apps versus figuring out how to traverse NATs. > > > > > > I hope this helps. > > > > > > On Mon, 2011-01-17 at 18:57 -0800, David Barrett wrote: > > >> I'd suggest first figuring out why someone would pick a P2P social > > >> network over Facebook, from a perspective of legitimate > > functionality > > >> rather than just privacy (which as Facebook has demonstrated, > > isn't a > > >> killer feature). I'd suggest really emphasizing the fact that with > > >> P2P-Book, there is no "uploading" photos or videos: you can > > share entire > > >> folders of files, videos, documents, or whatever and their instantly > > >> available to your friends -- without first uploading them > > somewhere else. > > >> > > >> Furthermore, emphasize that you're not sharing *copies* of the > > videos, > > >> songs, and photos -- you're sharing the originals: change the > > original > > >> (crop, reorient, touch up, tag with metadata, etc) and its > > automatically > > >> updated. > > >> > > >> -david > > >> > > >> On 01/17/2011 12:51 PM, Jan DomaEski wrote: > > >>> Hey Michael, > > >>> > > >>> Thanks for the comments, they're helpful. > > >>> > > >>> A lot of this boils down to having two (or more) 'sides' of > > self. One > > >>> for general public, others for the rest; this is doable. > > >>> > > >>> Grudge-friendly and jackboot resistant, in ideal world, comes > > with the > > >>> 'distributed' and 'secure+encrypted'. But sure, seems to have > > been lost > > >>> in the implementation of at least one social network i can > > think of. > > >>> > > >>> As to the grandmother compatibility, at least to me, this is not > > >>> absolutely essential at first. > > >>> > > >>> Cherio, Jan > > >>> > > >>> 2011/1/16 Michael Rogers<m--(a)gmx.com > > <mailto:m--@gmx.com><mailto:m--@gmx.com <mailto:m--@gmx.com>>> > > >>> > > >>> Hi Jan, > > >>> > > >>> Here's a quick list of features I'd like to see in any > > social network > > >>> (not just P2P ones): > > >>> > > >>> * Grandmother-compatible. It should be possible to be > > friends with my > > >>> grandmother without her seeing the photo of the time I did > > that thing > > >>> with the grapes. > > >>> > > >>> * Alcohol-compatible. There should be something as easy to > > remember as > > >>> an email address that I can give to random people I > > befriend while > > >>> drunk. And if they look me up the next day, there should > > be a polite way > > >>> of not responding. > > >>> > > >>> * Schoolproof. People should not be able to find my > > profile just because > > >>> we went to school together 20 years ago. Similarly, people > > should not be > > >>> able to find my profile just because I applied for a job > > at their > > >>> company (or at least, they shouldn't be able to see the > > photo of the > > >>> thing with the grapes). > > >>> > > >>> * Grudge-friendly. It should be possible to move my data > > from one > > >>> provider to another when the current provider accuses me > > of lacking > > >>> integrity because I don't want my grandmother to see the > > photo etc etc. > > >>> > > >>> * Jackboot-resistant. The Tunisian government should not > > be able to > > >>> steal my password by setting up a fake login page. > > >>> > > >>> Cheers, > > >>> Michael > > >>> > > >>> On 15/01/11 20:35, Jan DomaEski wrote: > > >>> > Hello everybody out there interested in p2p social networking, > > >>> > > > >>> > I'm doing a (free) p2p social network (just a hobby, wonbt > > be big and > > >>> > professional like diaspora). It has been in the works since > > >>> summer, and > > >>> > begins to get some shape. I'd like any feedback on things people > > >>> > like/dislike in the idea of a p2p social network and how this is > > >>> solved > > >>> > by the little toy. > > >>> > > > >>> > I've currently written it in java, netty handles the networking, > > >>> Qt is > > >>> > used for GUI. Some yml for configs and db4o for storage. > > Non-blocking > > >>> > xml (XMPP) parser is a missing puzzle. The app has been run > > only on a > > >>> > single machine, but it's already practical and I'd like to > > know what > > >>> > features most people would want. Any suggestions are > > welcome, but I > > >>> > wonbt promise Ibll implement them :] > > >>> > > > >>> > Two demos (the top one is new) below, gitorious and blog > > links inside > > >>> > http://www.youtube.com/watch?v=0rAwCsYt16w > > >>> > http://www.youtube.com/watch?v=K1dujrhGvBQ > > >>> > > > >>> > Jan (jan.domanski(a)new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk><mailto:jan.domanski@new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk>> > > >>> <mailto:jan.domanski@new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk><mailto:jan.domanski@new.ox.ac.uk > > <mailto:jan.domanski@new.ox.ac.uk>>>) > > >>> > > > >>> > PS. Yes - it's all my own work and done as a scientist not a > > >>> programmer, > > >>> > which has terrible implications for code ;) > > >>> > > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > p2p-hackers mailing list > > >>> > p2p-hackers(a)lists.zooko.com > > <mailto:p2p-hackers@lists.zooko.com><mailto:p2p-hackers@lists.zooko.com > > <mailto:p2p-hackers@lists.zooko.com>> > > >>> > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> p2p-hackers mailing list > > >>> p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > >>> http://lists.zooko.com/mailman/listinfo/p2p-hackers > > >> _______________________________________________ > > >> p2p-hackers mailing list > > >> p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > >> http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > _______________________________________________ > > > p2p-hackers mailing list > > > p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers(a)lists.zooko.com <mailto:p2p-hackers@lists.zooko.com> > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > > -- > > Pierre St Juste > > > > > > > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers(a)lists.zooko.com > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ > p2p-hackers mailing list > p2p-hackers(a)lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] Safer submission of content to news organizations
by Danny O'Brien 06 Jul '18

06 Jul '18

On Tue, Jan 17, 2012 at 11:39:36AM -0500, Martyn Williams wrote: > Hi to all on this list. I've been following discussions here for a while > but this is the first time I'm posting. > > I'm a Knight Journalism Fellow at Stanford this year, which means I have > a year off from reporting to follow projects that interest me and help > innovate in journalism in some way. > > One of my two projects is focused on the security of consumers who > supply content (text, photo or video) to news organizations. > > I see a lot of work being done on how citizens/activists/bloggers and > others can secure information on their end but I haven't seen much done > on the other end by the news organizations. Sometimes they offer little > more than an email address or Facebook page for submissions. > > So my project asks: If news organizations are to solicit content from > people on the ground (and there are no signs this will stop), what can > they do to make it safer for those submitting the information? > > Should they set up a dedicated server, rely on a cloud service, use a > certain type of encryption, base it on a particular technology, etc etc? > > The goal isn't anonymity like Wikileaks - that brings a heap of > editorial problems with it - but making it harder for tracking to link > person A with news organization B. It should also be practical to implement. > I spoke to CJR about this last week, including some of the failed attempts so far. I think it's much of a culture clash between traditional journalisms and comp.security environments. http://www.cjr.org/the_news_frontier/tell_me_a_secret.php?page=all&print=tr… Essentially, the problem you face is one of differing threat models. In traditional journalism, the idea is that you and your source would know each other's identities, but the journalist would be ethically bound (and legally protected) from revealing the whistleblower's name. Traditionally this hasn't required "anonymity". Your problem is that any networked connection is vulnerable to making that identification between the two users, journalist and whistleblower, unless you maintain absolute anonymity over the network, but provide some form of consistent attestation (ie, I don't know who you are, but you're the same person as I talked to last time). Any actual identity can be ascertained out of band. (I'm that guy you met that one time wearing a rose. We both know Bill's shoe size. etc) It's worth reading the original paper for OTR which covers some of these particular requirements in depth. http://www.cypherpunks.ca/otr/otr-wpes.pdf > It will ideally be based on open-source technologies that are freely > available and can be implemented by news organizations of any size. > > If successful, I hope to present this to news organizations, push for > its adoption, and raise awareness of the need for media groups to think > about the safety of those sending content. > > I welcome comments off list. If anyone has heard of or is working on > similar technology or has an interest in collaborating I'd love to hear > from you. > > -- > Martyn Williams > 2012 John S. Knight Journalism Fellow > Stanford University > Cell: 650-391-4868 > @martyn_williams > _______________________________________________ > liberationtech mailing list > liberationtech(a)lists.stanford.edu > > Should you need to change your subscription options, please go to: > > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" > > You will need the user name and password you receive from the list moderator in monthly reminders. > > Should you need immediate assistance, please contact the list moderator. > > Please don't forget to follow us on http://twitter.com/#!/Liberationtech -- Danny O'Brien Internet Advocacy Coordinator Committee to Protect Journalists +1 408 480 3412 _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

RE: [p2p-hackers] Why UDP and not TCP?
by Travis Kalanick 06 Jul '18

06 Jul '18

David, The main reason P2P is moving toward reliable-flow-controlled-UDP is that UDP allows for widely available straight forward techniques to route around NATs in NAT-to-NAT file delivery scenarios. I believe this was covered in the thread, but it may be such common knowledge by now that we only refer to it implicitly. Mangling TCP to implement similar traversal techniques is a substantially more difficult task. Though not impossible at all, it's a tricky bit of hacking you'll need to do to make it work. Travis -----Original Message----- From: p2p-hackers-bounces(a)zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of David Barrett Sent: Friday, November 26, 2004 5:45 PM To: P2P Hackers Subject: [p2p-hackers] Why UDP and not TCP? We've had a long-ranging discussion on how to overcome UDP's inherently unreliable nature, but I'm confused: what overwhelming benefits do you see to UDP that can't be found in TCP? Elsewhere, I've heard the general arguments: 1) UDP is faster (ie, lower latency) 2) UDP is more efficient (ie, lower bandwidth) 3) UDP is easier (ie, no TCP shutdown issues) 4) UDP is more scalable (ie, no inbound connection limits) However, it seems these arguments are only really true if in the application: (from http://www.atlasindia.com/multicast.htm) - Messages require no acknowledgement - Messages between hosts are sporadic or irregular - Reliability is implemented at the process level. Reliable file transfer (the impetus for our discussion, I think) doesn't seem to be a good match for the above criteria. Indeed, it would seem to me that in this situation: 1) Latency is less important than throughput 2) TCP/UDP are similarly efficient because the payload will likely dwarf any packet overhead 3) A custom reliability layer in software is harder than a standardized, worldwide, off-the-shelf reliability layer implemented in hardware 4) The user will run out of bandwidth faster than simultaneous TCP inbound connections. At least, that's what my view tells me. What am I missing? Is there another angle to the UDP/TCP protocol selection that I'm not seeing? I've seen mention of congestion -- does UDP somehow help resolve this? Alternatively, do you find yourself forced to use UDP against your will? I really don't want to start a religious war, but I would like to know what holes exist in my reasoning above. Thanks! -david _______________________________________________ p2p-hackers mailing list p2p-hackers(a)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(a)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 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Hey kids, come join the NSA!
by Eric Rescorla 06 Jul '18

06 Jul '18

Hey boys and girls! Want to help your country defeat that mean old Osama? Then check out the National Security Agency's CryptoKids web site (http://www.nsa.gov/kids/) On this site, you can learn all about codes and ciphers, play lots of games and activities, and get to know each of us - Crypto Cat, Decipher Dog, Rosetta Stone, Slate, Joules, T.Top, and, of course, our leader CSS Sam. You can also learn about the National Security Agency/Central Security Service - they're Americas real codemakers and codebreakers. Our Nation's leaders and warfighters count on the technology and information they get from NSA/CSS to get their jobs done. Without NSA/CSS, they wouldnt be able to talk to one another without the bad guys listening and they wouldnt be able to figure out what the bad guys were planning. We hope you have lots of fun learning about cryptology and NSA/CSS. You might be part of the next generation of Americas codemakers and codebreakers. The site comes complete with a bunch of material on making and breaking simple codes (cool), resources to teach kids about crypto (also cool), and detailed biographies of the CryptoKids characters (kind of creepy). Here's some of what CryptoCat does for fun: I'm usually hanging out with my friends at the mall or catching the latest movie. I love helping people so I find different ways to help out around the community. Right now, I volunteer as a swim coach for children with special needs. Its a lot of fun AND I get to spend extra time with my sister who has Downs Syndrome. The NSA Gifted and Talented program looks pretty cool, though. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [liberationtech] Safer submission of content to news organizations
by Danny O'Brien 06 Jul '18

06 Jul '18

On Tue, Jan 17, 2012 at 11:39:36AM -0500, Martyn Williams wrote: > Hi to all on this list. I've been following discussions here for a while > but this is the first time I'm posting. > > I'm a Knight Journalism Fellow at Stanford this year, which means I have > a year off from reporting to follow projects that interest me and help > innovate in journalism in some way. > > One of my two projects is focused on the security of consumers who > supply content (text, photo or video) to news organizations. > > I see a lot of work being done on how citizens/activists/bloggers and > others can secure information on their end but I haven't seen much done > on the other end by the news organizations. Sometimes they offer little > more than an email address or Facebook page for submissions. > > So my project asks: If news organizations are to solicit content from > people on the ground (and there are no signs this will stop), what can > they do to make it safer for those submitting the information? > > Should they set up a dedicated server, rely on a cloud service, use a > certain type of encryption, base it on a particular technology, etc etc? > > The goal isn't anonymity like Wikileaks - that brings a heap of > editorial problems with it - but making it harder for tracking to link > person A with news organization B. It should also be practical to implement. > I spoke to CJR about this last week, including some of the failed attempts so far. I think it's much of a culture clash between traditional journalisms and comp.security environments. http://www.cjr.org/the_news_frontier/tell_me_a_secret.php?page=all&print=tr… Essentially, the problem you face is one of differing threat models. In traditional journalism, the idea is that you and your source would know each other's identities, but the journalist would be ethically bound (and legally protected) from revealing the whistleblower's name. Traditionally this hasn't required "anonymity". Your problem is that any networked connection is vulnerable to making that identification between the two users, journalist and whistleblower, unless you maintain absolute anonymity over the network, but provide some form of consistent attestation (ie, I don't know who you are, but you're the same person as I talked to last time). Any actual identity can be ascertained out of band. (I'm that guy you met that one time wearing a rose. We both know Bill's shoe size. etc) It's worth reading the original paper for OTR which covers some of these particular requirements in depth. http://www.cypherpunks.ca/otr/otr-wpes.pdf > It will ideally be based on open-source technologies that are freely > available and can be implemented by news organizations of any size. > > If successful, I hope to present this to news organizations, push for > its adoption, and raise awareness of the need for media groups to think > about the safety of those sending content. > > I welcome comments off list. If anyone has heard of or is working on > similar technology or has an interest in collaborating I'd love to hear > from you. > > -- > Martyn Williams > 2012 John S. Knight Journalism Fellow > Stanford University > Cell: 650-391-4868 > @martyn_williams > _______________________________________________ > liberationtech mailing list > liberationtech(a)lists.stanford.edu > > Should you need to change your subscription options, please go to: > > https://mailman.stanford.edu/mailman/listinfo/liberationtech > > If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" > > You will need the user name and password you receive from the list moderator in monthly reminders. > > Should you need immediate assistance, please contact the list moderator. > > Please don't forget to follow us on http://twitter.com/#!/Liberationtech -- Danny O'Brien Internet Advocacy Coordinator Committee to Protect Journalists +1 408 480 3412 _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[drone-list] WSJ article
by villa＠ee.ucla.edu 06 Jul '18

06 Jul '18

Hi - article today, "Could We Trust Killer Robots?" This article discusses research (and I'm not making this up) into "lethal autonomous systems" - e.g. algorithms that would enable drones to make automated decisions to launch strikes. John http://online.wsj.com/article/SB10001424052702303448404577410032825529656.h… _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

FC: Day #2: U.S. v. Jim Bell report from federal court in Tacoma
by Declan McCullagh 06 Jul '18

06 Jul '18

http://www.wired.com/news/politics/0,1283,42860,00.html DOJ: Cypherpunk Threatened Feds by Declan McCullagh (declan(a)wired.com) 9:00 a.m. Apr. 5, 2001 PDT TACOMA, Washington -- A federal prosecutor said on Wednesday that an Internet essayist spent months illegally compiling information about IRS agents through CD-ROM databases and conversations with members of a mailing list of "cypherpunks." Robb London, an assistant U.S. Attorney, said in court that Jim Bell was not conducting a legitimate investigation of government wrongdoing last year but instead was a disturbed person who had never renounced a political treatise he wrote entitled "Assassination Politics." "It's still on the Internet today," London said during the second day of the trial in federal district court. "He has not retracted it." Bell is best known for writing the long-winded thought experiment predicting how future technologies including untraceable digital cash, encryption and anonymity should allow anyone upset with the feds to bet on when a certain government agent will die. The winner, presumably the assassin, wins the pool of money. London said that while Bell may not have directly threatened IRS agent Jeff Gordon, "he has done it indirectly through 'Assassination Politics.'" Bell has pleaded not guilty to five counts of interstate stalking that allegedly took place last year, saying he was legally assembling information about government agents he thought were participating in a conspiracy involving illegal surveillance. He is not accused of making direct threats or seeking physical confrontations. As evidence of Bell's malicious intent, London showed the jury a photograph of four guns that Bell legally owned up until the IRS raided him in April 1997 during a prior prosecution. The weapons: Two SKS rifles, a Smith & Wesson 629 pistol, and a Ruger mini-14 rifle. London characterized this as a collection of assault weapons that amounted to "serious firepower" and said, "That's what the agents were afraid of." That prompted an objection from Bell's attorney, Robert Leen. "(You're) asking the jury to draw an adverse infrerence from what was, at the time, an exercise of a constitutional right," Leen said. The government has not alleged that Bell owned firearms more recently than 1997. Bell pleaded guilty in July 1997 to interfering with IRS agents and using false Social Security numbers. U.S. District Judge Jack Tanner allowed the government to show to the jury photos of the weapons Bell once owned -- one rifle had a bayonet mounted on it -- and warned Bell that if he made any additional outbursts, he would be muzzled or hauled out of the room. Bell had interrupted Leen a few times and pounded on the table two or three times to get Leen's attention. Bell also wrote "SHAM" on a white pad of paper and held it so spectators could see. London complained that some people were downloading public documents through the Pacer service provided by the federal court system, translating the graphical TIFF images into text, and posting the documents on a website. He warned that soon everything will be "splashed all over the Internet for all to see." The prosecutor likened it to an illicit activity: "Transferring court documents from our computer onto the Internet." That got the attention of Tanner, an 82-year-old jurist with little patience for lawyers and even less patience for online open-records activists. He sealed the entire court file, including public documents like the charges against Bell, saying that "anything that's filed" will remain in his chambers. [...] ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if it remains intact. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ ------------------------------------------------------------------------- ----- End forwarded message -----

1 0