Slashdot Mirror
Distributed.net Cracking Scheme Halted
Colin Guillas writes "As we know, a single user posing as using a Russian supercomputer has been cracking distributed.net keys in the gigakeys range... but it turns out to be a hoax, as stated by nugget himself.
Also, there are clues to the identity of this cracker, as written by Maxxim Kochegarov at this site . "
One of the letters on d.net expressed concern that the way the database is set up, there is no way to determine which keys were faked by this person. My question is: Aren't the keys being checked in a sequental fashion? Couldn't we backup the counter a couple of days (or however long this person has been doing this) and simply repeat the last few days of work to be sure we don't miss the winning keys? Losing a few days isn't really going to hurt a project that has been running for almost 2 years now, and it will do wonders to dispel the worries people have that all of their work may be for nothing.
I read the internet for the articles.
Why the fuck can't you lame-ass script kiddies and l33t coders just LEAVE THEM ALONE. Why in God's name do you feel you must insist on forcing everybody to be totally secure and have their networks and systems completely impervious to all the lame crap you can throw at them?
And don't even THINK about calling yourselves "white hat" hackers here. The white-hats would try to find vulnerabilities and in quiet confidentiality contact the vulnerable with information on what they can do to fix the problems. Contrast that with the pests you moron packet kiddies consistently make of yourselves. You're not l33t or k-rad, you're fuckin' gimps. Knock it off.
D.net is doing COOL STUFF. You should be HELPING THEM reach their end goals, not pulling stupid shit like breaking their protocols and hacking up clients to "prove" to them that they're not totally secure.
Sure, releasing it open-source will help make the client more secure. It will also expose vulnerabilities (a necessary part of that process) and will attract more l33t hax0rZ and lame-ass packet kiddies to the sport of breaking into D.net. Why do you even need to do this to begin with? So it's theoretically possible to thwart their security measures and cause trouble. So why do it?
Whenever somebody pulls crap like this they always say, "I was doing it to show you you are vulnerable in this respect." Who the fuck cares? JUST LEAVE THEM ALONE AND LET US ALL WORK AS QUICKLY AND EFFICIENTLY AS WE CAN.
Time is the enemy here. By continuing to pull this shit and "force" them to keep adding all these countermeasures against your lamity, all you're doing is HURTING the effort. You may think you're helping by forcing them to keep it secure, but you aren't.
If you idiots would just fucking GROW UP and find something useful to do with this vast warehouse of knowledge you think you have, the world would be a much more efficient place.
It's an interesting idea but I don't think it'd work. Suppose I run a semi-fake client. It processes keys as normal but also churns out fake key responses. In that case the client would report a successful crack for those puzzles while still swamping distributed.net in fake solutions.
Before the speculation and misinformation get too far out of hand, I'd like to respond to the biggest issues I see raised in the threads here.
1. We *can* detect if a client has or has not performed the work it claimed
to perform. Right now we have the ability to pass a known positive key to
a client, and we detect very quickly if a client returns a negative result
for a known-positive block. Granted, this is not foolproof but it raises the
skill required to hack a client much past the insertion of a simple JMP at
the start of the keytesting code. Both czcrack and the russian cracked clients
failed this test and were spotted in this way. It is not simply their
unbelievable keyrates that allows us to tell that something is wrong.
2. The anonymous coward who accuses us of having ego problems is correct that
calculating and md5 hash of the decrypted strings is another way of being able
to verify that the work was performed as claimed by a client. I don't know
who he is, or when he claims to have submitted his code however. *shrug*
This concept is not implemented in the current clients, but it's likely to be
added soon. Hopefully the situation with the russian vandal will encourage
people to upgrade to the client supporting this feature even though their
keyrate will fall somewhat as a result. This addition is arguably quite
overdue.
3. No, we do not think that we are secure because the source is closed. I'd
point to http://www.distributed.net/source/ for the answer to the FAQ "Why is
distributed.net closed source?":
"Quite truthfully, releasing binary-only clients still does not completely
eliminate the possibility of sabotage, since it is relatively easy for any
knowledgeable person to disassemble or patch binaries. This is actually quite a
trivial task, so we urge you not to try. Indeed, security through obscurity is
actually not secure at all, and we do not claim it to be such."
More on this later, but I'd advise all the people crying for open source to
think through their proposal. This is an unfair demand to make unless you
have the solution to the client trust issue. Your argument is only compelling
if it contains the solution to how an opensource client can be trusted.
4. Full logs are kept showing who tested each block, when they tested it, what client version they used, and what CPU and OS were involved. While the stats database does not retain information at this level, the logfiles do and it is quite simple to "unflag" work performed by known spammer/vandal.
5. Finally, the difficult truth we face is that even if we do implement
every last suggestion. If we were to completely swing the pendulum the other
direction and check every block twice, calculate an md5 hash of the decrypted
texts, and implement every other suggested countermeasure to broken clients
it still would not be sufficient to allow the client to be released as
open source. It is false logic to equate work verification with results
verification. Even if you prove conclusively that the client performed
the work, you still cannot trust the answer that the client provides.
A client could conceivably perform all the work, and provide the necessary
hashes and checksums to prove that, yet always return a negative answer
even if the correct key is found.
It doesn't work.
Source code or not, you'll get cracked, you can see it now, and you will later.
A good example of security through obscurity is ICQ,
and a good example of secure open source product is PGP (and GnuPG).
Your claim is that people will work, but when the key is found they will report it as a false one,
claiming the reward.
It is possible, I agree, but it is also possible now.
but - Making an opensource program will allow you to find problems.
Assume the new client will send in a false signal as a mistake if it was true, what would you do about that it nobody find it in the code?
What if someone finds quicker algorithms?
think about it.
Last thing, you contridict yourself.
If you can autodetect cracks,
how come you don't know if all the other people in the russian dude's team are fakes as well?
(you cut them off, appearantly)
Why did you have to talk to that guy (which was already detected to be a cracker)?
---
The day Microsoft makes something that doesn't suck,
---
I'm going to live forever, or die in the attempt.
You can't know who is making false keys.
;-)
:-(
That russian dude was both smart and stupid.
Technicly, he was smart enough to hack the client. Bravo to him on that.
But he was stupid enough to make gigakeys.
(assuming he did not want to get caught, just bring his team the honor of a high keyrate)
The problem is that many people could have cheated without raising suspicion.
Instead of doing 200 packets per day, they now do 5000, which is quite good, but not good enough to be noticed.
They might have reversed engineered the client,
that it will act as several users, each with a thousand or so keys.
So the cracker pretends to be 200 users, each with ~1000/day and joins them in a team,
he has a team of 200kpackets/day, and that's a lot.
AnandTech can be just that too.
(sorry if they are not this is an example)
One sudden say they passed slashdot with one user who is the daily number 1.
Is he legit? How come it was so sudden?
How did he dare passing team slashdot?
The problem is that "it's not cheating unless you get caught".
And who knows the actual "winner" key could have been cheated and we're working for nothing.
A solution is to request the client to do another task on the packet (or a part of it),
that is very fast in one way (nanoseconds) and a bit slower on the other (few seconds), like hashing.
It will only slow the actual keybreaking by 1%,
but cheaters will need to solve the hashing challange as well.
(though if they crack the client well, they can "speed up" by about 100 times)
---
The day Microsoft makes something that doesn't suck,
---
I'm going to live forever, or die in the attempt.
Why not release the source in encrypted form. Then we can start another distributed computing project to decrypt it ;)
A big point of the RSA contests is to show just how crackable weak encryption is, to push for legalization of strong encryption. There are several groups who wish to argue otherwise. Since I am an American, one of those groups is on my payroll, as it were (not that I agree with them).
While I doubt that is currently happening, there are entities with opportunity, motive, and weapon to do this sort of thing to protect the encryption status quo.
--The basis of all love is respect
You have some valid points here... In the gaming world the rule is Never, ever trust the client!
;)
D.net has made a game out of this with the scoring and has thereby introduced a new set of incentives that are inconsistent with the stated goal.
I have to agree with your point about the stupidity of "security through obscurity". Your point about them being able to spot bogus blocks is almost certainly true. Unless they have a very lightweight crosscheck algorithm that is insignificant relative to the workload, then they are at best exagerating. The idea that there is a certain shortcut crosscheck, as opposed to a sampling approach of course, suggests a major cryptographic weakness itself.
For a "flamebait" comment, you have a hell of an argument.
But the question still remains: What is the solution you recommended? Post it here for a little friendly peer review.
Geeky modern art T-shirts
I missed that your suggestion *was* to have them do a sampling based on the result. Sorry. Of course, the overhead here rises with the confidence level they seek... A solution, but a costly one. Have you done the math on just how big a performance hit this would entail?
Geeky modern art T-shirts
It is d.net's official position that security through obscurity doesn't work to prevent this type of crack--sending back blocks without checking them--and I think they do actually believe that, especially since it's now been done several times. It's worth noting that they do have a scheme to check this sort of thing--i.e. sending a known positive to the suspected client and seeing if it returns a negative or not.
.1% but would deter anyone from not checking their blocks, IMO.
/.
A couple things to note about this scheme:
1) Apparently at this point the key word here is suspected: they only test someone with suspicious activity (say, returning 800,000 blocks a day on a chip which will not be built for several years). Of course, other than the drop in rate, there's no reason I can see why they don't check on everyone every once in a while.
2) Many people have suggested a checking scheme based on hashing negative results--essentially sending some portion of the blocks out to two people and seeing if they get the "same" negative result. Nugget says that he realizes this is a better idea and will incorporate it into the next client.
Ok, fine. But I think the reason they haven't incorporated a hash check yet is not, as has been suggested, because they can't stand to lose any speed (people around here have been throwing around figures like 20%). If I understand all the issues correctly (a big if, but still), they only need to double check every, say, 1000 blocks or so in order to get a handle on most any cheating. After all, even someone who bothered running a "covert" hacked client--one that would report blocks fast, but not so fast as to arouse suspicion--would still report at least 1000 blocks a day. Double checking 1/1000 blocks would only slow things down by
No, what I think d.net is more worried about is someone who cracks the client--or, as is, in their thinking (and I have to say mine too), more likely, modifies an open source client--to send out a negative when it gets the winning key, and notify the computer user instead. Then they just report the answer to RC5 themselves, and get $10,000 instead of $2000. d.net loses $2000--$2000 which, I would hope we all agree, they deserve--and some worthy charity loses $6000.
First off, the hash checking scheme wouldn't catch this, although the known positive scheme would (or might, depending on what exactly it means for them to send a known positive block, and how this differs from a winning block).
And second off, I hope I'm wrong, but I have this feeling that such an abuse would be much more widespread with an open source client.
As for the other drawbacks of open sourcing, there's the issue of reliability--how do you know someone's altered client isn't giving off incorrect results because they didn't understand the changes they made? Without checking of both kinds--known positive and hash--we'd never know. Hence open source means they have to double check results way more often than is necessary now.
There's the issue of rival servers to d.net popping up, taking d.net's share of the prize and making coordinating unchecked blocks more complicated.
And finally there's the best reason not to open source: it works fine already. Somebody here suggested that an open source client might find a better checking algorithm. Again, I'm not expert on RC5, but from my understanding of it, there is no better algorithm. After all, the specs to RC5 encryption are public domain, and have always been so. If a better algorithm does come along (very unlikely, but possible), it'll come from a mathmetician, not some random guy on
Turn off personal statistics forever. That'll solve the ego boosting problem.
It won't solve the cracking the program for fun problem though...