Auto 1 slot to each hub a user is in
Moderator: Moderators
Cologic
Quote:
I'll argue against that. As long as people upload reasonably, I would claim the individual hubs are fairly unimportant
(and dispute what you said in a previous post about looking at this through the point of view of a hub).
Well "individual hubs are fairly unimportant", Hmmm, remove them and what are you left with?
Quote:
You've given no compelling reason to make DC++ behave the way you want. If you have another idea, feel free to suggest it. Do not,
however, come in and whine "okay, so my ideas suck. You think of something. Or else I'll just keep whining." That's accomplishes
nothing positive
If thats all you got from that, you missed the point entirely, I did not say my idea sucks. I was pointing out that this is not a new problem, and there have been ideas before mine and still it goes round and round, and nothing has been done.
If you think this was all about whinning , well that explains your attitude. Sorry I forced you this.
Beleive me when I say , I have re read this thread several times over, and I have reconcidered many thing while doing it , and have made an effort to see things from the other posters point of veiw, and in most cases , I can understand what they say , but in others , it seems like just stubborness and not wanting to beleive that ++ isnt perfect.
I am far from done with this , and I am sorry you see this as whinning , but thats your perogative.
Sarf ,
This thread has gone back and forth on the community VS the Hub thing.
It changes to suit the point, but I can agree to disagree.
I'll argue against that. As long as people upload reasonably, I would claim the individual hubs are fairly unimportant
(and dispute what you said in a previous post about looking at this through the point of view of a hub).
Well "individual hubs are fairly unimportant", Hmmm, remove them and what are you left with?
Quote:
You've given no compelling reason to make DC++ behave the way you want. If you have another idea, feel free to suggest it. Do not,
however, come in and whine "okay, so my ideas suck. You think of something. Or else I'll just keep whining." That's accomplishes
nothing positive
If thats all you got from that, you missed the point entirely, I did not say my idea sucks. I was pointing out that this is not a new problem, and there have been ideas before mine and still it goes round and round, and nothing has been done.
If you think this was all about whinning , well that explains your attitude. Sorry I forced you this.
Beleive me when I say , I have re read this thread several times over, and I have reconcidered many thing while doing it , and have made an effort to see things from the other posters point of veiw, and in most cases , I can understand what they say , but in others , it seems like just stubborness and not wanting to beleive that ++ isnt perfect.
I am far from done with this , and I am sorry you see this as whinning , but thats your perogative.
Sarf ,
This thread has gone back and forth on the community VS the Hub thing.
It changes to suit the point, but I can agree to disagree.
That's why the FP hashes the client+the previously unseen randomly generated data from the hub machine.cologic wrote:Find a hash of a known good client and send it to the FP. The FP then handles everything else on its own, including generating the correct responses to the hub's random challenges...
This gets into the issue GargoyleMT brought up of assuming a secure host/FP program. That's the issue I'm gonna have to sleep on...cologic wrote: Alternatively, reverse engineer the FP, and rewrite it to not bother checking the identity of the local client at all, but simply to allow the user to pick a client to spoof (and use a hash accordingly).
?Soap?
Reality is what you can get away with.
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: One more thought...
Well, that's the key question. You had a good point before about PGP (or GPG) not being any less secure because it's open source.Soap wrote:If there is a "trusted" host.
[snip]
please feel free to poke more holes,
no thanks to blanket dismissals.
In this same vein, there are discussions online about similar issues, particularly by game developers about copy protection, and even among hardware key manufacturers ("dongles"). It's fascinating discussion, but I don't think a solution exists, because you don't control/trust the PC at any level. Perhaps there is some mathematical magic that can be worked to devise algorithms that get around this (seemingly) basic fact, but I think it's pretty much unassailable. So the question is: how much trouble do you want to go through to protect your product?
Maybe there are solutions out there. Although there are some talented people coding DC++ and its derivatives, mathematicians we are not. Better not to think up our own solution without basing it on something else, or at least getting a good suvey of the field. (Like Kerberos, it's good for what it does, but it seems to make a basic assumption that doesn't fit DC++'s reality.)
Well, I guess the point is moot, whether it's dynamically fetched, or pulled PGP style from a public keyserver, it can still be retrieved by a third party and used to send back information in the format of your fingerprinting programSoap wrote:PS, in response to cloning FP program and hub public key...the hub public key does not have to be static.
Well, I may be wrong about some of the things in this post, but I think I've given good consideration to them. (Hopefully nothing I've said will make me say 'duh' later in response.)
Food for thought never hurts.
[RAMBLE]
PGP is open source.
PGP is (believed to be) secure.
BUT, PGP is not what you trust.
1A.You trust yourself.
1B.You trust the secretness of your secret key.
2A.You trust your friend on the other end of the vast chasm.
2B.You trust the secretness of their secret key.
3. PGP (public key encryption in general) assumes two trustworthy ends, and provides a trustworthy bridge between.
We have:
1. One trustworthy end. (Hub owners - you do understand your scripts, don't you?
)
2. Trustworthy enough-for-all-extents-and-purposes middle --> no bridge needed.
3. Untrustworthy end. (client)
(without major miracle) My idea would do little but:
1.Add GREATLY to hub machine resource load.
2.Add SLIGHTLY to client machine resource load.
3.Add SLIGHTLY to network bandwidth load.
4.Add GREATLY to missplaced trust.
[/RAMBLE]
The only salvation I see now is diminished expectations.
?Soap?
PGP is open source.
PGP is (believed to be) secure.
BUT, PGP is not what you trust.
1A.You trust yourself.
1B.You trust the secretness of your secret key.
2A.You trust your friend on the other end of the vast chasm.
2B.You trust the secretness of their secret key.
3. PGP (public key encryption in general) assumes two trustworthy ends, and provides a trustworthy bridge between.
We have:
1. One trustworthy end. (Hub owners - you do understand your scripts, don't you?
)2. Trustworthy enough-for-all-extents-and-purposes middle --> no bridge needed.
3. Untrustworthy end. (client)
(without major miracle) My idea would do little but:
1.Add GREATLY to hub machine resource load.
2.Add SLIGHTLY to client machine resource load.
3.Add SLIGHTLY to network bandwidth load.
4.Add GREATLY to missplaced trust.
[/RAMBLE]
The only salvation I see now is diminished expectations.
?Soap?
Reality is what you can get away with.
Sorry for the double posts, not used to being unable to edit.
The need to issue and require the switch to a new version of the FP every time a "crack" for the previous version becomes commonplace.
This would require a closed source FP, with a secret hidden in the binary, and would only last as long as the secret remained hidden.
OR
This would require security support at the OS level, which rules GNU/Linux and the BSD flavors right out, and that's just moral molassas.
OR
This would require a client machine allowing the hub machine to run unseen code on their machine, and that's just BS.
So, I have not given up yet, my search continues, for windmills need chasing.
?Soap?
Diminished expectations =Soap wrote: The only salvation I see now is diminished expectations.
The need to issue and require the switch to a new version of the FP every time a "crack" for the previous version becomes commonplace.
This would require a closed source FP, with a secret hidden in the binary, and would only last as long as the secret remained hidden.
OR
This would require security support at the OS level, which rules GNU/Linux and the BSD flavors right out, and that's just moral molassas.
OR
This would require a client machine allowing the hub machine to run unseen code on their machine, and that's just BS.
So, I have not given up yet, my search continues, for windmills need chasing.
?Soap?
Reality is what you can get away with.
Obviously, that enough hubs exist to adequately serve the DC userbase is important. However, the particular identities or makeups of those hubs is not, as DC functions reasonably well as a single, unified network, across whatever hubs make themselvs available.Well "individual hubs are fairly unimportant", Hmmm, remove them and what are you left with?
My point is: suppose a client is connected to 10 hubs, and has 5 slots open. Then, that some hubs' users aren't getting uploads is not important, as the files are still propagating around the DC network as a whole. It is in this sense that individual hubs are unimportant.
Most others here don't seem to regard it as a problem, particularly... Thus not having done anything about it.I was pointing out that this is not a new problem, and there have been ideas before mine and still it goes round and round, and nothing has been done.
DC++ isn't perfect. That doesn't imply your idea is any good.it seems like just stubborness and not wanting to beleive that ++ isnt perfect.
WOW
Quote:
Obviously, that enough hubs exist to adequately serve the DC userbase is important. However, the particular identities or makeups of
those hubs is not, as DC functions reasonably well as a single, unified network, across whatever hubs make themselvs available.
My point is: suppose a client is connected to 10 hubs, and has 5 slots open. Then, that some hubs' users aren't getting uploads is not
important, as the files are still propagating around the DC network as a whole. It is in this sense that individual hubs are unimportant.
I resent you thinking of hubs as a slot slut for your client.
Obviously, that enough hubs exist to adequately serve the DC userbase is important. However, the particular identities or makeups of
those hubs is not, as DC functions reasonably well as a single, unified network, across whatever hubs make themselvs available.
My point is: suppose a client is connected to 10 hubs, and has 5 slots open. Then, that some hubs' users aren't getting uploads is not
important, as the files are still propagating around the DC network as a whole. It is in this sense that individual hubs are unimportant.
I resent you thinking of hubs as a slot slut for your client.
Re: To those who say it is "not possible"
You mix completely different things. PGP is believed to be algorhitmically secure (or logically if you want), while your proposed system is just phillosophically secure (no achievement in comparison with current state).Soap wrote:My ass!yilard wrote:Just few words: This is not possible.
Encrypted binary checking is not a new idea.
Public key encryption is not a new idea.
Public key query/response methods of authentication is not a new idea.
You probably have all three systems running on your machine as we speak.
Is PGP insecure by nature of it's source being open?
You just shift certain responsibility from DC client itself to third program. But that doesn't make the system as a whole any less vulnerable.
How would you ensure integrity of FP? It is really easy to modify compiled program. I can suggest one obvious modification (no need to fiddle with keys or anything): just make FP not to fingerprint truly running client but
valid plain dummy client, keps just for the purpose of fooling the system.
Clear now?
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM
-
no_dammagE
- Posts: 5
- Joined: 2003-02-18 03:55
- Contact:
for hashing we can use SHA1, it is a really progressive algorythm.
the current architecture of dc wasnt made for multi hubbing.
I have a model which would let the hubs work with slots again. But, it is impossible with current DC architecture and will make yakc (yet another kazaa clone) and it is not the goal of DC.
Its current architecture makes it one of the best networks available now.
You just have to let every user to connect to every hub. Then, all hubs are equalent.
The simpliest way to reduce leeching is:
* make 1 hub-limit again. But it wont work because then everyone will take just an older version or a mod.
* make x slots per hub. It is already doable per scripts. It doesnt work, too, the users just take the next hub.
* reduce amount of hubs, to which a user is connected (my idea, it is very relative to user's activity)
* make priority system.
I thought now about that and i like it. Then the user has to stay in hubs and in not many of them. Because if he uploads a small chunk to every hub, he doesnt get enough points. That system is also not "killable" by mods because the score is not saved locally.
First positive point: sharing users will get priority
Second positive point: people will add more new files to get more score (very important)
First negative point: if you are new on a hub, you will get problems getting a file
Second negative point: new users will have problems getting files globally
Req for such system: first we will need a gnutella-like remote queing system (easy to do)
user hash implementation
why that?
If i will call myself eminem or gandalf, i will get score everywhere and steal someones score.
What can be used for hashing? Randomize matrix, it is not hard to do.
But what about NMDC users? how will they get the hash???
Then, the client will have either to share a GUID file or we will get a problem with score.
Problems sharing GUID file? Massive: you can search for them and create an own one with someone's GUID and so steal his score.
without GUID it is impossible to identify a user and NMDC doesnt support GUID and it is closed source ...
the current architecture of dc wasnt made for multi hubbing.
I have a model which would let the hubs work with slots again. But, it is impossible with current DC architecture and will make yakc (yet another kazaa clone) and it is not the goal of DC.
Its current architecture makes it one of the best networks available now.
You just have to let every user to connect to every hub. Then, all hubs are equalent.
The simpliest way to reduce leeching is:
* make 1 hub-limit again. But it wont work because then everyone will take just an older version or a mod.
* make x slots per hub. It is already doable per scripts. It doesnt work, too, the users just take the next hub.
* reduce amount of hubs, to which a user is connected (my idea, it is very relative to user's activity)
* make priority system.
I thought now about that and i like it. Then the user has to stay in hubs and in not many of them. Because if he uploads a small chunk to every hub, he doesnt get enough points. That system is also not "killable" by mods because the score is not saved locally.
First positive point: sharing users will get priority
Second positive point: people will add more new files to get more score (very important)
First negative point: if you are new on a hub, you will get problems getting a file
Second negative point: new users will have problems getting files globally
Req for such system: first we will need a gnutella-like remote queing system (easy to do)
user hash implementation
why that?
If i will call myself eminem or gandalf, i will get score everywhere and steal someones score.
What can be used for hashing? Randomize matrix, it is not hard to do.
But what about NMDC users? how will they get the hash???
Then, the client will have either to share a GUID file or we will get a problem with score.
Problems sharing GUID file? Massive: you can search for them and create an own one with someone's GUID and so steal his score.
without GUID it is impossible to identify a user and NMDC doesnt support GUID and it is closed source ...
Well, I did say viable; I guess I've had bad experiences with DCgui on Linux, though I've never tried it on OS X.NMDC isn't the only client for OS X - DCgui works on OS X, too..
That's okay; it seems to work quite well.the current architecture of dc wasnt made for multi hubbing.
You're reinventing the ideas in this thread; please read it to see how others have developed them.* make priority system.
I thought now about that and i like it. Then the user has to stay in hubs and in not many of them. Because if he uploads a small chunk to every hub, he doesnt get enough points. That system is also not "killable" by mods because the score is not saved locally.
