Distributed.net Cracking Scheme Halted 88
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 . "
Extremely silly (Score:1)
1. To get your name on top of the keyrate list. Of course, putting yourself on top is a great way to be singled-out, discovered and eliminated. If you're not going to be on top, why do it?
2. To sabotage distributed.net's operation. Why? Are you trying to find the key yourself? Better you should run the regular client, get a chance at the $1-2K prize!
3. Just to be an asshole. I suppose there are plenty of those running around; look at all the new virii and trojans.
Luckily, even with hundreds of hacked clients operating too slowly to be singled out, the spoofed blocks would be a small fraction of a percent of the total keyspace being processed; so the odds of distributed.net finding the correct key would still be >99%.
Now, what WOULD be devious is if the contest sponsor were to slip in a keyblock, supposedly generated randomly but giving null results for the actual solution. Distributed.net would then churn away in vain.
How to Stop Fake Clients (Score:1)
The difficult part may be creating the "puzzles" so that the spiked, known-solveable puzzles are not easily differentiable from the normal puzzles. The point is to just make a forging client more costly for a cracker that is worth it.
The cost for distributed.net would be a configurable, negligeable slice of the cracking time - I'd guess a number around one every half a million would be good.
Something to think about for next-generation clients. Would allow distributed.net to go open-source, too.
-Pimp Daddy Root
root (at) localhost
Backup over the faked keys? (Score:2)
Distributed.net == today's Usenet. (Score:1)
You can't be too paranoid about security now.
---
Spammed? Click here [sputum.com] for free slack on how to fight it!
Just leave the project ALONE (Score:2)
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.
Re:Come on. (Score:1)
Re:RTFP (Score:1)
Till they throw out this stupid notion of security through obsecurity, and this idotic idea that their current methods scale I'll be running my key faker.
was just there to make the post buzzword complient?
Re:How to Stop Fake Clients (Score:2)
Re:Processor ID/MAC address checks (Score:1)
Not to mention than with some cards, you can alter your mac address.
- - - - - - - - - - - - - - - - - - - - - -
Response to the points raised so far (Score:5)
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.
There is another way... maby. (Score:1)
I.e not much point in hacking the client anymore.
Now i'd just like to say that these russians did actually increase d.ned security now didin't they?
Russian Team (Score:1)
is recommended reading. I found it interesting and
informative. On top of that, he uses better
english than most goofs posting here
-kabloie
Re:Read my below post.. (Score:1)
Thanks,
dB!
decibel@distributed.net
Re:Backup over the faked keys? (Score:1)
Re:How to Stop Fake Clients - double-checking (Score:1)
Am I missing something? Comments?
Re:Security through obscurity (Score:1)
Why don't you people get your facts straight before you spew this drivel?
For the record, they HAVE "thought about it".
The parts of the code that crack blocks *ARE* Open; you can download them from the distributed.net web site, using the URL given in the message TO WHICH YOU WERE REPLYING.
The closed parts are mostly the key exchange bits, and the disk buffer bits.
Nobody at distributed thinks this will prevent abuse; it simply cuts down on the NUMBER of abused blocks.
If the entire client was Open, any jackass with a C compiler and a copy of "Teach Yourself C in 53 nanoseconds" could intercept the good key or churn out crapola.
With parts of the client closed, only the folks who care to take the time to disassemble and reverse engineer can abuse the system. It's not all that hard, but a much lower number of people will bother to do it.
With the actual RC5 code Open, which it is, the off chance that somebody will find a faster way is accounted for.
Get this through your head; THERE ARE SITUATIONS WHERE CLOSED SOURCE MAKES SENSE. Not many, but they exist. Read Eric Raymond's articles some time for examples.
Re:Problem is...Anandtech does what? (Score:1)
-----
Won't work (Score:1)
Re:h4x0r (Score:1)
Re:Problem is... (Score:1)
Let's assume the winning key is: 5577F332 (could it be? chances are 2^(-64) that it is).
Cheating the winner key would be saying that 5577F332 is a bad key.
This is the worst thing that can happed, it would force us to start the whole search from key 0.
(many months of work for waste)
Cheating as the winner key would be saying that key 4567AB67 (not the winner) is the winner.
This is a very small problem.
It will only make the distributed.net computer recheck if it is the winner.
(no more than a few cycles lost)
---
The day Microsoft makes something that doesn't suck,
Security through obscurity (Score:2)
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,
Problem is... (Score:3)
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,
h4x0r (Score:1)
(b/c it would sound kind of silly for CNN et. al. to say, "The FBI's servers were hacksored again today")
Re:Problem is... (Score:1)
Aye, you can bet if anyone did have the winning key, they wouldn't bother toying with d.net. They'd call up RSA in a heartbeat, and get the money and fame
Re:Moderators are faschists (Score:1)
Re:Backup over the faked keys? (Score:1)
As far as I know, it is possible to remove all keys tested by a person from the database. this is supported by this post [slashdot.org] by nugget. In it he states:
"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"
Re: Rechecking keys for verification (Score:1)
So, 1-2% more cpu for security vs 100-n00% more for failure.
Security would be fairly simple. Simply require a CRC of the results of each block. CRCs are fast, and wouldn't slow the clients much. Then, d.net would redistribute a certain percentage of keys at random and check that both users returned the same CRC. If they didn't match, then d.net itself would crack that block and kick out the user whose CRC theirs didn't match.
Something like this (basing a CRC on the results of the proper cracking, like CRCing the first 4 bytes of the resulting 'plaintext') would force people to actually try the keys, and since there's no faster way to crack than by running the client (that we've yet discovered, or the client would be using it) you guarantee that people are actually doing the work.
And this method wouldn't depend at all on security by obscurity, and would allow them to open-source the client, if they desired.
Re:How to Stop Fake Clients - double-checking (Score:1)
Compared to RC5 cracking, CRCing is relatively free. So simply have the client CRC the last four bytes of the message they decrypt for all the keys in the block.
By requiring a CRC for all the tried-decryptions keeps someone from only doing every fifth key (or whatever) and by requiring the CRC to be of the *last* bytes in the string, you force them to decrypt the whole thing (or at least as far as the regular client does to report a failure).
Then yes, record the CRCs you get on every hundredth packet or so, and send it out to someone else to check. When the results come back, if they don't match, one of the people is a cheater.
This sort of double-checking should have been in there from the beginning, to guard against bugs, if not cheaters. Only makes good sense to spend a little time making sure you're not wasting a lot.
Re:Response to the points raised so far (Score:1)
I believe that the test is done by encrypting known plaintext, which is always the same, with a secret key, so the plaintext and cyphertext would be wired into the client, or at least sent infrequently.
The only way to include a known correct key would be to include a new plaintext of cyphertext with the keys so that one of them would properly decrypt it, but a 'smart' cracked client could simply watch for the plaintext or cyphertext to change and then actually start doing the work properly...
Re:Why they don't open source it (Score:1)
The problem is false-negatives. I hadn't even thought of the economic benefits involved in this, just from the cracker angle of people wanting to screw up the project.
The only way I can see to solve this is cryptographically... bear with me.
The point of the contest is to find the *1* key that will turn the cyphertext into the plaintext. Both are (obviously) known to the client and, most likely, hardcoded in. (I mean, the cyphertext changes once per contest, and the plaintext doesn't change at all, right?)
So, it's impossible to send a fake winning key to a client because you'd have to send a new cyphertext as well. Even if the cyphertext is sent with every block, it would be the same for the other 999 of 1000 blocks, so the client just watches for the cyphertext to change and then calculates properly for a while to catch the fake winning key and then continues cheating.
The other way to cheat is to crack properly, and thus pass all tests, but halt when the winning key is found, without telling d.net. Then just silently return a fake CRC and hope it doesn't get checked, or stop cracking, turn in the answer, and try to say that you were running a personal cracking attempts, which though unlikely to succeed, has to be allowable...
So, it's impossible to send fake winning keys without having already solved the contest, and cheaters don't have to report a win...
So, what to do? Well, I didn't invent RC5 so I don't know how something like this would work, but...
Is there a way to hash the cyphertext AND the plaintext in such a way that the same key will decrypt then as worked on the unhashed pair?
This would allow d.net to send a plaintext and cyphertext pair to each client that the client would be unable to determine as the real cypertext/plaintext pair. The client would still determine for itself if the key was correct or not, but it wouldn't know if it found the real k/c/p, or a dummy. This would make them return all positive results, because most (if not all) positives that any client generated would be tests, not the real thing...
But, just eliminating unchecked negatives (via some dual testing) drop the number of cracked significantly. I mean, how many crackers are going to bother running the rc5 client for months, just for a one in a few million chance of being able to screw it up? I think most crackers would want slightly more gratification. Especially since it's not like they could even take credit for it later if it was (by some huge fluke) them who missed the key the first time around. There's no payoff at all, either positive or negative attention.
On the subject of people finding better ways to crack... It's the algorithm, as interpretted on the computer, that would be enhanced, not the actual algorithm. It's always possible to tweak something with some hand-coded assembly.
Also, to quickly answer a thread about crypto checking the client... Neat idea, but it doesn't work. It's just more layers to be hacked through, and if you make it that interesting, you'll attract more hackers looking for a challenge along with the crackers. The only way crypto can be used to verify the client is if both end users (d.net and the person running the client) are cooperating to stop a hypothetical third party in the middle, and in this case, MD5 hashes of the client keep hacked clients from being substituted for the real thing.
Re:Processor ID/MAC address checks (Score:1)
First, as some people already said, that stuff is easy to fake. But more importantly: there are plenty of distributed clients which don't have MACs or Intel IDs.
What good will a MAC do if a computer doesn't have Ethernet? What if it has multiple Ethernets? What if the MAC has been reused? (I think vendors have done this, even though they're not supposed to...) What if you're IP Masquerading through just one MAC? What if the Ethernet isn't the connection used to connect to the net? (Hmmm... I'm still using modems, how about you?)
As for the Intel IDs, this would apply to a small portion of the clients. What if someone doesn't have a BigBrother make CPU? I don't have any which do...
All of these considerations apply to me. I run clients through my personal proxy. Only one is Intel. I also have Macs, and a K6-3 Linux box. I have clients which don't have a MAC address... So, none of this would work for me, nor would I want it to. I mean, really... until everybody has the same computer and network connection... :)
Solution to Open Source Dilemma (Score:2)
Not really (Score:1)
besides why would someone want to write a hacked client and then *not* get an insainly high score? I mean, what would be the point? There are only 3 reasons to hack/crack/h4x0r antention, money, or beacuse you belive your target is moraly wrong. Now I don't see how you would get money for hacking D.net, and I really doubt anyone would be moraly opposed to d.net (the NSA?) and how would slowly and silently cracking away at d.net get you attention?
_
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
China (Score:1)
did you know that there entire millitary budget is less than the *increase* in the US's budget? (While clintion is "cutting" funding, he's probably just "decreasing the increase")
I don't know if the US could win a strate war with china at this point, but i don't belive that China is in anyway better then us as far as Sciance/tech
damn, this is *really* offtopic...
_
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
Re:Not really (Score:1)
There is one additional motivation that some people have that you overlooked: the desire to cause damage for absolutely no reason. Some people simply take pleasure in destroying a legitamite project.
Re:Extremely silly (Score:2)
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.
Processor ID/MAC address checks (Score:1)
Since each individual machine would have a unique id, you can check if the same machine is returning unfeasible amounts of say 3000 blocks/processor/day.
Re:Dnet is afraid of the truth. (Score:1)
Exactly. I think that too many people are joining these distributed-computing projects, not to help out the cause, but to see their names up there on the big result board. It's all just a game to them, a big competition to see who has the most CPU power. And viewing it from that angle makes it "logical" to throw a spanner in the works and show the world how k-rad & l33t you are.
*sigh*
--
Open Source Terrorism? (Score:2)
Re:Nope, easier. (Score:1)
First, why post as an AC? This anonymous thing doesn't do much good for your credibility.
Second, you seem very pissed because DCTI didn't listen to you over a year ago. handle sticking name in credits, the must know everything I guess
Why this attitude? As suggested, write the white paper. Hang out in #distributed on EFnet, maybe submit your ideas again. You seem very interested in distributed computing/security, otherwise you wouldn't have taken the effort to rewrite that v1 client. If you really want to see DCTI to go forward, be more helpful and cooperative. Afterall, even DCTI is only human and it's possible your suggestion just slipped through.
Re:Problem is... (Score:1)
Re:Come on... and join the peer review process! (Score:2)
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.
Re:Come on... Doh! that was the suggestion... (Score:2)
Re:Hold on a minute (Score:1)
The
No, actually... (Score:1)
Re:Problem is... (Score:1)
Re:Problem is... (Score:1)
Reminds me of school... (Score:1)
Doesn't this remind you of the old school phrase "Don't let one person ruin it for you all" ? It's a shame that the phrase rings so true here. Thankfully, according to the finger, no harm has been done, but it just goes to show that at the end of the day there are always people out there to harm.
The user in question said that he did it to prove it could be done. Whilst this is the main point of the hacker ethic (as in the true meaning), why did he/she/it decide to actually use the thing ? He could have posted it to distributed net with a little explanation highlighting the weaknesses and thus helping them out no end, I'm sure... although perhaps I wrong...
Not really secure (Score:1)
The problem with this approach is that it can be defeated easily by keeping both the correct and the broken clients around. The broken client would be the one that actually runs, and the correct one would merely be used as data to compute the "secure" hash.
How to trust an Open-Source client (Score:1)
Re:Nope, easier. (Score:1)
Why they don't open source it (Score:2)
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
Statistical sampling (Score:1)
Its almost fully automatic, only requires wasting at most 5% of the processing time. and cheaters will eventually get automatically caught.
The other solution (Score:2)
It won't solve the cracking the program for fun problem though...
Re:Why they don't open source it (Score:1)
All the cores are available to anyone who wants them. There is nothing stoping anyone from building their own client and finding the solution themselves.
As for the comments of people "hijacking" the correct solution, go read the rules for the contest as per RSA. They are going to want full disclosure of how you got the correct answer. I'd like to see how someone would get a hijacked answer past RSA.
The hashing/crc ideas have been around for a long time. Yes, it would eat some processing time -- how much is open for debate. But someone would still have to go back and verify the results at some point. That's about the only way to make sure everything is on the up-and-up. (It also adds a little extra verification to make sure the actual core(s) are working correctly. It's happened before.)
For the record, I know of no one ever braking the RSA public key verification ("blessing") for any nettrek client. (In theory, it's not that difficult. And every line of that source code has been public for ever.)
Rule #1: There is no such thing as "secure."
Re:Shutup you dork! (Score:1)
I wasn't aware laws were being broken. It's mean-spirited but is it illegal?
Re:Backup over the faked keys? (Score:1)
Re:Dnet is afraid of the truth. (Score:1)
I think the people who run the fake clients have lost the sense of purpose behind this whole thing. It's to try and do something no one has ever done before, showing the government how encryption is something that can't be treated like nuclear technologies (I'm talking about the US government's ban on exporting high-level encryption software).
Just my $0.02 anyway...