Re: The Joy of Java

Somewhat independent of the security/safety issues regarding Java
applets, there are also questions about their suitability for crypto
applications.  Applets currently labor under several restrictions (at
least when part of the Netscape browser) which make it hard to do crypto:

  Applets cannot accept net connections, and they can only make outgoing
  connections to the host which provided them to the browser.

  Applets cannot read or write local disk files.

  Applets cannot access other local hardware, such as smart cards,
  printers, or microphones.

These restrictions make several things difficult.  Finding good sources
of entropy for random numbers is hard.  Applets do have millisecond
resolution event timers (provided that the implementation keeps times to
that resolution, of which there is no guarantee), so they can get some
entropy by keystroke timings or mouse movements.  But they have little
access to disk files or other sources of environmental noise.

Retaining secure information between runs is also hard.  Specifically,
there is no place to store key data other than by sending it to the
server and having it put it somewhere.  It would not be hard to have an
applet which created a public key, but the key would have to be stored in
an insecure location.  So the best it could do would be to encrypt the
key with a user specified pass phrase and hope that was strong enough.

The restriction on connections makes other applications difficult.  To
make an applet which can send PGP compatible email it needs to be able to
look up keys on the key servers.  This can only work if the host serving
the applet can look up keys for it.  It has to be either running a key
server or able to forward requests to one.  This requirement makes the
applet not "self contained" in that to put it on your web pages you also
have to have this other infrastructure in place.

Another problem is in trusting applets.  Imagine an applet to help you
participate in electronic commerce.  Just type in your ecash pass phrase
and it will help you open your ecash account and then charge you tiny
amounts as you surf the web.  But of course if the applet is capable of
withdrawing small amounts, it would also be able to withdraw big amounts
as well.  It could drain your bank account before you knew it.

Some of these problems might be fixed by giving applets limited access to
disk files.  But even then it would be risky to let an applet see your
PGP secret key ring or ecash wallet.

Signed applets can probably help with some of these as well.  If Phil
Zimmermann has signed the PGP applet, maybe you'll trust it as much as
you trust the PGP executable.  Likewise if Chaum has signed the ecash
applet you'll trust it as much as you trust the ecash software.

The thing to keep in mind is that you are already trusting people when
you use their code, or virtually any code for that matter.  PGP is
special because source is available.  Of course most people don't have
any guarantee that your particular binary was built from the source
that you see.  But all the other software you run makes you vulnerable.
How do you know that DOOM, for example, doesn't check to see if there is
a network connection and send out your PGP secret key ring?  You even
have a pointer to it in your PGPPATH environment variable.  Maybe that's
unlikely because you'd see your modem lights flash suspiciously, but how
about networking applications?  Suppose Microsoft's Internet Explorer
rummaged through key rings and wallets, piggybacking packets on your
output data as you browse?  You'd probably never know.

So there are limits to how much safety you can expect.  Hopefully with
signed applets it will be OK to authorize some overrides of the current
restrictions so that these other kinds of applications can be provided.

Hal

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?

> Somewhat independent of the security/safety issues regarding Java
> applets, there are also questions about their suitability for crypto
> applications.  Applets currently labor under several restrictions (at
> least when part of the Netscape browser) which make it hard to do crypto:
>
>   Applets cannot accept net connections, and they can only make outgoing
>   connections to the host which provided them to the browser.
>
>   Applets cannot read or write local disk files.
>
>   Applets cannot access other local hardware, such as smart cards,
>   printers, or microphones.
[SNIP]
> So there are limits to how much safety you can expect.  Hopefully with
> signed applets it will be OK to authorize some overrides of the current
> restrictions so that these other kinds of applications can be provided.

My understanding is, Java applications (as opposed to applets) don't have
those limitations, and can do _almost_ anything a C program can. The
applications still have the full cross-platform compatability. IMO dumping
the security of applets in favour of the capability of applications is a
good idea. After all, the applet security features have a lot of flaws, 
so why limit your programs when it's not offering any real security?

Signing programs is a good idea. It will provide better security than we 
currently have, without having to limit the capabilities of the software.

JMHO.

=====================================================================
| Steve Reid - SysAdmin & Pres, EDM Web (http://www.edmweb.com/)    |
| Email: steve@edmweb.com   Home Page: http://www.edmweb.com/steve/ |
| PGP Fingerprint: 11 C8 9D 1C D6 72 87 E6  8C 09 EC 52 44 3F 88 30 |
|              -- Disclaimer: JMHO, YMMV, IANAL. --                 |
===================================================================:)