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.
I don't get it. If the challenge is partly secret, how will I know if I crack the code?
The only difference would be that the sweeper who discovered the real key would not be the first to know of a break
? Sorry, the terminology seems to be over my head here.
and that it would not be possible to attack the crack through dishonestly claiming to have swept space that hadn't been.
That is one reason I like the random method.
You can't ACK something which has not been allocated to you.
But I could announce it on the list.
A clarification: my "it" above refers to a successful cracking of the code. Will French <wfrench@interport.net>
I don't get it. If the challenge is partly secret, how will I know if I crack the code?
You don't thats how we make sure that you can't crack the code and not tell everyone else. The servers can be validated by using a standard bit commitment type affair. Its a matter of principle, we should ensure that the key breaking service is not itself subject to cryptanalytic attacks. One small point, cryptanalysis equipment is also covered by ITAR restrictions. Phill
participants (2)
-
hallam@w3.org -
Will French