Distributed.Net-Why Isn't ALL Of The Source Open?

nullset writes "I was browsing on distributed.net's site, and noticed this article that talks about why the client isn't fully open source. Most of the source however, is available. The article says that they haven't opened the entire source because of the worries of people faking packets. They even mention that this really ISN'T secure, but they're looking for a better solution. What would you do in this case?" Once again, it's the ever present case of Security Through Obscurity. The old argument aside, are there cases where it works well enough? Is Distributed.Net secure enough in their position where they can keep things closed, or would opening the rest of the code help in any way?

Comments

IMHO

[PooF]

The problem is similar to quake being open sourced. There were cheaters before but more afterwards. DNet would suffer a lot of abuse if the networking code was open sourced, but they probally do face a lot of abuse right now anyway.

As they mention on the page; it is easy to fake packets and they know that, but how do you build a system that can verify information sent without checking over everything again. If people had the code to generate packets and people abused it; it could ruin years of many people's CPU cycles.

However, I'm sure if there was a secure way to deal with the problem, that could be open sourced they'd do it in a flash.

Aaron "PooF" Matthews

There is a solution...

[Anonymous Coward]

There is a quite simple solution to this problem: Have the client checksum the result of all the decryptions. If the checksum is bad then you know that the response is faked. You don't have to actually redo all the work; if the client is faking packets then they're all going to be wrong, so you only have to check one. Doing random checks on maybe 1 in 100 should be sufficient to catch the cheaters.

As for why distributed.net is not doing this, I have no idea. It's been discussed many times.

Its a difficult problem to tackle

[Zaffle]

Esentialy I can create DNet packets that say that I have tried these key-blocks, and they don't work, and the result was 0x12345678 The problem is I can lie, and say I've done them when I haven't. There are a two main ways to combat this.

Redundancy - Give each key-block to a number of clients, and if one says the result was a different number than the others, then that one may be cheating. The problem is if a LOT of clients are cheating, you start running into higher ratios, and have difficulty determining what the right answer is.

Block Processing analysis. If someone is going through 10 billion keys a second, they are either the NSA, or are cheating. This is the primary way to detect cheaters, however its not always accurate, and as people get smarter, they'll start submitting their keys slower, and from different IP addresses, and use different email addresses.

Another way would be to make the result the client sends computationaly difficult to find, but easy to verify. (Hmm, sounds like encryption to me). I'm not totaly sure what result the client sends back, but if something like this was possible, then the server could always verify if the key indeed has been checked.

If i recall, the DNet system involves giving each client a block of keys, some cipher text, and some clear text, and telling the client to try the key and see if it gets clear text.

---