Tom Guptill tgpt at pas.rochester.edu
Sun Jun 22 15:55:27 EDT 1997

I still don't see what's wrong with keeping track of which blocks were
processed by "trusted" (i.e. v3) binaries and which ones were processed by
"untrusted" (i.e. source-available) binaries.  Then, if the key has not
been found at the end of the keyspace, you simply start handing out the
"untrusted" blocks to "trusted" clients only.

If the number people who require source is as minimal as people seem to
think, the likliehood that people will hack the source to only notify
*them* of a successful block *AND* actually get the block that contains
the key seems like a pretty minimal risk to me...

- Tom

Tom Guptill                     Department of Physics and Astronomy
UNIX SA                         University of Rochester  Rochester, NY USA
                                HEPNet:  tgpt at urhep
On Sun, 22 Jun 1997, Kris Van Hees wrote:

> > I will admit that I presented my idea while ignoring the reasons for the
> > discontinuing the v1 clients.  It was presented in the spirit of "maybe
> > there's a way to satisfy "source required" organizations without releasing the
> > source to the v2 clients".  Cryptographically signing the binaries is a good
> > idea, though I don't know how acceptable that will be to the "source
> > required" organizations.  I've seen the source to the v2 clients while
> > working on the VMS port and I haven't seen anything malicious so far... 
> > (For the organizers to code in something malicious would again be a stupid,
> > "self-destructive" thing.)
> A signed binary has no value in my case, since there is no 'authority' who
> is going to be willing to 1) sign the binary, 2) take responsibility in the
> extremely unlikely event something goes wrong (bug, inteneded, whatever, ...)
> I bet.  And since I run this on machines which I cannot put at risk (and I
> would in fact put my very job at risk by installing a binary for which there
> is no one who takes responsiblity).
> On the issue of a v1/v2 gateway not helping.  Well, with all respect for the
> organizers and designers of the rc5 servers and clients, if you need to use
> obscurity to avoid false reports, and people holding back blocks, and doing
> other doubtful and possibly selfish things... Well, then I think we're most
> of all fighting a design flaw.  Maybe I'm alone in my view but:
> 1. If no proper verification of block replies exists, that is a serious flaw.
> 2. If getting continuous positive replies to blocks, and not being able to
>    cope with that by either verifying them, or simply ignoring the client
>    who is being the culprit, then that is another flaw.
> 3. If someone not reporting back on blocks, and no way to either re-issue that
>    (or those) blocks in some way to provide redundancy -or- simply accepting
>    that if you want to have the cooperation of a very large amount of users,
>    you take the risk that someone might take advantage of the situation...
>    well, I thought we did this out of principle, rather than trying to make
>    money?
> Anyhow, I believe we haven't heard the comments on this issue yet from the
> actual organizers/designers.  Though I doubt the comments will be supportive
> of trying to keep the people who are like me unable to run non-locally
> compiled binaries, I would prefer to keep up the hope.
> Kris
> ----
> To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list