New Client

[White Stripes]

github, sourceforge, google code... i dont care.... it needs to be out there where ppl can get to it... and if the primary protocol is so broken that it cant be trusted like that then it just needs to be replaced in its entirety... is it documented somewhere with the trouble spots pointed out? i still have that .zip from the leak with all the code in it but the docs cover the library and config files not the protocol...


you need to trust someone that can code... and to do that you need to put whats coded and documented out there to be worked on... but you say trust is a problem since they would be able to take down the network or use it for bad..... thing is... its already being used for bad... and slowly bleeding users... wait too long for that trust to come along and nothing will be left... ....need to take a risk that the network will actually be worked on and not abused (any more than it is)... if you cant take that risk then there is no 'network' anymore.... just a partially obscured abandonware app that will go nowhere....

you dont want it to collapse i know... but if it does then that was its fate due to too many bad users compared to good...

[White Stripes]

just for shits and giggles heres a screeny of the opennap servers from 'pauls public' (most recent) that still work... note the 'populations' ... and it only takes a few searches to figure out that most of those users are doing what im doing and connecting to multiple naps... meaning theres about 150 users total... ...whats the headcount on the 'undocumented' wpn?

[GhostShip]

We are able to get a rough headcount of users due to the patch update bar being in operation however its not ever wise to broadcast the number unless its of a decent size as that may embolden the enemy to try harder or redouble their efforts if an end seemed in sight, that is why its not published.

I have documented the entire Protocol set and also I have written up various potential solutions that involve addressing the primary weakness directly, after a lot of reading it seemed to me that the problem is that we are missing vital components from the TCP network header, to strengthen this we need to add both a UTC and full date component, this can then be hashed (diffie hellman/merkle) with the rest of the header and the hash sent out, this simple mechanism allows for the network header to be in effect digitally signed and thus verifiable, doctored packets will of course be dumped and due to the time date addition we can ensure old packets are not replayed back into the network.

Why are we not using this already ?

I am not always confident in my own logical abilities and this seemed perhaps too good to be true thus I have kept it to myself but documented it also under the heading of improved network headerr concept in case i was ever run over by a truck, now we have little to lose it seems like we can maybe look seriously at this concept and how we can implement it the problem is as you have stated Stripes its not been possible to show the material to anyone because that means giving someone ultra fine details of the existing network header that i have always kept to myself , a working knowledge of the header can as you know allow for all sort of problems and yes I didn't want any general collapse on my watch.

The utc offset can be delivered to the user as they join the network at the cache level thus ensuring the whole network can stay in lockstep.

Anyone with a powerful mind have the time to investigate this concept ?

[White Stripes]

not ever wise to broadcast the number unless its of a decent size

i might be reading in-between the lines wrong but that feels like its not that great a number....

missing vital components from the TCP network header, to strengthen this we need to add both a UTC and full date component

(emphasis mine)

good idea ... slightly bad idea... reason; not all computer clocks are 'right' .... even the ones synced with NTP or synced to a virtual clock at start... clocks drift (which is why NTP is consistently tho very intermittently correcting the computer)... beware the resolution of time you use... 

(fun/stupid trivia? the system clock onboard most unmanned spacecraft is timed to the received data rate so sent data is in sync... farther the craft the slower the clock due to the speed limit of light...)

doctored packets will of course be dumped

how will doctored packets with correct time-hash be filtered out? --- granted they or any other packet wont (shouldnt) repeat but doctored 'correct' packets could be rapid-fired at the network....

its not been possible to show the material to anyone because that means giving someone ultra fine details of the existing network header that i have always kept to myself ,

so you have the entire roadmap but cant trust anyone to drive... ...concepts aside... how long is that going to last? will the wpn be here in another 4 years? you found one programmer who created an unstable base to build on then vanished in these 4 years....


interesting concept you have tho... ...if someone can glue it into the current patch that would be really nice...

[Bluehaze]

There may be many possibilities for the Community. It is unmistakeably clear to anyone, regardless of their level of technical savvy, that the current WPN is terribly broken. Perhaps while things like the primary protocol and other issues are being solved, someone could set us up even temporarily on a simple 3-part network, like Zenar suggested in this old thread?
https://forum.winmxworld.com/index.php?topic=12160.0.html

