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

Comments

Response to the points raised so far

[Nugget94M]

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.

Problem is...

[BiGGO]

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,