From: Piete Brooks <Piete.Brooks@cl.cam.ac.uk>
Date: Sat, 26 Aug 95 14:58:08 PDT
To: Will French <wfrench@interport.net>
Subject: Re: SSL trouble
In-Reply-To: <199508262118.RAA15661@interport.net>
Message-ID: <"swan.cl.cam.:029190:950826215747"@cl.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain


>> Use integrity checks to ensure that the slaves are acting
>> properly. One method of doing this is to keep secret part of
>> the known plaintext (say 16 bits). A slave is required to
>> report _all_ matches in the range to the master. Slaves who
>> report a statistically low number of matches may be considered
>> suspicious. It is a simple matter to allocate part of that
>> keyspace to another processor for a double-check.
>  Please don't do anything like this.  This will prevent people
> like me who prefer the "random" method from participating.

You can't use the random method if the CRACK is using a sequential search.
It just doesn't fit !
You can't ACK something which has not been allocated to you.

However, if a CRACK were to be using random, the above would be useful as a
"progress report" as the rate of reports indicates how well the search is
going.
It would also allow more equal sharing out of the prize money, as on
average 2**15 "possible" keys would be found, and the first finder of each
would receive a fraction of the prize.


I don't know enough of the theory -- is there any limit as to how many
"partial" matches there could be in a single "segment" ?
(currently brure{ssl,rc4} stops on finding a match. They would have to keep
 going, and might have to return upto 2**16 partial results ??
)