This is a little more centralized, and maybe we could get a reprieve from the WPN's tormenters? This model would provide filesharing and chat, while features could be added? I apologize as I have no technical skills, but I even wonder if perhaps much of the existing code could be imported to such a simplified project.

I know we won't settle for anything less than what we have already got, but please consider, what do we have? I hope we will not leave the possible at the mercy of what we cannot yet arrange.

This is just a recurring thought...No one should get "beat up" over the new client project.

[hollow87]

I have a few things to say since this discussion is all about GhostShip telling people what to do and nothing about taking advice from the community

I cannot afford to be distracted from the core topic so trivially Stripes I am here soley to discuss the way ahead and how we are going to reach that place, I know its been hard on all of the users but its also been a weight on my own shoulders of tremendous proportions, thus for now I choose not to become embroiled in doom and gloom but I do understand why you have reached this stage its a place many have hit way earlier than yourself.

There will be plenty of time for recriminations when we fail trying rather than giving up before our human resources are fully expended.

Stripes was offering advice about how its not just the primary portion that needs redone to think about moving ahead its practically all of them.

I have documented the entire Protocol set and also I have written up various potential solutions that involve addressing the primary weakness directly, after a lot of reading it seemed to me that the problem is that we are missing vital components from the TCP network header, to strengthen this we need to add both a UTC and full date component, this can then be hashed (diffie hellman/merkle) with the rest of the header and the hash sent out, this simple mechanism allows for the network header to be in effect digitally signed and thus verifiable, doctored packets will of course be dumped and due to the time date addition we can ensure old packets are not replayed back into the network.

Diffie-Hellman-Merkle is not a hashing algorithm its a key exchange one.

Unless your thinking about an T-OTP type thing (time based one time password)

And no hashing with the UTC time stamp does not make it digitally singable as all they have to do it match what your doing and guess what its back to square one.

You want a digitally singable look at RCA, RCA also has an asymmetric encryption.

