FW: [rc5] Next Crack

Robert N. Waybright neilw at cts.com
Sat Aug 23 11:38:01 EDT 1997


I meant for this to got to the list.....

----------
From:  Robert N. Waybright[SMTP:neilw at cts.com]
Sent:  Saturday, August 23, 1997 12:15 AM
To:  'Vincent Janelle'
Subject:  RE: [rc5] Next Crack

The rules you cite are somewhat true for applets, but java applications can access local resources, do file I/O (FileInputStream), call native methods (compiled C, or probably any other language that follows C calling conventions), open its own network connections (Socket, DataInputStream), etc.  We have javastations whose entire OS is written in Java.

There may be still room in the project for a java based wrapper that calls a highly efficient native method to perform the actual number crunching.  How much would have to be native is a matter for experimentation.  Since the library with the native method might be quite small, it brings up some interesting possibilities for distribution of revised code through the key server.

As for the security aspects of things, since many of the public key encryption algorithms fell out from under their patent protection this year and are in the public domain, could we use something like public key verification of blocks and code signed by the servers private key?  I don't remember which ones they were, but I remember the posts on the USENET news....

Neil

----------
From:  Vincent Janelle[SMTP:random at avara.com]
Sent:  Friday, August 22, 1997 5:41 PM
To:  rc5 at llamas.net
Subject:  Re: [rc5] Next Crack

Uh sorry to burst your bubble, Java wn't fly that way.  Java is designed
with security in mind, so executing code all willynilly off the person's
hd is a no-no, and besides, tha would defeat the purpose of a Java client,
since you would need precompile code made for that person's OS and
processor type, which also defeats the purpose of Java.  And in fact, with
the java intepreter overhead, it would be slower.

On Fri, 22 Aug 1997, Steve Trottier wrote:

> It wouldn't be that slow if you had most of the client functionality in Java
> but had the cracking portion done as a native method.  Keyspace retrieval,
> transmitting, buffering, user interface, etc, could all be done in Java and
> the code cracking stuff could be done in a platform specific loadable module
> (DLL or whatever) and in theory it should be just as fast as it is now.
> 
> >>> Vincent Janelle <random at avara.com> 08/22/97 02:49PM >>>
> Sigh, Java code is slower than taking the v1 source and compling it on
> your own machine.  In fact, it is 130 times slower, and due to "features"
> in Java, you would have to have a proxy server on the server you retrieved
> the url from.  It is a nice idea, and it was done, and it was slower than
> a SE/30.  Since the machines that Java has been ported to already have
> native client, the loss in performance would be tremendous.
> 
> On Fri, 22 Aug 1997, fulltilt wrote:
> 
> > Just a quick one...  How about the performance of the JAVA code?  I
> > thought this came up w/the RC5 effort?  Is there a give, (performance)
> > and a take (flexible client) when it comes to JAVA?  I know that
> > performance is a BIG issue here, or at least it seems it.  (read
> > Cyberian effort)
> > 
> > Just a though, would like it clarified.
> > 
> > Thanx
> > 
> > fulltilt
> > 
> > ----
> > To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5'
> in the body.
> > 
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                                             
>                                                           
> ----
> To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
> 

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


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



More information about the rc5 mailing list