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

Re:IMHO

[Dwonis]

I think the QuakeWorld Forever project did something useful like this. It had a way of using an encrypted client authentication system.

Bascially, you generated a key, then you compiled the client with it and told the server to accept clients using that key. That way, the source was entirely open. Everyone could build secure clients, just not the same secure clients that the server would accept.

In this way, the distributed.net people could distribute a working, open-source client and server, without having to allow every hacked version of it to mess with their statistics.
--------
"I already have all the latest software."

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.

---

Two Possibilities

[The Famous Brett Wat]

The Problem

In the case of a distributed cracking effort, the client is given hunk of ciphertext and a block of keys to try on it. A malicious client can send back false negatives (well, 99.999% of them will be true negatives, but you know what I mean) to corrupt the search effort, or send back false positives which waste CPU time at the central server due to verification overhead.

Proposed solution 1: Bait

In addition to tracking which blocks have been checked, the server must also maintain a record of which host (by IP address or other provided data such as email address) checked which blocks. The server then occasionally provides the client with a known ciphertext and a block that contains the correct key. If the client provides a negative response, all blocks known to have been submitted by the client are marked as unchecked. If the server wishes the client to remain ignorant of being caught, it should continue to provide the client with blocks of ciphertext and keys, and discard the results.

The same technique can be used for false positives: systems that give false positives can be put in a blacklist and their results ignored. The server can continue to provide blocks and ignore the results in order to deceive the client.

Weaknesses in this solution include the fact that it is normally more convenient to have a fixed hunk of ciphertext. Cipher feedback modes may necessitate that the cracking attempt be started at the head of the ciphertext. Unless there is a range of ciphertexts to attack, it will be obvious to the client which hunks are bait, and which are real.

Proposed solution 2: The Chinese Lottery

Based on an idea found in Applied Cryptography. A cracking effort does not have to be centrally organised: this is done purely to increase efficiency by decreasing redundancy. In a super-large keyspace, however, the redundancy caused by duplicated effort isn't nearly as big an overhead as most people think.

To be precise, the efficiency of an uncoordinated effort decreases over time, initially following a roughly linear curve, but tapering off as the area of the keyspace already searched becomes larger. For example, when 5% of the keyspace has been searched, there is a 95% chance that any random trial will try a key that has not been tried before. When 50% of the keyspace has been searched, the system tries new keys with 50% efficiency.

The (somewhat surprising, I think) result of this is that if it takes time T to search 50% of a keyspace at 100% efficiency (no double-checking any keys), then a system that picks keys at random can check the same portion of the keyspace in time T*1.39 on average. Although the random system is operating at 50% efficiency by the time it hits the 50% mark, its history of greater efficiency means that its average efficiency is closer to 72%.

This is a clear loss of efficiency relative to the coordinated approach, but with two major benefits. First, there is no communication or memory overhead in the cracking algorithm! None! The system is stateless and need only report success to someone when it actually finds something. The client need only check in with a central server to see if the lottery is over and if there is new work to do. The second benefit is a consequence of the first: because there is no need to report progress, clients can't submit false negatives. Indeed, there is no part of the protocol where negatives are reported!

Of course, if we go for the chinese lottery solution, then the nature of the central organiser goes from one of coordinator to one of "site where the software is developed and discussed" and possibly "where decisions are made about what problems to feed the clients". I really like the chinese lottery idea: it's really distributed!