Megor writes "Well it was bound to happen, people are cheating on Seti@home to inflate their work unit statistics, and the people who administer Seti are ignoring the complaints. ZDNET has an article explaining how they are cheating."
Wasn't cheating to be "impossible" ?
by
holle2
·
· Score: 5, Interesting
I thought the move to close the source of SETI@home back in the old days was meant to stop the cheating ? Could it be that the protocol should be redesigned to contain, say digital signaures embedded into the binary (well not really a save place for that anyway..)
Re:Wasn't cheating to be "impossible" ?
by
ebbomega
·
· Score: 4, Interesting
If anything, closing source opens you up to "cheats" because every time that an exploit/cheat comes up, you don't have OpenSource-support to fix it sooner rather than later.
Closing source isn't like sealing a tank. It's more like building a beaver-dam.
-- Karma: Non-Heinous
Re:Wasn't cheating to be "impossible" ?
by
anshil
·
· Score: 5, Interesting
Closing the source does not help a bit. After all you give a binary to your "foe", thats enough. Look in example to Ultima Online, they encrypt the stream already in 10 layers or so, with constant changing keys, algorithmns and so on. But it is still beeing hacked, simple as that, you've a binary of the client, you can view the algorithmn on assembler basis, thats enough "source" code to hack anything assuming enough motivation and time.
Look at all the companies trying to hinder people copying with copy protection CD's, tongels and all that. Does it help? No it's all just a new challange for the hacker folk.
--
--
Karma 50, and all I got was this lousy T-Shirt.
Re:Wasn't cheating to be "impossible" ?
by
bogado
·
· Score: 4, Interesting
In fact this is a hard problem to solve, since you have to trust the computations made on the client side. Every security protocol must not trust the client! The solution in this case would be punishing the guilt.
My opinion is that each login should have a key, this key would sign all the packects received from this particular login. Now for every X packects received from any client, you resend one of them to another user, of there is a mismatch in the packet You then redo the calculation with your trusted code, and checkout witch is cheating and then ban this user.
Since cheating is for achieving higher pontuation, no one would like to be banned, since this would mean that one would have to restart their statisics. Groups could also be punished if one of their members is cheating making them also responsible for their components. This would help to police the network.
The key I proposed is for guaranty that a good user could not be sobotaged by other people sending packets in his name. Also one couls adopt a policy of sending more test packects to user with higher, more suspicious, rates of delivery.
--
[]'s Victor Bogado da Silva Lins
^[:wq
Re:Wasn't cheating to be "impossible" ?
by
ComputerSlicer23
·
· Score: 4, Interesting
Okay, your right, I'd just gotten done reading another link from the posts, there is one from distributed.net that discussed all this, and actually was much more interesting then the original link. They talk about using a public key to sign data. Not that differs per individual, but even that is easy to abuse.
It's *MUCH* faster to generate bogus data, then it is to check it. I could generate thousands of work units in an hour. If I was a bad person, I'd sign up for a new name for every single work unit. Or only every 10-20 units. If I can turn them in faster then you can test and reject them, I'm winning. The DOS will actual work. Remember, they can't possibly afford to check 1 out of every million blocks of the data they are sending out, otherwise they wouldn't be doing it as a distributed computing project. I can DOS them if they attempt to run a "trusted" version of the binary locally. I'd whoop them really bad and generating bogus data. The attacker isn't going to play nice and put all their work units in under a single name if they are attempting to subvert the process.
I'm speaking from the perspective of an attacker who want's to subvert the process not rack up a big WU total. If I really wanted to rack up a huge work unit total, I'd take all my units under one name, and then submit them via 10 signed keys when they are done, so they all look like proper work units. Then they never check them locally, because they got verified by 10 different people as the same. How handy... If they have a set of "trusted" users that have to verify all the blocks, then all they should have the trusted people run the binaries, because everybody else will be throttled by the rate of the trusted ones.
In the end, they really can't check anything locally or only by trusted users, because locally and trusted users doesn't scale, that's why it's a distributed process. All the attacker has to do, is overrun the computing resources of the checker, and they win. It's not hard at all to pump to much data at them, because I don't need to do any real work to generate them, they have to do loads of work to check them. (Spoken like a man who use to grade tests.)...
Thanks,
Kirby
Our experiences from running the rc5-56 challenge
by
jukal
·
· Score: 5, Interesting
run at cyberian.org some 4 years ago was that people will do anything to get their team/name listed in the first page of the statistics. Some of the people were even arrested by police for hacking into machines to make them crunch rc5 for their name. And it seems this trend is only getting worse. This is kind of sad, because it is not very good for the reputation of such efforts.
Re:SETI Checking?
by
phragle
·
· Score: 4, Interesting
from the seti FAQ
http://setifaq.org/faq.txt
2.4 I heard I was getting the same work unit as everyone else. Is the
program wasting my time?
Nope, because the only time you're giving it is time your
computer would have wasted anyway. Yes, early in the program
there were times when the same work units went out over and over,
due to overloading of the SETI@home servers that were supposed to
be making new ones to send out. (They didn't expect half a
million people to sign up, and they don't have enough staff or
computing power to keep up with it.)
And since then, the same work units are still sent out to several
people, for various reasons (for instance, more than half the
people who signed up have never returned their work units, and
probably dropped out) But new work units are being sent out too,
so just leave your SETI@home program working and it'll take care
of the details.
Note:
If workunits are sent out multiple times, they can be
doublechecked by SETI@home.
I'm researching seti for a final year comp sci project, and I've just handed in a draft about how its been secure, but how my distributed foobar will be open, and therfore more secure.
(dunno how to make it secure yet though)
Cheating is a big thing, as you can sell your work units on ebay!
500 units @ 25 euros and http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&it em=2064169353 and http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem& it em=2064990327
What happens if there really was something found, but due to the high rate of contamination that it was thought to be too good to be true and discarded. Consequences really need to be thought out before you start wrecking the hardwork of scientists and academics who are only doing a service for everyone's benefit.
Not that I disagree with you overall, but if they thought they found something but the results were contaminated, they would just reprocess them. Now, what we should worry about is something being overlooked...
-- Robots are everywhere, and they eat old people's medicine for fuel.
Re:SETI Checking?
by
Coplan
·
· Score: 5, Interesting
Simple solution...
Seti should track what it hands out (and I'm sure it probably does). In fact, it should probably track to who it sends it (again, it probably does).
If Seti sends out 30 WUs (abroad), it should know that if it gets 200 back, a flag should be sent up. If seti sends a WU to Bob, but not to Gregg, and Gregg sends THAT WU back, the one returned from Gregg should be voided.
This is not about preventing competition. Screw that...Seti shouldn't be concerned about this issue relative to that. Seti's concern should be plain and simple -- it should be protecting the integrity of the data.
'Nuff Said.
Slashdot Mirror
I thought the move to close the source of SETI@home back in the old days was meant to stop the cheating ? ..)
Could it be that the protocol should be redesigned to contain, say digital signaures embedded into the binary (well not really a save place for that anyway
run at cyberian.org some 4 years ago was that people will do anything to get their team/name listed in the first page of the statistics. Some of the people were even arrested by police for hacking into machines to make them crunch rc5 for their name. And it seems this trend is only getting worse. This is kind of sad, because it is not very good for the reputation of such efforts.
from the seti FAQ http://setifaq.org/faq.txt 2.4 I heard I was getting the same work unit as everyone else. Is the program wasting my time? Nope, because the only time you're giving it is time your computer would have wasted anyway. Yes, early in the program there were times when the same work units went out over and over, due to overloading of the SETI@home servers that were supposed to be making new ones to send out. (They didn't expect half a million people to sign up, and they don't have enough staff or computing power to keep up with it.) And since then, the same work units are still sent out to several people, for various reasons (for instance, more than half the people who signed up have never returned their work units, and probably dropped out) But new work units are being sent out too, so just leave your SETI@home program working and it'll take care of the details. Note: If workunits are sent out multiple times, they can be doublechecked by SETI@home.
I'm researching seti for a final year comp sci project, and I've just handed in a draft about how its been secure, but how my distributed foobar will be open, and therfore more secure.
t em=2064169353 and & it em=2064990327
(dunno how to make it secure yet though)
Cheating is a big thing, as you can sell your work units on ebay!
500 units @ 25 euros
and http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&i
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem
Not that I disagree with you overall, but if they thought they found something but the results were contaminated, they would just reprocess them. Now, what we should worry about is something being overlooked...
Robots are everywhere, and they eat old people's medicine for fuel.
Seti should track what it hands out (and I'm sure it probably does). In fact, it should probably track to who it sends it (again, it probably does).
If Seti sends out 30 WUs (abroad), it should know that if it gets 200 back, a flag should be sent up. If seti sends a WU to Bob, but not to Gregg, and Gregg sends THAT WU back, the one returned from Gregg should be voided.
This is not about preventing competition. Screw that...Seti shouldn't be concerned about this issue relative to that. Seti's concern should be plain and simple -- it should be protecting the integrity of the data. 'Nuff Said.