[RC5] Gaining A Statistical Advantage

Steve Bird sbird at UATC.com
Thu Dec 3 09:55:36 EST 1998

Besides, the only way to really implement this would be to basically have
their machine join d.net.  Do you really think it would be possible to get a
fully working client for their custom hardware built in the small amount of
time remaining before the contest starts?   Even if it could happen, their
client probably wouldn't be as optimized for their hardware as much as our
client software is for the different platforms. 

I disagree however with your comment about needing overlap,etc..  I don't
disagree with your reasoning...I just think that they have us at a
disadvantage.  D.net is really powerful, however, the rate at which we turn
over and start going after DES 3 will be critical.  If all clients instantly
switched then I think it would be fair, but we all know that they won't and
if THEY start at the same point that WE start and head towards the end of
the keyspace  then they'll beat us without question.  

Has anyone tried to determine their keycracking rate?  How does d.net

If we aren't faster than they are then we need to seriously reconsider the
whole idea of starting at the start of a keyspace and working linearly
towards the end.  There would be NO POINT whatsoever to this contest if this
were true.  Also, yes...in a real world situation there would be no
advantage to skipping about a keyspace searching for a key, but this is a
CONTEST with a $10,000 prize.  If we know we're going to lose then we HAVE
to alter our tactics...I personally like the idea of distributing keys from
the middle and working towards the start and the end.

No... a distributed system of computers using idle time isn't going to
outgun a dedicated piece of hardware.  It also isn't going to cost $250,000

		-----Original Message-----
		From:	robert zwaska [mailto:rzwaska at nd.edu]
		Sent:	Wednesday, December 02, 1998 6:39 PM
		To:	rc5 at lists.distributed.net
		Subject:	Re: [RC5] Gaining A Statistical Advantage

		The discussion continues on whether we could improve our
odds of winning
		by having peculiar choosing techniques for blocks,
expecially in the
		DES-III.  Someone even tried to inroduce "lottery" logic.  I
		everyone really knows that we stand the same of chance
winning no matter
		where we start.  That would indicate that we would be best
served by
		choosing a simple and straightforward manner for dividing
the keyspace.

		The other branch of the discussion is whether we would have
a sort of
		further combined arms with EFF.  That is, we would
coordinate our
		respective efforts to minimize the overlap of searching
involved.  This
		is the important question.  We have to decide what our
over-riding goal
		of our project is. We might say that we wish for the code to
be broken
		in the leat amount of time, in which case we would
coordinate the
		attempts to not overlap.  However, I would submit that we
		coordinate our attempts so that we maximize overlap.  That
way the group
		with the faster system stands a better chance of winning.
After all,
		this is a competition.  A prize was posted to spur groups to
try to come
		up with inovative ways to solve them.  Two are here posted:
		masssive distributive computer, and the very fast dedicated
		Which is better?  The competition will show, and the best
way to ensure
		the fastest wins is to maximize our overlap.

		Bob Zwaska

		To unsubscribe, send 'unsubscribe rc5' to
majordomo at lists.distributed.net
		rc5-digest subscribers replace rc5 with rc5-digest

To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list