From: Hal <hfinney@shell.portal.com>
Date: Mon, 29 Apr 1996 20:36:01 +0800
To: cypherpunks@toad.com
Subject: Re: The Joy of Java
Message-ID: <199604290530.WAA25425@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


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