Re: SSL trouble

> 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.


Will French  <wfrench@interport.net>

>> 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 ??
)

>> 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.

Not true, it would be open for anybody to sweep a random space and report the 
results. The only difference would be that the sweeper who discovered the real 
key would not be the first to know of a break and that it would not be possible 
to attack the crack through dishonestly claiming to have swept space that hadn't 
been.

	Phill