[RC5] DES 2 (in preparation of)

Greg Wooledge wooledge at kellnet.com
Fri Jan 2 19:59:41 EST 1998

B aka B (balzak at metsys-open.demon.co.uk) wrote:

> 1) As I understand it, there is a central server controlling the distribution of
> each of the quadzillion (or more) packets to be tested for the hidden message so
> that each is only processed once.

phoenix:~$ echo 2^64 | bc | number
eighteen quintillion.
four hundred forty-six quadrillion.
seven hundred forty-four trillion.
seventy-three billion.
seven hundred nine million.
five hundred fifty-one thousand.
six hundred sixteen.

Yes, there's a central server, and many distributed "proxy" servers.

> a client on their machine that downloads a set of
> packets when they dial-in and connect to the Internet, and uploads any completed
> 'results' from the previous batch once processed by their client

In a nutshell, yes.  You have a bit of control over the timing of events,
however -- at your discretion, the client could run an update (send and
receive blocks) whenever you connect to the Internet; or it could poll
periodically attempting to connect and eventually succeeding because you
just connected to the Internet; or if you use demand dialing the client
could actually initiate an Internet connection.  Of course, if you're
permanently on the 'Net, it's even simpler -- the client will simply
connect to the proxy server when it needs to get more blocks or when it's
"filled up" it's "outbox" (and you control the number of blocks which
triggers this event).

Basically, you're in control, and if you need help getting the client
to do something, just ask here on in the #rc5 IRC channel.

>- which all
> happens behind the scenes when their computer/LAN is doing nothing else.  Is
> this understanding right?

Mostly right.  The cracking actually occurs when your CPU is otherwise
idle.  However, the client/server connection doesn't attempt to measure
network utilization.  Don't worry about that, though, since the amount
of network traffic generated by the client is trivially small.

> 2) As far as the competition is concerned, how is the 'winner' discerned?  If
> all the calculations, etc are being handled in the background, how would you
> know if one of 'your' packets held the solution?

When a *potential* match is found, the proxy server is notified, and
then the client logs the potential match.  If you don't read your logs
regularly (and I don't know anyone who does), you'll probably miss it.
But don't worry -- if you *do* find the real key, you'll be notified by
mail at the very least.  (You are supposed to put your personal e-mail
address into the client configuration.  If you don't do this, you won't
be able to get the $1000 prize, and your e-mail address won't appear in
the stats....)

>I assume the distributing
> server keeps a record of who had what or the individual clients break into a
> 'celebration' algorythm?

Yes, the servers keep track.  Remember that $1000 of the $10000 goes to
the person who finds the winning key, so they have to track you.

> 3) When up/downloading packets during a dial-in, how long will it take to
> complete the transaction?  Ie, how long @ 28k8 (for example) will the process
> need the line kept open for?

It depends on how many blocks you're sending/getting.  A few seconds is
usually enough, or a few minutes at the most.  The more often you connect,
the shorter each connection will be.

# Greg Wooledge                         # "Daddy, why do those people have to
# wooledge at kellnet.com                  #   use Microsoft Windows?"
# http://kellnet.com/wooledge/main.html # "Don't stare, son; it's not polite."
#        --  Crack RC5-64 now! http://www.distributed.net/rc5/  --
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list