[RC5] client protocol security
j-zbiciak1 at ti.com
Wed Nov 19 13:55:36 EST 1997
| There's no way to generate the correct hash without processing the
| entire block and you'd only need to double check, say, one in a hundred
| blocks to make sure that nobody was cheating.
If the d.n keyservers were responsible for the checking, this would get
very expensive to do. You could, however, just duplicate 1 in 100 blocks
out to the clients, and compare notes when they're returned. Perhaps
run a modified client in the background on all the keyservers which only
does block verification as an added boost.
To really formalize this, you might want to have a "confidence level"
in the database of returned blocks. Blocks which have been returned,
but not verified, would have the lowest confidence level. So, when we
hit the end of the keyspace, we start redoing blocks with the ones
which were assigned and never returned (as we do now.) When those run
out, we do the ones with low confidence next (meanwhile grumbling about
those bastards who made off with the key... ;-)
| Doesn't eliminate the chance that you steal the winning block instead of
| reporting it back but hey, can't solve everything!
There's a couple aspects working in our favor here.
First, if the person is participating in the Bovine effort, the logs
will have his IP address(es) and likely his email address in there.
Participating in Bovine is beneficial since it ensures that you're not
duplicating work (or duplicating very little). Just running random
blocks on your lonesome won't get you there, so there's a huge impetus
to playing as part of the effort, at least for awhile.
Second, the Bovine terms and conditions of use require the person
operating the client to comply with d.n's plans for the $10,000.
(Basically, $1,000 to d.n, $8,000 to Proj. Gutenberg, and $1,000 to the
lucky sap who got the key.). I believe this is a legally binding
agreement, so if someone tries to pull that off, d.n has recourse
against them -- and 10,000-20,000+ angry d.n participants is a force to
be reckoned with!
Third, it'll pretty obvious when someone reports the key to RSA,
regardless of who does it, so we can all check up on their validity
when they do. It isn't exactly going to happen in secret.
Basically, it's an awful lot of trouble to go through for $10,000,
especially with the piss-off factor involved and the potential legal
consequences as well. Spoofing blocks is much lower profile and so
is much likelier to happen if some k3wl h4x0r d00d decides to raise
Are blocks tagged via IP, email address, or some other identifier in
the database logs? It would make it really easy to invalidate all
blocks returned by a weasel, or even by a client which is discovered
to be buggy after-the-fact. Or is this in the v3 protocol? ;-)
+------------ Joseph Zbiciak -----------+
|- - - - - j-zbiciak1 at ti.com - - - - -| You have the capacity to
| - http://www.primenet.com/~im14u2c/ - | learn from mistakes.
|- - - -Texas Instruments, Dallas- - - -| You will learn alot today.
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5