Version Authentication
Moderator: Moderators
Version Authentication
Could some version authentication be implemented to help combat the Un-Official versions that keep popping up, i know this almost certainly require another extension to the protocol but it would be nice
I realise that doing this in a way that could be detected reliably in a NM-Hub script would be difficult (if not impossible) but it would allow DCH and other still developing Hub-softs to include it
also it could pave the way for global Upload/Download limiting (0 to -25% Upload & Download) and other features that would be too unsafe to do otherwise
I realise that doing this in a way that could be detected reliably in a NM-Hub script would be difficult (if not impossible) but it would allow DCH and other still developing Hub-softs to include it
also it could pave the way for global Upload/Download limiting (0 to -25% Upload & Download) and other features that would be too unsafe to do otherwise
Need NOT Greed (don't abuse poor countries)
Pay the Poor (increase minimum wage)
Tax the Rich (100% SuperTax rate)
(Do ya think thats maybe a little left-wing?)
Pay the Poor (increase minimum wage)
Tax the Rich (100% SuperTax rate)
(Do ya think thats maybe a little left-wing?)
-
- Posts: 506
- Joined: 2003-01-03 07:33
Re: Version Authentication
Short answer; No.Da8add1e wrote:Could some version authentication be implemented to help combat the Un-Official versions that keep popping up, i know this almost certainly require another extension to the protocol but it would be nice :)
Longer answer; Maybee, but probably not worth the effort...
we-have-to-live-with-certain-limitation-when-it-comes-to-this-protocol-and-filesharing-in-general-ly'ers ,))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
Version authentication. I really can't think of a way to do this in an OSS program. Neither can I recall reading about an established method to do it.
Perhaps someone has a good idea though. It's always nice to have a brain puzzle like this to think about in any case. ;-)
And just to start off, the system needs to be resistant against active attacks. The attacker has full access to source and has full access to the computer the program is running on.
Perhaps someone has a good idea though. It's always nice to have a brain puzzle like this to think about in any case. ;-)
And just to start off, the system needs to be resistant against active attacks. The attacker has full access to source and has full access to the computer the program is running on.
I think you are looking the wrong here... You want to authenticate the software
when the protocol really is flawed. I'm working on a new protocol design codename "DCng", I'm trying to find all pitfalls in todays protocol... and that's quite a few!
I'll post it here when it's mostly done.
when the protocol really is flawed. I'm working on a new protocol design codename "DCng", I'm trying to find all pitfalls in todays protocol... and that's quite a few!
I'll post it here when it's mostly done.
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
well my first thought was that the VS .NET program ID that each program is given when compiled could be used to some degree, however theres not a lot to stop that from being copied (its just a number after all)
so, it might as well be a static version number like it has atm for all the good that would do and i don't think theres any real way to do it either now that i have thought of it for a while
With closed source i think its still impossible as clients could packet log and decomplile just about anything the only way thats been proven to work is a public but closed source client and a secure (unreleased) server, using SSL or TSL or something
so, it might as well be a static version number like it has atm for all the good that would do and i don't think theres any real way to do it either now that i have thought of it for a while
With closed source i think its still impossible as clients could packet log and decomplile just about anything the only way thats been proven to work is a public but closed source client and a secure (unreleased) server, using SSL or TSL or something
Need NOT Greed (don't abuse poor countries)
Pay the Poor (increase minimum wage)
Tax the Rich (100% SuperTax rate)
(Do ya think thats maybe a little left-wing?)
Pay the Poor (increase minimum wage)
Tax the Rich (100% SuperTax rate)
(Do ya think thats maybe a little left-wing?)
OSS has nothing to do with it, please don't spread the false impression that it does.eHast wrote:Version authentication. I really can't think of a way to do this in an OSS program.
I disagree pretty strongly. The systemic model of DC is flawed, and only in a few but very basic ways. The protocol itself just needs a little polish.Dj_Offset wrote:the protocol really is flawed. I'm working on a new protocol design codename "DCng", I'm trying to find all pitfalls in todays protocol... and that's quite a few!
So Da8add1e, ivulfusbar had it pretty correct with what he said.
No, there's no way to authenticate the client, but if you design the system right you won't have to.
Look at it this way: by designing the system so that you need to approve clients you're limiting the amount of advancements that can come from unoffical clients. But, by designing the system so that the client doesn't really matter you allow a hundred different unoffical clients to attack the problems in a hundred different creative ways. Everyone wins![/quote]
Yes, I agree with you, because thats exactly what I mean also (however I used the word protocol when I was referring to the system).volkris wrote:I disagree pretty strongly. The systemic model of DC is flawed, and only in a few but very basic ways. The protocol itself just needs a little polish.Dj_Offset wrote:the protocol really is flawed. I'm working on a new protocol design codename "DCng", I'm trying to find all pitfalls in todays protocol... and that's quite a few!
I'm working on a new concept called the DCng (next generation) which is a new system, and an improved protocol.
-- Okay, it's an entirely new protocol and system, but it is still based on the idea of having hubs and clients and resembles DC in most ways.
A rewritten protocol handler should be enough, for any DC client to support this protocol...
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
How do you propose to encourage users to share voluntarily?Dj_Offset wrote: Yes, I agree with you, because thats exactly what I mean also (however I used the word protocol when I was referring to the system).
I'm working on a new concept called the DCng (next generation) which is a new system, and an improved protocol.
OSS has a lot to do with it. If you have closed source you can use obscurity for this purpose. Although obscurity is never a substitute for security (or authenticity in this case) it's a hell of a lot easier to do.volkris wrote:OSS has nothing to do with it, please don't spread the false impression that it does.eHast wrote:Version authentication. I really can't think of a way to do this in an OSS program.
My point is that in an OSS program you /have/ to use a provably secure protocol. There are no shortcuts that you can use.
Your protocol has to be resiliant against people with complete control of the client. And that is a pretty hard problem. (Understatement of the year.)
My point is that I have never seen or heard of a protocol which could do this. And that is after several years of studying computer science, cryptography etc at university. That doesn't mean it's impossible to do it, but it sure as hell is a very hard problem. And quite honestly I doubt that we will see a working implementation of it in the next version of DC++. (Or any other P2P program for that matter.)
And yet it is very often that a closed source client is hacked before the open source one. It's kind of funny, actually, but I supose it might have something to do with the different methods of attacking each.eHast wrote:OSS has a lot to do with it. If you have closed source you can use obscurity for this purpose. Although obscurity is never a substitute for security (or authenticity in this case) it's a hell of a lot easier to do.
This is because the problem really has nothing to do with the protocol.My point is that I have never seen or heard of a protocol which could do this.
Nobody really actually hacks the protocol to do unforseen things. All of these uncooperative clients implement the protocol well enugh. They just use the same, unhacked protocol to do different things.
The key is to change the system behind the protocol, not really the protocol itself. Discovering/hacking the protocol will let unapproved clients communicate with the network, but that is completely seperate from actually abusing the other clients.
The solution is simply to adjust the system so that people have reason to share and are held more accountable for their actions. There is currently no reason for a person to actually share, and that's the whole basis of the problem. There is only reason for people to claim that they're sharing.
And yet it is very often that a closed source client is hacked before the open source one.
these are both the same point imo, closed source is simply obscuring the source not securing it, anyone with a decompiler and some knowledge of windows messaging system can quite quickly hack thier way through even the most suposedly secure program.Although obscurity is never a substitute for security
only if data sent from a userA -----> userB can be guaranteed of having the same construction origin can the comunication be regarded as secure.
even if the data is encrypted it's no indication that the information was constructed in the intended way, the encyption is just one process in sending the data
<snip>
[probably best not to describe ways to exploit DC protocol but i'm sure you know what i mean]
therefore security can only be guaranteed when the client program is secure, but as eHast pointed out theres no sure way to do that.
Need NOT Greed (don't abuse poor countries)
Pay the Poor (increase minimum wage)
Tax the Rich (100% SuperTax rate)
(Do ya think thats maybe a little left-wing?)
Pay the Poor (increase minimum wage)
Tax the Rich (100% SuperTax rate)
(Do ya think thats maybe a little left-wing?)
We are more or less arguing the same thing. Even if you may not have realized it yet. ;-)volkris wrote:And yet it is very often that a closed source client is hacked before the open source one. (...)eHast wrote:OSS has a lot to do with it. If you have closed source you can use obscurity for this purpose. Although obscurity is never a substitute for security (or authenticity in this case) it's a hell of a lot easier to do.
This is because the problem really has nothing to do with the protocol.My point is that I have never seen or heard of a protocol which could do this.
First off, I think the main source of confusement comes from my use of the word "protocol". I mean a cryptographic protocol, not a P2P protocol. "No such protocol" was meant as a much broader term. My point is that I have never heard of /any program what so ever/ which can securely and accurately authenticate the client.
In closed source software you often have things like CD-keys and encrypted packages. None of these are usable in a OSS project, since the keys would be open and attackable by software. (And note that you can't use a system which authenticates the user, the point is that the user is the one attacking the system.)
In other words, the question is "How do I make sure that this user is running my program?" My answer is that "You can't." With closed source you can put in some stuff which makes it a bit harder, but you'll never get 100% authentification. (But for many you can get "close enough", if the game has outlived it's shelf life when it's hacked then you have succeded.)
In conclusion I'm not complaining about OSS. I'm complaining about information theory and what a bitch it is when you can't do what you want. ;-)
The only problem is that others will see what you're writing and interpret the wrong way, thinking that open sourcing is inherently insecure. I'm no huge OS zealot or anything, but I want people to at least make up their mind about it based on real qualities, as opposed to percieved ones.eHast wrote:In conclusion I'm not complaining about OSS. I'm complaining about information theory and what a bitch it is when you can't do what you want.
If they're that stupid, let them. We'll just leave a few pointy sticky laying around and hopefully they'll pick one up and stab themselves to death. ;-)volkris wrote:The only problem is that others will see what you're writing and interpret the wrong way, thinking that open sourcing is inherently insecure.(...)