[HARDWARE] Cracking engine wish list

Jeff Wilhelm jeffwilhelm at hotmail.com
Sat Jan 8 14:45:31 EST 2000

i think there was an e-mail yesterday explaining the situation, and i
believe there is an official statement on the website.

--- --- --- --- --- --- --- --- --- --- --- --- --- ---
J E F F R E Y   M .   W I L H E L M

  Phone: (860) 688-2976
  Voice Mail: (860) 285-7779 x2811
  Fax: (419) 735-8865
  E-Mail: jeffwilhelm at hotmail.com
  Internet: http://jjjweb.cjb.net
--- --- --- --- --- --- --- --- --- --- --- --- --- ---
The Usenet Oracle has pondered your question deeply.  Your question was:
Will your answer to this question be in the negative?
And in response, thus spake the Oracle: Memory fault.  Core dumped.

CPU time is a terrible thing to waste!
Join the world's fastest computer - http://www.distributed.net

----- Original Message -----
From: John L. Bass <jbass at dmsd.com>
To: <hardware at lists.distributed.net>
Sent: Saturday, January 08, 2000 2:35 PM
Subject: Re: [HARDWARE] Cracking engine wish list

> On Sat, 18 Sep 1999 13:33:04 -0600 Dan Oetting wrote:
> > This looks like a good place to reintroduce inline testing. Currently
> > d.net clients test themselves once at startup and assume if they pass
> > startup tests everything will function perfectly. As we move to
> > cracking boxes there is more opportunity for hardware and software
> > to invalidate the cracking efforts. My inline testing procedure verifies
> > the proper operation of the client with every block processed. And the
> > 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
> > verified when the logs are processed so even intentional tampering
> > 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
> It's a little annoying the Distributed Net team is exhibting poor
> skills with the community resources that crunched the CSC test. Maybe we
> 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
> auditable result including bits from every key in the block - maybe some
> 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
> several alternatives are possible, including black listing the client and
> 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
> 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
> 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. I don't see why this couldn't be done for smaller
> like CSC too. I would certainly be willing to host an international key
> that handed out random key blocks in several day to week sized processing
> Just my two cents ...
> John Bass
> --
> To unsubscribe, send 'unsubscribe hardware' to
majordomo at lists.distributed.net
To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net

More information about the Hardware mailing list