How would you manage identities in decentralized p2p?

[TankGirl]

We have lately seen the death of several centralized p2p networks: Napster, AudioGalaxy and Aimster being the showcase victims of content industry harassment. True decentralization is clearly the way to go to have safe p2p networks. If any willing user can easily initiate the formation (or re-formation) of the network from anywhere in the world, it becomes virtually impossible to kill. Gnutella is a living proof-of-concept for this principle.

Decentralization means that there will be no outside authority – VeriSign, MicroSoft or Napster - to keep books of who is who in the network. No trusted third party will be there to guarantee that peers really are really whom they claim to be. We have to know it and remember it ourselves. To do that we need unique, permanent and verifiable peer identities. Nicks (even with random additions such as we have seen in WinMX's WPN) are unsuitable for this as peers can pick and change their nicks freely, and there will be no outside authority to prevent nick collisions.

What would you use as a unique, permanent and verifiable peer identifier in these circumstances?

My own candidate would be the public encryption key from an asymmetric crypto key pair. It would be relatively easy to make unique. Even moderate key lengths (say 160 bits for elliptic curve cryptography) combined to some quality randomness in the key picking process would make the probability of an identity collision astronomically small. Strong public keys would also be very persistent, as it would take months of processor time from dedicated server farms to break them. And they would also be nicely verifiable as only the real owner of the private key would be able to prove his/her identity when so asked.

Your thoughts?

- tg

[Dawn]

I think I like it when you wink at us

[kento]

i'm afraid i don't understand.

[pod]

There probably is no reasonable way to implement a P2P authentication system. Either a single machine has to know about all users or everyone has to know about all users. Otherwise it's a crapshoot.

Even the content on FreeNet will be damaged or eliminated if enough nodes go down and it cannot be accessed or found. That's just because no single node has all the content; if every node has the total content, you have to worry about bandwidth (to synchronize), etc; if every node holds a piece of the content (overlapping and duplicated of course) then you have to worry about data going missing, or maybe just becoming unreachable on the network (ttl running out).

This is a very difficult problem because you can't treat the P2P network as one big distributed computer. The environment is too fluid, too unreliable. Nodes come and go. They have various levels of bandwidth available (nearly always too small for our purposes). Even if you could somehow pull it off, how would you store this data? It would quickly become too large an amount of stuff to shuffle around and query and update non-stop.

My opinion: cannot be done. Of course, I'm no scientist, and don't even play one on TV.

As for machine-friendly unique IDs... there's always the GUID, guaranteed to be unique when generated. Then again, that's hardly an issue, user ids would also have to be unique, no?

[TankGirl]

Originally posted by pod
Either a single machine has to know about all users or everyone has to know about all users.

Why?

Isn't it enough to know only those peers that you are connected to and deal with directly? More like memorizing and recognizing your hotlist, ignore list and perhaps a few thousand of your recent transfer and chat contacts. You could still communicate and co-operate with unknown peers using agreed-on protocols.

- tg

[jaan]

Originally posted by pod
There probably is no reasonable way to implement a P2P authentication system.

i think tankgirl just described one: all users are identified by their public key.

so whenever you communicate with a user in your hotlist, the software will issue a cryptographic challenge based on his/her public key. this way you can be 100% sure that the user you are chatting with really is the one you added to your hotlist in the first place (assuming that his/her private key hasn't leaked out).

- jaan

[kento]

Originally posted by TankGirl

Why?

Isn't it enough to know only those peers that you are connected to and deal with directly? More like memorizing and recognizing your hotlist, ignore list and perhaps a few thousand of your recent transfer and chat contacts. You could still communicate and co-operate with unknown peers using agreed-on protocols.

- tg

<kento blushes> okay maybe i am still reading you wrong TG....but it sounds like all you are really wanting or asking for is for a "hotlist" like in Napster? that shouldn't be impossible to implement....

however....

Decentralization means that there will be no outside authority – VeriSign, MicroSoft or Napster - to keep books of who is who in the network. No trusted third party will be there to guarantee that peers really are really whom they claim to be. We have to know it and remember it ourselves. To do that we need unique, permanent and verifiable peer identities. Nicks (even with random additions such as we have seen in WinMX's WPN) are unsuitable for this as peers can pick and change their nicks freely, and there will be no outside authority to prevent nick collisions.

and

What would you use as a unique, permanent and verifiable peer identifier in these circumstances?

so...ranger inc....can't do it? microsoft can't do it? riaa can't do it? why then do you want to do it TG? This disturbs me....why does it matter?

-kento

[TankGirl]

Originally posted by kento
so...ranger inc....can't do it? microsoft can't do it? riaa can't do it? why then do you want to do it TG? This disturbs me....why does it matter?

Anybody could establish their own unique identity as a peer in the network. But with verified identities you could start building trust relationships, protected invite-only groups etc. 'above' the public network structure. This would allow the emergence of much more sophisticated social structures and content distribution chains than what we have seen so far.

A practical example: say you have a good hotlisted contact with whom you would like to do some privileged sharing (larger shares, bandwith prioritizing). To do this you want to know reliably who you are dealing with so that no outsider could 'steal' the given privileges.

Reliable peer identities would also make a good basis for an intelligent leech control system. If your client would automatically reward (with bandwidth, shorter queue times etc.) peers that have contributed to you recently, non-spoofable identities would be a must.

- tg

[kento]

okay this does sound much more interesting now that you've explained it a little more fully so that even i could get it.

okay i like your explanation...now let me play "devil's advocate" what if you are in the minority as far as bandwidth is concerned for whatever reasons whether they be "socio-enoconic" or "lack of availablity" to higher speed accesses in your area...wouldn't such "controls" (bandwidth sharing, queue-control) be "wasted" on such users...and not really matter at all?

just would appear that maybe this "proposed p2p standard" you are suggesting...would alienate many users?

[TankGirl]

Originally posted by kento
what if you are in the minority as far as bandwidth is concerned for whatever reasons whether they be "socio-enoconic" or "lack of availablity" to higher speed accesses in your area...wouldn't such "controls" (bandwidth sharing, queue-control) be "wasted" on such users...and not really matter at all?

just would appear that maybe this "proposed p2p standard" you are suggesting...would alienate many users?

There are many ways to implement leech control, and they don't need to follow any mechanistic bandwidth-for-bandwidth rule. If you find and receive good original content form a dial-up why not to reward that dial-up, even if the delivery of the stuff is inevitably slow (for further elaboration of the topic see my comments in this thread). The point here is just that to have any reliable leech control or privileged sharing mechanism at all you need to have a reliable identity management system.

- tg

[zombywoof]

It would seem to me that the balance between total anonymity on a peer network and the ability to get your node learned without some sort of tracking ability by companies and agencies looking to shutdown these networks would be a very difficult task to overcome. Maybe not impossible, but understanding the design of encryption, algorithms and such used to build and design routes to do it anonymously is a bit beyond my scope of knowledge here. I'm sure there are a number of legal issues to deal with involving encryption. In laymens terms, it would seem to me that if there is some way that IP addresses can be encrypted so that they are not detected by monitoring devices, and or the peers they connect to when accomplishing a search for a particular file.

[JackSpratts]

Originally posted by oscar
It would seem to me that the balance between total anonymity on a peer network and the ability to get your node learned without some sort of tracking ability by companies and agencies looking to shutdown these networks would be a very difficult task to overcome.

something to seriously consider all right. as long as adversaries are using the power of the state to search out and persecute individuals who share their property via the internet, it provokes little but danger to trumpet ones' location and identity. if the goal of complete personal anonymity could be assured for a hotlist system then that concern might be muted, but technically this seems a long way off at present.

still, the day may come when the state takes a less draconian view of file sharing and then such a system will have important practical and social values. having a hotlist that carries over from session to session a la napster takes decentralized p2p into a whole new realm.

it’s hard to think tho that if such a system incorporated rewards it wouldn’t be totally dominated by big bandwidth/big content users. i can’t see the average dial uppers with a few dozen files, those that log on for just minutes a day, enjoying much advantage here, and they’re the majority in the networks. but it would sure be nirvana for power users. changes everything.

the goals are too worthwhile to abandon. incorporate the little users and establish anonymity and you've got a system of tremendous benefit.

- js.

[zombywoof]

Originally posted by JackSpratts




still, the day may come when the state takes a less draconian view of file sharing and then such a system will have important practical and social values.
.

- js.

That is what will ultimately determine the future of peer-to-peer networking.

[kento]

okay first off MY APOLOGIES earlier for not understanding what you were "driving at" TG


This is TOTALLY valid and vary, vary Good points....I need to study this more in order to make more intelligent and informed respones to you....but yet at the same time (even knowing I'm not an intellectual when it comes such abstract thinking and even linear concepts such as math and science which are definitely needed to be implored here to give you a decent answer to your question) I must press on and answer you even though I am not really qualified in area of programming or networking knowledge...just as a exuberant fan of filesharing and p2p in general who does use dialup and shares over 2300 songs on both KaZaA, winmx and xolox [most of the songs i got from Napster btw

okay with that said...let me again (without being fully qualified or informed) respond to:

There are many ways to implement leech control, and they don't need to follow any mechanistic bandwidth-for-bandwidth rule. If you find and receive good original content form a dial-up why not to reward that dial-up, even if the delivery of the stuff is inevitably slow (for further elaboration of the topic see my comments in this thread). The point here is just that to have any reliable leech control or privileged sharing mechanism at all you need to have a reliable identity management system.

okay tG PLEASE CORRECT me if i am wrong....at first it seemed like you wanted something more than a "GLOBAL anonymoust p2p client" is this the case?

Because what you were ORIGINALLy suggesting or implying about having "varifiable p2p identities" can be done through ESTABLISHing of rapport or "bonds" with others over ANY filesharing network through whatever means are imployed by the client to provide a basis for user interaction:

example: say "Napsterites" had its own p2p client which loaded the napsterite forum into the main window....then people could interact on the forum while trading p2p files....establishing strong bonds if desired or MAINTAINING their relative anonymity if they so desire...if you get to know someone with the same interests as you then you can then opt for a more personal exchange say maybe with using ICQ to transfer your "larger files" or even go so far as to set up a ftp for you and your friends (surprising NOT that hard to do)

this would give you that "verifiable p2p identinty" meaning "you know this is your friend/acquaintance whom you are sharing with and you TRUST their files and or identity to be valid...

second way is to use the "chat functionality" of the p2p (proposed p2p program) to determine the "legitamicy" of the other user and whether or not this is someone you would like to trade with on a regular basis then just exchange ICQ contact infos....


Finally if i may be so bold as to suggest this:

The THIRD scenario is probably the most likely for what I think it is you are wanting to convey which is this:

[b]the ability to change usernames "on the fly" like with WinMX in their "chat rooms" leads to confusion and or abuse in that i can say for example: "I am "dr.damn" and come into a winmx chat room with the monicker "dr.damn" later i can log off and combact as "mysterymanX" and no one would know the difference as the "loginname" isn't verified by any CENTRALISED source....

so TG what it seems are saying is a contradiction in the way it was said...you do want PERMANENT verifiable p2p identities (so that you know your "trusted source" isn't an RIAA dude or 'virust writer') BUT you don't want 'verifiable p2p identities' because you don't want to be busted by the riaa/mpaa/etcetera....etcetera

did i surmise this correctly?

Regards,

-kento

[kento]

JackSpratts how did i MISS your comments?? anyway a GREAT reply...and good points Oscar!

I love this place...you people really force me to think about things...and I like that.

-kento

[pod]

Originally posted by jaan
i think tankgirl just described one: all users are identified by their public key.

so whenever you communicate with a user in your hotlist, the software will issue a cryptographic challenge based on his/her public key. this way you can be 100% sure that the user you are chatting with really is the one you added to your hotlist in the first place (assuming that his/her private key hasn't leaked out).

OK, well, that's all fine. I though were talking about user authentication. Identification is a pretty trivial issue by comparison. You can implement a P2P hotlist by performing a user search in the background. You can even ensure no one steals your identity by using public/private keys. However, this is VERY bandwidth intensive. I'm sure you've seen keys before, they're not exactly small. If everyone's running these searches on an ongoing basis, there will be some people with larger than expected bandwidth bills. (I think WinMX does not have a permanent hotlist because users are not identified uniquely enough, just by a small username.)

I mean authoritative authentication. As in, user A logs in, and everyone agrees that it is, indeed, user A, and he has access to so and so, not just because he says he's user A, but because everyone can authoritatively verify this. This problem is not a problem at all if you can have servers you trust do this for you. Who does this authentication on a free-for-all P2P network?

[pod]

Originally posted by TankGirl
Why?

Isn't it enough to know only those peers that you are connected to and deal with directly? More like memorizing and recognizing your hotlist, ignore list and perhaps a few thousand of your recent transfer and chat contacts. You could still communicate and co-operate with unknown peers using agreed-on protocols.

Because if your info happens to be stored on only a couple of nodes, and they disconnect, suddenly no one knows who you are, except you. That's not a very safe solution, see my other reply to Jaan's post.

[TankGirl]

Originally posted by kento
so TG what it seems are saying is a contradiction in the way it was said...you do want PERMANENT verifiable p2p identities (so that you know your "trusted source" isn't an RIAA dude or 'virust writer') BUT you don't want 'verifiable p2p identities' because you don't want to be busted by the riaa/mpaa/etcetera....etcetera

did i surmise this correctly?

Let’s clarify the concepts a little…

The unique, permanent and verifiable identities I am talking about are meant for machine level interactions only. As symbolic data the public encryption keys are just random-looking bit patterns to the human eye. Like physical keys they derive all their meaning from what doors they can open, what is behind those doors and who have access to the keys.

The question of anonymity is a separate issue from identity. You can build both anonymous and non-anonymous networks on permanent identities. In an anonymous network the clients could just collect objective technical data (response times, search hits, transfer speeds etc.) from each other and use them to automatically optimise network structure (supernode selection, download source selections). In a more social network you would have all the anonymous level stuff plus some socially meaningful metadata (nicks, avatars, profiles etc.) associated to identities.

Any of your friends could change their nicks and avatars as they wished but they could not force any such changes onto your recollection of them. Should a peer change its nick, your client could prompt you whether you want to start using the new given nick or rather stick to the old one. In other words, your client – basing its actions on reliable identity data - would safeguard the integrity of your social environment and bonding.

The kind of verifiability that the RIAA is interested in is to associate a particular logged online action (like sharing the latest Britney album on a p2p network) to a particular person. To do this, they try to get access to your ISP’s logs and customer data to prove that the bad guy or gal was indeed you. As the ISPs can be compromised under legal threats the best protection here is to know (as far as possible) whom you are dealing with (secure identity management) and to do all your data transfers through protected pipes so that no third parties will have any idea of what is being transferred. Here public keys as identifiers become particularly handy as they allow the encryption of all peer communications starting from the first contact requests.

- tg

[jaan]

Originally posted by pod
I mean authoritative authentication. As in, user A logs in, and everyone agrees that it is, indeed, user A, and he has access to so and so, not just because he says he's user A, but because everyone can authoritatively verify this.

well, everyone who has A's public key will be able to verify A's identity.

in other words, if you have seen user A before, you can be pretty sure it's the same A next time you chat to him/her.

sure, you have a point that if one does not have A's public key, then it becomes impossible to tell which A is the one you are looking for. however, as the public key is sent to you "automagically" first time you see A, that becomes a non-issue in most cases.

also, you seem to be right that in p2p environment it is too bandwidth intensive to implement hotlists that automatically alert you when a buddy is online. however, that's the cool thing about p2p networks: lots of things seem to be impossible at first, but nevertheless become reality later.

- jaan

[TankGirl]

Originally posted by pod
However, this is VERY bandwidth intensive. I'm sure you've seen keys before, they're not exactly small.

A 283 bit ECC key would provide the same security as a 3,072 bit RSA key, and that would be more than enough for a safe p2p identity. 283 bits would fit to 36 bytes. Doesn’t sound too big to me.

Originally posted by pod
This problem is not a problem at all if you can have servers you trust do this for you. Who does this authentication on a free-for-all P2P network?

In the first place there is only one peer that you can trust to authenticate anything, and that is you yourself. You can search identities through other peers but it is up to you to check that they are the ones they claim to be.

Originally posted by pod
Because if your info happens to be stored on only a couple of nodes, and they disconnect, suddenly no one knows who you are, except you.

Why would my contacts forget my identity when I go offline? They have my permanent public key stored on their computers. Whenever I pop back online, I can search them by their public keys and after finding them I can prove my identity to them.

- tg