[RC5] stop running the client?

Ryan Malayter rmalayter at bai.org
Tue Dec 14 19:17:36 EST 1999

Folks, I believe I mentioned in my initial post that the aforementioned paper did not apply directly to d.net, because d.net does not directly purchase its computer power with a fixed budget.

However, I did say that this paper is an argument in favor of running our shorter projects now, rather than after we finish RC5. That way, the number of projects that d.net can finish before future date x will be greater.

Moore's law dictates that the bulk of the RC5 cracking work will be done near the project's end. For example, let's say that without running CSC and OGR, our expected completion date (50% key space) for RC5-64 would have been 1/1/2001. If we include the CSC and OGR projects, our expected completion date for RC5-64 would probably only slip to something like 2/1/2001. So why not fit these projects in?

This is the same argument used for the old "shortest-job-first" timesharing method on mainframes.


-----Original Message-----
From: Mike Fisher [mailto:mikefisher at mindless.com]
Sent: Tuesday, December 14, 1999 3:04 PM
To: rc5 at lists.distributed.net
Subject: Re: [RC5] stop running the client?

At 12:01 AM 12/14/99 -0600, Stephen Berg wrote:
>On Mon, 13 Dec 1999 00:12:39 -0600, Ryan Malayter wrote:
> >The premise of this paper is that, for long-running calculations (like 
> the Rc5 crack) it is often better to WAIT to start it on newer hadrware, 
> beacuse you'll actually finish the task sooner.
> >
> >This is because of Moore's law. The author's calculations indicate that 
> if any task will take longer than 26 months to complete on current 
> hardware, you're better off waiting a wile and running it on new hardware.
>But what if the correct key just got handed out to a client, that key
>I've seen similar articles saying we shouldn't bother trying to go to
>the nearest star until we can travel faster than the speed of light.
>The theory being that if we launch a long term mission now, it'll
>still be chugging along while technology builds a newer faster way to
>travel and later missions could actually arrive at that star *before*
>the first one arrives.  But in that case we pretty much know how long
>it'll take to finish with current technology.
>If RC5 had been started on 8088's or 80286's back in the early 1980's
>could they have already finished RC5-64??  Maybe not without the
>internet access most of us enjoy today but I'd guess that the raw
>processor power was out there to at least start the job.  In the 20
>years or whatever we've had PC's around they could have checked a
>good 10 or 15% of the keyspace that we wouldn't have had to check
>This is all a layman's opinion, those of you with Computer,
>Statistics or Math degrees can probably shoot most of this full of

No, I think you're completely right, but allow me to summarize a bit...

Such a project as this (RC5) is cumulative, meaning that the work performed 
by slower hardware doesn't go to waste, it is just added to whatever newer 
hardware accomplishes.  Now, on the other hand, if you could only start 
*one* client on *one* machine and not switch it until it is done, then yes, 
wait for faster hardware (this follows from your space-travel 
example).  But since you can run multiple clients on multiple machines and 
add all their results together, go ahead and get a start!  You'll be that 
much ahead when the faster hardware arrives.

Now that I've tried to simplify it a bit, let me confuse the matter 
further...  If you are trying to minimize the *total* time spent on a 
project, then you'll want to wait for faster hardware, since it will 
naturally complete the stuff already done faster than originally.  And 
technically, I suppose that is what we're doing (trying to prove that an 
encryption algorithm is too weak by the time it takes to crack a 
message).  (Follow me so far? ;-) )
However, once we've started, we might as well finish, and some of these 
contests have deadlines on them, so we should go ahead and start with what 
we've got currently available.  Heck, you could end up in an endless 
loop--"Faster hardware coming in 18 months, wait." and when you get there 
"oops, even *faster* hardware coming 12 months from now, wait a bit 
longer!" and so on.  You have to start *sometime* right? :-)


Mike Fisher
Junior Computer Engineering Major  and  Network Engineer Co-op
mf33 at evansville.edu                     NetworkWCS
ICQ 445127 (home) and 28960914 (work)   mjfisher at networkwcs.com

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