[rc5] Next Crack

Ryan Krueger rskrueger at jtmd.com
Thu Aug 21 09:26:13 EDT 1997

I said:

>> I can imagine two possibilities:
>> 1. Certain organizations (Bovine, Cyberian) make a wrapper client for 
>> each platform that runs in the background and they swap the problem 
>> whenever they want to something different.  This is interesting because 
>> they could get this massive installed base and then sell time to some 
>> company that needs incredible power.  But most time would be for more 
>> academic purposes, otherwise people wouldn't volunteer their CPU time.
>> 2. A generic distributed process API is created and all machines have it 
>> as an option at install time (default on).  Then a developer could write 
>> a chunk of code to the API and it would distribute it on the internet in 
>> real time and then return the answer.  I know stuff like this has been 
>> done a little before, but not yet to the point where any machine can be a 
>> partner in any arbitrary problem.  Of course Java is an ideal language 
>> for this, except that it's slow which defeats part of the whole point, 
>> but it does diminish once you have so many computers.

Team RC5 at Inet One said:

>I think your suggestions will not work. People devote their CPU time for 
>RC5 because they know they are making a good cause and, most importnatly, 
>they have full control over their machines (other than the fact that they 
>still have to trust the binary). But when people have to trust more than 
>that, i.e. let some organisation (be it Bovine or Cyberian or ...) have 
>full say of what to run, they will hesitate qnd most likely not to 
>I think what we need is to come out with some "generic distributed.net 
>client" with a pluggable cracking/application engine. The owner will only 
>need to install the generic client once on each of his/her machines, and 
>then remotely control and plug in whatever cracking code he/she wants. 
>The generic client basically does two generic things: 
>(1) listen for the owner's instruction to plug in the engine code, with
>proper authentication mechanism; perhaps it will also let the owner check
>its status and start/stop the current engine; 
>(2) does the actual cracking/processing job, by requesting the data/key to
>be cracked/processed via the network, feeds it to the engine, starts the
>engine, receives the completed result, sends the result, and repeats the

You've got it right.  People are going to be scared by the "Good Times 
Virus" crap when some reporter idiot writes an article saying that the 
distributed team (Bovine, etc.) could send out a virus and gets people 
all scared.

They're not going to have an incentive to install it on their machines 
other than interest in the project.  Of course once it's installed and if 
it's "quiet" (non-intrusive) they might just let it stay running.

I think in the future all these people (myself included) that do 
everything that they can to squeak out a few extra kkey/s are not going 
to do that.  They'll just make sure that it's running on every machine 
that they can and leave it.  (Of course some still will.)

Anyway, Bovine is the first situation (wrapper client).  The problems are:

1. Getting the v3 client out before cracking the RC5.  (Don't slow up RC5 
though.)  Because if it's not ready to go then all the people working on 
RC5 with a v2 client will go away.  Some will watch closely, but a lot 
will not immediately be back for the v3 rollout.

2. Beefing up the communications.  Make it even easier to run.  On a new 
machine it should do everything possible to not ask the user anything.  
If it's behind a firewall then hit the Netscape or IE pref file to grab 
the firewall/proxy info automatically.  I'd say that the standard Bovine 
port should be 80 for compatibility.  Anyway, it needs to work with 
existing systems very, very well.

3. Heading off the virus people.  (Both the people that create them and 
the people that don't understand them.)  First by working on security, 
and second by posting information about the possibilities (in a place you 
can't miss it).  People are really freaked about viruses and they just 
don't understand.  I still get "Good Times" warnings.

4. Making it both easy to be ignored and easy to control.  If a person 
wants to watch everything that goes on they need to be able to, but it's 
very important that people can forget about it.  I think that's where the 
big number of people will be.  After a few months a lot of people won't 
care as much as we (the people that bother to read this list) do.
As Team RC5 at Inet One said:
>Note the most important feature here is, the owner has full control of 
>what to be run and when to run, etc, and without having too much effort 
At the same time it's gotta be such that the user can say "I trust 
Bovine, just let them do their thing on my computer."

5. Keeping people interested.  Cryptography is interesting, but is prime 
numbers?  I don't really know, I am, but are other people?  How about 
SETI, chess engines.  Note that this is closely related to number 1 
because if the client is installed and automatically grabs the new 
problem then the people are more likely just to let it go onto another 
"not-interesting to me" problem.

6. More?

I wonder if the Bovine people are thinking about a v3 Mac client yet.  
...it is the largest group on Bovine.

-Ryan Krueger
-rskrueger at jtmd.com
-James Tower Media Design

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list