[HARDWARE] Cracking engine wish list

Dan Oetting oetting at gldmutt.cr.usgs.gov
Sat Jan 8 18:07:01 EST 2000

At 12:35 -0700 1/8/2000, John L. Bass wrote:
>I went looking in the announce archive for any clues why the CSC test went
>over 100% and the key server is still handing out keys. The web site is
>totally useless for current state information on the project. It's getting
>pretty clear that somewhere there is:
>	1) a bug in a CSC client
>	2) a machine that returned incorrect results due to a HW failure,
>	   possibly an overclocked machine or bad MB/Memory.
>	3) somebody who ran with a hacked client.

You forgot to include the possibility of a bug or failure in the servers.
In any of these cases since there isn't any way to locate the cause of the
failure the proper solution is to run the project again without any common
components that would reintroduce the same failure. I'd give
distributed.net another day or two to finish all the blocks or at least
tell us exactly how far we have to go. Then we should all jump over to
DCypher.Net to finish the project :)

>Dan's transparent inline autotesting is starting to look like a better idea.
>For Dan's idea of inline testing to be successful it would need to provide an
>auditable result including bits from every key in the block - maybe some form
>of hash/CRC in the inner per key loop.

There are actually 3 components that go together to make a solid
verification strategy.
1. Tracking ID - a form of electronic signature that allows the server to
group all blocks processed by the same CPU.
2. Residual Check - a simple check sum (XOR) of the final result of every
key processed. Can be used to verify 99% of the client operation for
selected blocks but requires the block to be reprocessed.
3. Inline Testing - requires the client to process every key to find a test
result but can be instantly verified by the servers. Also verifies the last
1% of the client operation with every block processed.

>That still doesn't prevent a hacked client from returning a false "fail"
>when the
>key is found - possibly with the intent of submitting an independent claim
>for the

The server has a log of where every returned blocks came from. The prize
may not be awarded if it is shown that the hacker was using unauthorized
resources (ie: the distributed.net servers).

>Distributed.net's unbalanced award percentages, and unwillingness to share
>key space with smaller distributed efforts like Dcypher.net, invites this
>abuse. For larger contests that should take years to complete, it would be
>more productive for the world-wide community to share key space rather
>than have
>everyone, especially smaller teams, be forced to check keys already checked by
>other larger teams.

Distributed.net is already sharing the keyspace for RC5-64.

>I don't see why this couldn't be done for smaller contests like CSC too.

If everybody in distributed.net jumped on CSC it would have been finished
in less than a week. Coordinating the keyspace may have taken longer.

>I would certainly be willing to host an international key arbitrator
>that handed out random key blocks in several day to week sized processing

If you are going to coordinate the keyspace you need to be sure that all
groups are counting the same way. In RC5-56 there were at least 3
independent groups and each one was counting in a way that was incompatible
with sharing keyspace with the other groups. Because of the different
optimizations in bitslice DES depending on the counting order
distributed.net almost became incompatible with itself in one round.

-- Dan Oetting <oetting at ghtmail.cr.usgs.gov>

To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net

More information about the Hardware mailing list