P2P-Zone - View Single Post - How would you manage identities in decentralized p2p?

SA_Dave · 06-09-02, 10:53 PM

kento you might want to read this too. VLAIBB's Bubble2Bubble idea has alot to do with my idea of incorporating centralised chat into this "trust" system.

I did read that original thread before and I reread it just before I posted. The only problem with this is how to accomodate mobile users ie. people using a pc at work & one at home, whilst providing the greatest security. It makes sense for me for the key to be related to the processor. This would make it unique as no two computers will have the same fingerprint. However, if the key could be freely copied & used from one pc to the next, then it would either need another means of verification or it would be a rather weak measure. This would ultimately leave all the security of the system in the hands of the end-user. The end-user is the weakest link in any security system, no matter how secure, although I'd like to think that most p2p users have the requisite smarts!

Perhaps it would be best to have some sort of alternate identity or alias, but then how would this be "pooled" with any others that actually accrue "community credits"? For example, someone could be downloading at work & sharing from home via cable simultaneously. Apart from biometric identification methods, which aren't widespread amongst home pc users in general, there's very little I can think of offhand to allow for this. Maybe a private key uploaded to a password-protected ftp from work, assuming the "trust" account was established there, which could be decrypted at home with the relevant password. This could allow the user to temporarily bypass the cpu-fingerprinting mechanism and later generate a "new" key for the current processor, with the relevant details from the original identity embedded into this "alias" key. If a motherboard/cpu upgrade was performed, the program itself could theoretically do all of this automatically, assuming that the key wasn't lost in the process. Of course it might require a password lock or something similar.

I'm sure someone can think of something a little simpler! I tend to overcomplicate things.

06-09-02, 10:53 PM	#26
SA_Dave Guardian of the Maturation Chamber Join Date: May 2002 Location: Unimatrix Zero, Area 25 Posts: 462	kento you might want to read this too. VLAIBB's Bubble2Bubble idea has alot to do with my idea of incorporating centralised chat into this "trust" system. I did read that original thread before and I reread it just before I posted. The only problem with this is how to accomodate mobile users ie. people using a pc at work & one at home, whilst providing the greatest security. It makes sense for me for the key to be related to the processor. This would make it unique as no two computers will have the same fingerprint. However, if the key could be freely copied & used from one pc to the next, then it would either need another means of verification or it would be a rather weak measure. This would ultimately leave all the security of the system in the hands of the end-user. The end-user is the weakest link in any security system, no matter how secure, although I'd like to think that most p2p users have the requisite smarts! Perhaps it would be best to have some sort of alternate identity or alias, but then how would this be "pooled" with any others that actually accrue "community credits"? For example, someone could be downloading at work & sharing from home via cable simultaneously. Apart from biometric identification methods, which aren't widespread amongst home pc users in general, there's very little I can think of offhand to allow for this. Maybe a private key uploaded to a password-protected ftp from work, assuming the "trust" account was established there, which could be decrypted at home with the relevant password. This could allow the user to temporarily bypass the cpu-fingerprinting mechanism and later generate a "new" key for the current processor, with the relevant details from the original identity embedded into this "alias" key. If a motherboard/cpu upgrade was performed, the program itself could theoretically do all of this automatically, assuming that the key wasn't lost in the process. Of course it might require a password lock or something similar. I'm sure someone can think of something a little simpler! I tend to overcomplicate things.