[RC5] Do not forget about the cheaters :)

Slawek sgp at telsatgp.com.pl
Fri Jan 9 06:59:18 EST 2004

Yes, I know that.

There are just so many options with varying
- client side cpu overhead
- server side cpu overhead
- server side database storage overhead
- proxy storage overhead
- reissuing keys overhead
- chances of finding clueless cheater
- chances of finding advanced cheater
- implementation complexity

I think the main problem here is that nobody's going
to turn proposed solutions into code :o)
That's why I'm trying to find the solution which is
as simple to code as possible.


----- Original Message ----- 
From: "Décio Luiz Gazzoni Filho" <decio at revistapcs.com.br>
To: "D.net Discussion" <rc5 at lists.distributed.net>
Sent: Friday, January 09, 2004 12:18 PM
Subject: Re: [RC5] Do not forget about the cheaters :)

Hash: SHA1

Unfortunately, this requires reissuing blocks and effectively wasting work
the process. The scheme described on my other email requires no reissuing of
keys, and shouldn't have much more overhead than the current system (though
there needs to be an array to store all the matches collected during that
block), and of course it can detect cheaters with high probability.


On Friday 09 January 2004 08:34, Slawek wrote:
> The simplest possible method of verifying the clients
> is making them report CMCcount for each block tested.
> Some blocks may be sent to other used for recheck
> and/or checked by d.net staff and results compared.
> This has no overhead for the client as CMCcount
> is already counted by all the cores.
> To break this the cracker would need to break rc5
> rendering all of the distributed.net rc5 work useless.
> Attacker may be able to guess CMCcount once or twice
> but it's virtually not possible to constantly guess it.
> /Slawek
Version: GnuPG v1.2.3 (GNU/Linux)


rc5 mailing list
rc5 at lists.distributed.net

More information about the rc5 mailing list