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