Want security? Get a new protocol, make it a bit more centralized. or harder to get onto the network for a client, malicious or not (by harder I mean computationally harder.  This is a essentially a Sybil attack on the network only a few ways to deal with that.

That's why more centralized versions work better than centralized they end up harder to attack with only trusting the central server(s) winmx has a trust everyone mentality, which as we seen is very insecure.

Moving forward need to design a trust no-one or partially trust this one etc.

But as I said without new protocol none of this would be a mentality and we would be back to trust everyone.

[hollow87]

Remove accidental double post

[Bluehaze]

"The Sybil attack in computer security is an attack wherein a reputation system is subverted by forging identities in peer-to-peer networks. It is named after the subject of the book Sybil, a case study of a woman diagnosed with dissociative identity disorder." from wikipedia

It makes sense hoilow. Forging identities is so easy and the disruption so great because the attackers have great familiarity with the existing protocol. Completely new protocol ought to set the attackers back for awhile.

I hope we will think in terms of the possible, the doable.

The best to all of  you!

[hollow87]

Not just a new protocol, it would have to be designed to help mitigate the Sybil attack.  That's why there are so many possible attacks against a decentralized network it's a matter of trust / security vs anonymity.  The more secure the network is the less anonymous it is and vice versa. Have to find a balance and figure out what your willing to give up for something else.

EDIT: phone auto corrected RSA  to RCA in my previous post

[GhostShip]

This much seems clear at this stage Hollow ,Pri and others who hide out of the way but are known to the community want to ditch all of the WPN protocol for something not as yet invented or functional in theory or practice but certainly it will be on "github"carrying the REN badge, this topic however isn't about a REN network client so if you really have nothing to add why are you so disruptive and negative about those trying to move this community ahead without making folks sign up to anyones central server or rules.

i believe in a decentralised network approach and no amount of time wasting from time wasters will change that view neither will personal attacks aimed at me achieve anything because frankly if you have nothing to say that's in any way balanced ,fair or informative I most likely wont be reading it bar the first few mantra words of " we don't like Ghostship", get over it and yourselves, this topic isn't about me baby sitting either of you its about a way ahead for this community as it is no one seems able to discuss the header with me because they seem to feel all of the current header fields are no longer there bar the additional ones I have suggested, what sort of foolishness is that ?

Perhaps the attacker has a magic wand that knows everyones client to client key pair as you seem to believe but i however don't , perhaps he is going to pre compute every possible search or room request before its sent and thus know the network id on each packet but of course we know that's not the case either in fact what I see here is just time wasting nonsense from those who have enjoyed a small measure of benefit from the attacks and strangely have had post attack relationships with the original attacker Michael Jones, Pri and Hollow are simply here to push their own weak agenda that's mainly hot air from what I can see, you guys have had 4 years to come up with something the same as the team here have, lets not brush that over,  is this REN idea all you can come up with in that time ?

[Pri]

I think some of the mitigation techniques we could use would be first off all requests like channel lists, would require a handshake. That would stop the IP spoofing right off the bat. Then second to that we would add in flood controls so the same IP's can't keep requesting the same thing over and over while receiving replies from the network.

Then the searching system, at the moment a bad primary can be built to meddle with requests and to send out forged requests. I think probably the only way to fix this would be to add in a hashing system to requests as they leave clients which are computationally heavy to create and decrypt. The hashing system itself would also need its difficulty to scale as the years go by and processing power becomes higher. We're not talking several minutes to perform a single search just maybe 2-5 seconds on modern hardware. We could increase memory requirements and serial math operations to make it not work quickly on GPU's and have the strength automatically increase by year, we could also have clients not respond to highly hashed requests if the strength doesn't match the year, this would stop resource depletion attacks by the attacker sending hugely hashed searches to be decrypted.

This is a similar method used on some other decentralised systems and I think it could work well for us.

This much seems clear at this stage Hollow ,Pri and others who hide out of the way but are known to the community want to ditch all of the WPN protocol for something not as yet invented or functional in theory or practice but certainly it will be on "github"carrying the REN badge, this topic however isn't about a REN network client so if you really have nothing to add why are you so disruptive and negative about those trying to move this community ahead without making folks sign up to anyones central server or rules.

i believe in a decentralised network approach and no amount of time wasting from time wasters will change that view neither will personal attacks aimed at me achieve anything because frankly if you have nothing to say that's in any way balanced ,fair or informative I most likely wont be reading it bar the first few mantra words of " we don't like Ghostship", get over it and yourselves, this topic isn't about me baby sitting either of you its about a way ahead for this community as it is no one seems able to discuss the header with me because they seem to feel all of the current header fields are no longer there bar the additional ones I have suggested, what sort of foolishness is that ?

Perhaps the attacker has a magic wand that knows everyones client to client key pair as you seem to believe but i however don't , perhaps he is going to pre compute every possible search or room request before its sent and thus know the network id on each packet but of course we know that's not the case either in fact what I see here is just time wasting nonsense from those who have enjoyed a small measure of benefit from the attacks and strangely have had post attack relationships with the original attacker Michael Jones, Pri and Hollow are simply here to push their own weak agenda that's mainly hot air from what I can see, you guys have had 4 years to come up with something the same as the team here have, lets not brush that over,  is this REN idea all you can come up with in that time ?

So childish, get back on topic.

[GhostShip]

* GhostShip pays attention 

[hollow87]

Ghostship if your going to be so hostile to me when I'm trying to help and everyone else then screw it.

Don't try and start a discussion on getting the community involved when you clearly just want to do personal attacks questioning the community's agenda.

All I was trying to do was bring up valid points its a matter of security vs anonymity finding the balance.

You don't want a new protocol then its going to suffer just like the old.

Security through obscurity doesn't work. which is how WinMX is right now.  Your trying to base your "fixes" around the same.  What is preventing the attacker from using the same "UTC timestamp diffie-hellman hash" (again diffie-hellman is a key exchange not a hash) to carry out the same attacks.

Diffie-hellman key exchange is based on the idea of large random prime numbers  RSA asymmetric encryption based off their concept (except uses much larger numbers) 2048-bit and 4096-bit for RSA are common

I said nothing about making it centralized your just putting words in my mouth in a personal attack against me.  I brought up the fact that these attacks have to be dealt with and is a core problem in decentralized networks.  There are solutions which I gave an example of

Want security? Get a new protocol, make it a bit more centralized. or harder to get onto the network for a client, malicious or not (by harder I mean computationally harder.  This is a essentially a Sybil attack on the network only a few ways to deal with that.

That's why more centralized versions work better than centralized they end up harder to attack with only trusting the central server(s) winmx has a trust everyone mentality, which as we seen is very insecure.

Moving forward need to design a trust no-one or partially trust this one etc.

But as I said without new protocol none of this would be a mentality and we would be back to trust everyone.

or harder to get onto the network for a client, malicious or not
Moving forward need to design a trust no-one

That is how to make it harder for a single client to get a proper identity on a decentralized network
See how I had both solutions for a centralized AND a decentralized

Now if you wish to continue this discussion in a civil way I will if not I have better things to do than waste my time tolerating personal attacks when I'm trying to help the community.

[GhostShip]

I agree I have said a lot and maybe annoyed a few of you but heres the deal I wont post as long as you guys continue the brainstorming unless you ask me to, what better deal can I offer, I asked for input and as long as its for the benefit of the community its the decent thing to listen to it.

[hollow87]

Still want your input
You say you don't want a centralized system but as it offers the best security why not use the centralized system we already have

Cache Servers

Put the burden of verifying trust on the cache servers themselves, primary's will look to the cache server to see if so and so can be trusted.
The cache servers can already know each other through DNS so a mini trust all p2p can be made between them.

Based on the rest of the community's input on this further expansion on exact details can be made

[GhostShip]

The reason for not centralising anything directly is simply the premise of falling foul of the napster/grokster legal minefield, atm most of us come here for the chat rooms etc and some still swap files, if we get involved in anyway directly with clients bar sending them off to do their own thing we could see a court order being issued as being "in charge" of the network or have a controlling method regarding what folks do on the network, this is an area of the law that has to be looked at carefully so we are always compliant with its terms, as long as we don't encourage folks to swap copyrighted material nor get involved in such we are all good to go but changes to this safe harbour model might not be so easy to achieve.

[Pri]

What if we used the Tor network to use hidden services for it? There are libraries available to include Tor connectivity into the client and then we could make a new type of peer cache which operates behind hidden services, these can't be taken down and don't exit the tor network at any time.

That would provide anonymity and the ability to put many more peer caches. Of course I'm talking about under a future system where the peer caches would take on a few more roles as a central authority.

[GhostShip]

Its a good idea but I cant officially comment on it as far as wmw is concerned, personally I think it might be useful for a p2p network but its that centralisation and reliance on a web server that to me seems a fat target for the Cartel to make false claims about.

You guys know a lot about DHT, what about looking at how we can use that to share information around the network without actually needing any third party support to enable or maintain it ?

[hollow87]

Yes the cache servers still would only send them on their way after they do a computational verification. NO transfers of files NO file listing or anything like that would be sent to the cache server only a heavier computational overhead of having a supernode connect to another supernode

For example an attacker can use the tcp's secondary connection to get supernodes to prevent that the handshake for a supernode to connect to another supernode must go through the cache server server all it would contain is a signing key, ip and port of x supernode or some sort of lookup table for that signing key and node cause right now a malicious supernode can just fake it way onto the network without the caches.   

And yes DHT still has issues of sybil attack that is what we are trying to prevent in first place got to have a chain of trust or heavy computational overhead to get an id on a network to mitigate sybil attack.

How to get the heavey computational overhead is the hard part.  One idea is to go up the chain to the root nodes. aka cache server that's what I'm trying to get to, but the way winmx is designed it doesn't follow a binary tree system. so trying to find a solution that doesn't totally change winmx while still getting the security.

[hollow87]

Idea is winmx is an unstructured p2p atm

Turning it into a semi structured one would allow us to mitigate a sybil attack with the ideas in this paper along with a few of our own
http://www.cse.psu.edu/~tfl12/paper/Sybil.pdf

And idea of unstructured vs structured p2p
https://www.usenix.org/legacy/event/usenix07/tech/full_papers/vishnumurthy/vishnumurthy.pdf

Edit: And the idea of a hidden tor service is it exists on the tor network where you have to be on the tor network to access it it is given an ID by the tor network to connect to.
Not a regular ip:port centralized thing.  It's kinda the same as the cache servers atm except their ip's and ports would not be known to regular clients only their tor id the .onion address