Re: Fwd: [DES-ANNOUNCE] New clients and 'spamming'

Dan Oetting (oetting@gldfs.cr.usgs.gov)
Mon, 5 May 1997 14:57:46 -0600

>On Mon, 5 May 1997, Nelson Minar wrote:
>
>> There are some serious, realistic threat models on a distributed
>> attack like deschall. On a discussion on coderpunks a few months ago
>> the consensus was that the only really safe solution was a completely
>> uncoordinated one - every client pick random blocks.
>
> Assuming that the percentage of malicious clients is fairly low, you can
>achieve a rather high degree of certainty that blocks are being searched.
>The easiest way is to compute a checksum of the decoded results. You then
>hand out the same keyspace to another host (or more, if you're paranoid),
>and make sure both checksums match. This obviously cuts the search rate at
>least in half, so you can optimize it a bit by only spot checking. The
>most you spot check a host, the less chance it has of cheating.

The damage done by malicious clients is ZERO until the search reaches 100%.
Except for a small load on the server the only effect is to inflate the
statistics. If the search does reach 100% coverage there will be a small
loss while the logs are spot checked to uncover the perpetrators.

Every new host should be checked once to be sure it is not inadvertantly
running a bad client.

> There are also a couple variations on this which require the client to
>find a known result within its key block. This requires a small amount of
>work on the server, but ensures the clients are checking at least 50% (on
>average) of their assigned work.

If you require the client to find all matches to a pattern that has at
least a probability of multiple occurences within the range you will force
a 100% search if the client doesn't want to get caught cheating.

> The one "flaw" in spot checking is that a malicious client that lies
>*only* if it finds the key is hard to detect, unless another host is asked
>to spot check that exact range.

You will detect it when somone else clames the prize. It will be too late
for spot checking.

-- Dan Oetting <oetting@gldfs.cr.usgs.gov>