From: Will French <wfrench@interport.net>
Date: Tue, 29 Aug 95 21:00:00 PDT
To: sjb@austin.ibm.com
Subject: Re: SSL trouble
Message-ID: <199508300356.XAA09408@interport.net>
MIME-Version: 1.0
Content-Type: text/plain



Scott Brickner writes:
> We've identified several forms of "real-world retaliation:"

> 1) "Result hoarding" - failure to report a found key
> 2) "Segment hoarding" - requesting more segments than one can hope to search
> 3) Denial of service - preventing access to the server

  Perhaps I wasn't clear... by real-world retaliation, I'm
referring to being sued, thrown in jail, belabored about the
head with blunt objects, etc.  The three basic defenses I have
are: (a) not getting people angry, (b) not letting them know who
to be angry at, or (c) the threat of counter-retaliation.  The
"random" method is of type (b).

  I think you are focusing a bit too much on theoretical
efficiency and not enough on bottom-line practicality.  A 37%
waste factor is better than staying in bed and wasting it all.

>>   I _don't_ care about the procedures, as long as I can get
>> the information I need to go my own way.

> So what information wouldn't you be getting?  To "go your own
> way", you need exactly the same information that the client
> workstations use to test one key.  The difference in your code
> and the clients exists solely in how they determine the next
> key to try.

Yes, this is currently true, but there was a suggestion of
witholding part of the challenge in order to keep people honest,
or something like that.  I didn't quite understand it, but I
didn't like it.


Will French  <wfrench@interport.net>