Re: The Joy of Java

[Alex Strasheim <cp@proust.suba.com>]

[All of Hal's excellent post deleted]

Everyone on this list is shooting for military grade security, and Hal's 
just given us a lot of reasons why it's going to be hard to achieve that 
with Java applets.

I'm not sure that list proves that Java applets are completely unsuitable
for crypto applications, though.

I don't that the general public is ever going to have military grade 
security.  (I don't think I will either, for that matter.)  Most people 
don't have the discipline or the knowledge to use their tools properly.  
They'll pick weak passphrases, let other people have access to their 
computer, or not pay enough attention to plaintext disk residue.

"The best shouldn't be the enemy of the good."

The thing that's important is to set up workable and accssible systems
that are good under everyday (typical) use, and that don't impose many
limits on how secure individual users can make themselves.  Java applets 
and applications taken together could be good at that.

Most people probably pick weak PGP passphrases, and they probably don't
bother to edit the letters they intend to encrypt on a ramdisk.  But
people who have reason or the inclination to careful can avoid these
pitfalls and communicate with more security than more casual users. 

The things that make PGP worth using are (a) even casual users get a lot
more security than they would have without PGP, and (b) it's possible to
get just about as much security as is possible with anything if you use
PGP properly. 

The point is that a java applet that implements a mixmaster client might
not be nearly as secure as the unix C version, but if one existed it would
still (right now, at least) be the best way to send anonymous mail for a
comparatively naive user.  It would fit into a larger mixmaster system
that provides more security for people who are willing and able to invest
the effort it takes to run the unix version.

And better yet, shouldn't it be possible to set things up so that almost
all of the code in a crypto applet could be reused in a crypto application
that's more secure?  

Most crpto programs will need entropy, and that's hard to come by in a
java applet;  a java application should have an easier time of it.  Why
not write two versions of an entropy generator, one for applets, and one
for applications, so that someone who writes a mixmaster applet can get a
better mixmaster application for just a little more work?  

Isn't this sort of code reusability supposed to be what OOP is all about? 
Couldn't Hal's list of applet problems serve as the basis of two packages,
one for applets, and another for applications?  Each problem would have a
method associated with it in each version of the package.  Maybe the
applet package would have a routine to write a file, encrypted with a
passphrase, on a central server.  The same routine in the application
package would write the file, encrypted with a passphrase, to a local
disk.

Ideally, we'd have a mixmaster applet, with an explanation on the same
page that says the stand alone application would be more secure, and a
link to download it.

Does this make sense?