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