[1402] in cryptography@c2.net mail archive
Re: Checking for cheaters in distributed challenges
daemon@ATHENA.MIT.EDU (Adam Shostack)
Tue Sep 2 09:34:40 1997
From: Adam Shostack <adam@homeport.org>
In-Reply-To: <Pine.LNX.3.95.970831123813.5103A-100000@alpha.sea-to-sky.net> from Steve Reid at "Aug 31, 97 01:09:38 pm"
To: sreid@sea-to-sky.net (Steve Reid)
Date: Tue, 2 Sep 1997 09:04:27 -0400 (EDT)
Cc: unicorn@schloss.li, cryptography@c2.net
Steve Reid wrote:
| Each time the key server receives a report of a searched block of keys, it
| should also receive a list of keys that resulted in near misses. It would
| take just one decrypt operation per near miss to verify each near miss. If
| someone reports keyspace searched but reports bogus near misses, the
| person is untrustworthy. The key server should ignore people deemed
| untrustworthy.
The server should not ignore people deemed untrustworthy; that allows
for an attacker to find the servers criteria, and game their approach.
The server should use the untrustworthy to check each other's work.
This is because we've already decided to not accept it. If the
suspected cheater gives us more information than we had before, than
we win, even if they are a cheater. If they don't give us back extra
information, it demonstrates nothing (cheaters can collude, after
all.)
So, by ignoring possible cheaters, we inform them of the cheating
criteria, fail to exploit their cycles for checking other cheaters, an
gain nothing from the detection. Here we have a small possibility of
a gain (the case where they are accidentally labelled a cheater, or
the case where, discovering that they're in the cheater pool, give up
the key in the hopes of getting themselves out.)
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
