[HARDWARE] Cracking engine wish list

John L. Bass jbass at dmsd.com
Sat Jan 8 12:35:41 EST 2000


On Sat, 18 Sep 1999 13:33:04 -0600 Dan Oetting wrote:
> This looks like a good place to reintroduce inline testing. Currently the
> d.net clients test themselves once at startup and assume if they pass the
> startup tests everything will function perfectly. As we move to dedicated
> cracking boxes there is more opportunity for hardware and software errors
> to invalidate the cracking efforts. My inline testing procedure verifies
> the proper operation of the client with every block processed. And the best
> part about inline testing is it doesn't cut into the cracking rate. The
> test for each block can be generated by the master server and the results
> verified when the logs are processed so even intentional tampering anywhere
> in the distributed network can be detected.

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.

Dan's transparent inline autotesting is starting to look like a better idea.

It's a little annoying the Distributed Net team is exhibting poor communications
skills with the community resources that crunched the CSC test. Maybe we can
start some side discussion and draw the insider scoop out into the public.

To open the discussion on possible ways to attack the problem:

	1) a bug in a CSC client.  
		1a) Re-running just the keys handled by non-x86 MMX clients would
		    only take a few days, possibly itteritively for keys processed
		    by non-MMX clients in the second/third pass. This would quickly
		    verify that an non-MMX architecture specific porting/compiler
		    bug didn't cause the problem.

	   If the key is still not found, that implies:

		1b) a bug in the MMX code, possibly at some internal boundry
		    not tested by the example cases.

		1c) a bug in the basic algorithm, possibly at some internal boundry
		    not tested by the example cases.

	   or #2 or #3.

	2 & 3) we are pretty much doomed to re-run the entire key space. March
	   isn't very far away. Should it happen a second time, there might
	   not be enough cycles for a third attempt.

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. Random retesting by a third party of blocks
submitted by all parties would confirm real-time that at least all keys are being
checked by the clients. Should a client be detected not checking keys properly,
several alternatives are possible, including black listing the client and continue
to hand them keys already checked by others so they would be unable to detect that
they had been discovered and move to a new identity.  This would mostly prevent
somebody from spoofing blocks without actually checking them, while using a small
number of dummy accounts to submit blocks under.

A hacker could still submit "false" blocks without checking the keys under a large
number false identitites. To fix this problem, distributed.net would have to tighten
up the registration process to minimize the chances of someone being able to forge a
large number of identities and remain completely anonymous. In most cases, it is
difficult for most hackers to gain access to a large IP pool since most ISP's use
a fixed pool of IP's per "POP" dial-in pool. It wouldn't take much to monitor for
"false" blocks being submitted by a small group of IP pools and black list those IP's.

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
prize. Distributed.net's unbalanced award percentages, and unwillingness to share
key space with smaller distributed efforts like Dcypher.net, invites this possible
abuse. For larger contests that should take years to complete, it would be much
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. I don't see why this couldn't be done for smaller contests
like CSC too. I would certainly be willing to host an international key arbitrator
that handed out random key blocks in several day to week sized processing blocks.

Just my two cents ...
John Bass
--
To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net



More information about the Hardware mailing list