Version Authentication

[Da8add1e]

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

[ivulfusbar]

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 :)

Short answer; No.
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 ,))

[eHast]

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.

[Dj_Offset]

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.

[eHast]

My point was that the problem is much harder than that. The problem is a lot harder than something you can adress with just a good protocol. (Ie network protocol, not authentication protocol.) But if you have ideas please do post them and you can get some input on them.

[Da8add1e]

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

[volkris]

Version authentication. I really can't think of a way to do this in an OSS program.

OSS has nothing to do with it, please don't spread the false impression that it does.

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 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.

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]

[Dj_Offset]

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 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.

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.
-- 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...

[volkris]

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.

How do you propose to encourage users to share voluntarily?

[eHast]

Version authentication. I really can't think of a way to do this in an OSS program.

OSS has nothing to do with it, please don't spread the false impression that it does.

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.

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.)

[volkris]

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.

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.

My point is that I have never seen or heard of a protocol which could do this.

This is because the problem really has nothing to do with the protocol.
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.

[Da8add1e]

And yet it is very often that a closed source client is hacked before the open source one.

Although obscurity is never a substitute for security

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.

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.

[eHast]

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.

And yet it is very often that a closed source client is hacked before the open source one. (...)

My point is that I have never seen or heard of a protocol which could do this.

This is because the problem really has nothing to do with the protocol.

We are more or less arguing the same thing. Even if you may not have realized it yet. ;-)

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. ;-)

[volkris]

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]

The only problem is that others will see what you're writing and interpret the wrong way, thinking that open sourcing is inherently insecure.(...)

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. ;-)