[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin [EMAIL PROTECTED] - From: Kerry Bonin [EMAIL PROTECTED] Date: Mon, 31 Oct 2005 07:25:20 -0800 To: Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Frank, In my experience w/ pretty hardcore authentication and security domains, it is pretty much impossible to guarantee that a remote node connecting over an untrusted network is running trusted code. For every clever way to try and detect a compromised client, there are even more clever ways to subvert the detection process. The simplest model - simply reverse engineer the network traffic via packet capture, and write a client that looks identical from the network traffic. One example of a common client validation approach is requesting a strong checksum of some random range of the client or its dataset, but this is pretty trivial to circumvent once you have a complete copy of the client and have reverse engineered its checksum algorithm. In my experience, if you really care about what your node are doing, then NEVER trust ANY node - validate every bit of every packet. If you are trying to catch compromised nodes, there are clever ways to do that - build heuristic models that examine what nodes are doing, and forward captures to admin nodes for human analysis for heuristic refinement and analysis of what your attackers are up to. While it is in theory impossible to allow users to do anything and still catch a user doing something they're not supposed to, it may be possible to specify terms in your EULA that define constraints users would not typically violate, and respond with penalties that are not too strong for the corner cases where a user triggers a false positive by crossing the line. An example of this in the file sharing domain would be temporary bans on nodes that initiated too many searches in some time frame, suggesting spidering. On the other hand, clever counter-heuristics and large numbers of zombies can defeat most heuristics - see SPAM for many examples... Kerry Frank Moore wrote: Matthew Kaufman wrote: I think what you're asking here is is it possible to design a p2p network such that the peers must be running the official code that does the right thing, instead of running some subverted code that does something 'wrong'? Matthew, Very eloquently put. Yes, this is exactly what I was asking. We supply the client as well as the server and we just need to make sure that any client that joins the network is our client and not a 'rogue'. The one exception is that you *can* in some cases design the network such that peers that don't behave properly are shunned or dropped by the rest of the network, assuming that such behavior is detectable. For instance, in a distributed file store, you could store test data and see if it sticks around... If it doesn't, that peer is cheating. We have a way (we think) of authenticating the stream put out by a peer, so we can catch a 'rogue' client this way, but it seems more logical to prevent someone from logging into the network in the first place. Thanks for your help, Frank. ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
At 9:27 PM -0700 10/27/05, cyphrpunk wrote: Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. So, as Carl Ellison says, get it from the source. Self-signing is fine, in that case. Certificates, CRLs, etc., become more and more meaningless as the network becomes more geodesic. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! Feh. You sound like one of those newbs who used to leave the plastic wrap on his 3.5 floppy so he wouldn't get viruses... Cheers, RAH What part of non-hierarchical and P2P do you not understand? -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
[EMAIL PROTECTED]: RE: [p2p-hackers] P2P Authentication]
- Forwarded message from Matthew Kaufman [EMAIL PROTECTED] - From: Matthew Kaufman [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 19:28:53 -0700 To: 'Peer-to-peer development.' [EMAIL PROTECTED] Subject: RE: [p2p-hackers] P2P Authentication X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Alen Peacock: Personally, I'm put off by the centralization. I'm not really concerned about the library size or complexity of PKI,. In fact, my experience indicates that implementing centralized CAs is a good deal less complex than trying to distribute identity verification throughout the system with no centralization. Agreed... Hierarchical PKI with a single root is distinctly easier than multiple roots, random chains of trust, or reputation models, which is why we've started with the simplest design for the default PKI that ships with the amicima MFP and MFPNet libraries. Completely decentralized p2p applications have the advantage of being especially resilient to DoS and other attacks on centrality. Introducing centralized components negates this advantage. It negates some advantages, not all. In the case of using CAs in a p2p app, the entire network can be disabled by attacking the CAs. As has already been pointed out, the network still runs, but new clients can't be authenticated. However, it is possible to make that unlikely... For instance, if enough trusted entities already have the ability to sign keys, you can reduce the odds that an attacker can successfully disable ALL of the CAs. Adding additional roots to the PKI, especially if they are public roots that are unlikely to be disabled, also helps... It doesn't seem likely that the world will shut down the existing secure web PKI in order to take your P2P app off the air. p2p networks pose an interesting challenge because you have to design for the fact that malicious or misbehaving clients *will* be present. This is actually true of the entire Internet and isn't unique to p2p networks at all. All protocol implementations and higher level applications that run on them must be designed to deal with malicious or misbehaving clients will be present... See buffer overflows of mail servers and http servers, for instance. Since there is no single entity or known group of entities controlling the nodes (as in typical distributed applications), there is no way to enforce adherence to protocols other than with the protocols themselves. This isn't about p2p networks at all, but about open-source distribution, it seems. Lots of totally proprietary p2p and client-server applications have been shipped where a single entity controls the implementation... Skype comes to mind as an example in the P2P space. These have the temporary advantage of unpublished protocols and implementations, but this won't stop a dedicated attacker for long, which brings us back to the original point, that everything attached to the Internet needs to assume that malicious and misbehaving things will try to mess things up. Whether or not that really matters is another point... There's numerous ways one could build a highly incorrect Gnutella peer, for instance, and yet it doesn't seem to have become commonplace. This may sound idealistic and naive, perhaps justly so, but the further away from protocols that require centralized architectures we get, the better (IMHO, of course). Well, that's why we're all here on the P2P hackers list, I suppose, because we believe that decentralization is good, but it doesn't really change the most basic of the design parameters at all. Matthew Kaufman [EMAIL PROTECTED] www.amicima.com ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
At 9:27 PM -0700 10/27/05, cyphrpunk wrote: Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. So, as Carl Ellison says, get it from the source. Self-signing is fine, in that case. Certificates, CRLs, etc., become more and more meaningless as the network becomes more geodesic. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! Feh. You sound like one of those newbs who used to leave the plastic wrap on his 3.5 floppy so he wouldn't get viruses... Cheers, RAH What part of non-hierarchical and P2P do you not understand? -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... It's great to see this guy showing up yet another of the false dogmas of the crypto hacker community: PKI can't work. According to this view, only old fogies and tight ass bureaucrats believe in certifying keys. All the cool kids know that the best key is a bare key. After all, MITM attacks never really happen, this was just an invented threat designed to force poor college kids into paying hundreds of dollars a year for a verisign certificate. But when we come into the P2P world things look very different. Where MITM would require special positioning in the old net, in a distributed P2P network, everyone's a MITM! Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! CP
[EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
- Forwarded message from Kerry Bonin [EMAIL PROTECTED] - From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... Kerry [EMAIL PROTECTED] wrote: And if they do, then why reinvent the wheel? Traditional public key signing works well for these cases. ... Traditional public key signing doesn't work well if you want to eliminate the central authority / trusted third party. If you like keeping those around, then yes, absolutely, traditional PKI works swimmingly. Where is the evidence of this bit about traditional PKI working? As far as I've observed, traditional PKI works barely for small, highly centralized, hierarchical organizations and not at all for anything else. Am I missing some case studies of PKI actually working as intended? Regards, Zooko ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ___ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers ___ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences - End forwarded message - -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]
From: Kerry Bonin [EMAIL PROTECTED] Date: Thu, 27 Oct 2005 06:52:57 -0700 To: [EMAIL PROTECTED], Peer-to-peer development. [EMAIL PROTECTED] Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] There are only two good ways to provide man-in-the-middle resistant authentication with key repudiation in a distributed system - using a completely trusted out of band channel to manage everything, or use a PKI. I've used PKI for 100k node systems, it works great if you keep it simple and integrate your CRL mechanism - in a distributed system the pieces are all already there! I think some people are put off by the size and complexity of the libraries involved, which doesn't have to be the case - I've got a complete RSA/DSA X.509 compliant cert based PKI (leveraging LibTomCrypt for crypto primitives) in about 2k lines of C++, 30k object code, works great (I'll open that source as LGPL when I deploy next year...) The only hard part about integrating into a p2p network is securing the CA's, and that's more of a network security problem than a p2p problem... It's great to see this guy showing up yet another of the false dogmas of the crypto hacker community: PKI can't work. According to this view, only old fogies and tight ass bureaucrats believe in certifying keys. All the cool kids know that the best key is a bare key. After all, MITM attacks never really happen, this was just an invented threat designed to force poor college kids into paying hundreds of dollars a year for a verisign certificate. But when we come into the P2P world things look very different. Where MITM would require special positioning in the old net, in a distributed P2P network, everyone's a MITM! Every key has passed through dozens of hands before you get to see it. What are the odds that nobody's fucked with it in all that time? You're going to put that thing in your mouth? I don't think so. Using certificates in a P2P network is like using a condom. It's just common sense. Practice safe cex! CP
