[rc5] Next Crack
STROTTIER at novell.com
Mon Aug 25 12:05:23 EDT 1997
Oh my. I wasn't talking about an applet (which does have security
restrictions) but rather a Java application. And it wouldn't excercise code
all willy-nilly. It would only exercise the native piece that went with it.
It would be no less secure than the current setup. Yes, you would still
have to compile the native method portion for each platform the way it is
being done now (you can even use Assembly), but all of the rest would only
need to be done once. Don't tell me there is no advantage to this. The
majority of the code in the current clients is not for cracking keys. And
the major differences between different client versions are for the
different user interfaces. Java has common user interface code that can be
used on any platform that has a Java virtual machine. And, in fact, it
would NOT be slower with the java virtual machine overhead because you could
send an entire keyblock into your native method and require no communication
between Java and the native method until the entire keyblock was finished.
At that point there would be an insignificant performace hit because the
native code would only have to communicate with Java once per keyblock (to
get a new one and to send off the work finished, etc.)
For those worried that Java is not widespread enough to be able to pull
something like this off--Java comes with a JRE (Java Runtime Environment)
that can be used to package an application so it can be used without
installing the JDK first.
>>> Vincent Janelle <random at avara.com> 08/22/97 10:40PM >>>
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
> but had the cracking portion done as a native method. Keyspace retrieval,
> transmitting, buffering, user interface, etc, could all be done in Java
> the code cracking stuff could be done in a platform specific loadable
> (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
> 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