From: Raph Levien <raph@CS.Berkeley.EDU>
Date: Thu, 19 Oct 95 15:02:37 PDT
To: sami.shaio@eng.sun.com
Subject: Java power
Message-ID: <199510192201.PAA14221@kiwi.cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


   At the recent cypherpunks meeting about Java, I was fairly
skeptical of its power, especially its ability to do anything useful
towards interesting cypherpunk projects. I've been thinking about it a
bit more, and I believe I was overly pessimistic.

   My thinking problem was that I was envisioning Java as a
replacement for ordinary HTTP server interaction (such as CGI
scripts). I still believe that, absent HTTP server interaction, Java
applets are quite limited. However, now that I've started thinking
about systems that are built using a combination of Java and servers,
the universe has expanded a lot.

   I'm still unclear about the exact security policy implemented by
Java browsers, but this is my understanding:

   * No access to local files at all.

   * Can only access URLs on same server as applet came from.

   Actually, I'm pretty sure the latter is an oversimplification, that
the applet can contact any socket as long as it is on the same IP host
as the applet itself. However, since HTTP can do pretty much anything
any other socket can, the only difference that makes is performance.

   Here's the "big insight" I had: the server can make up _both_ of
these deficiencies, by acting as a file server and communications
proxy. Essentially what this architecture does is shift the security
burden from the client to the server. In this way, the applet can
become "net complete," rather than merely Turing complete.

   I see one big drawback to this approach. Setting up a server like
this is pretty expensive, and using it takes up precious resources.
Not everyone has access to a fully scriptable server, which will limit
a lot of people.

   One concern is the "parasitic" use of file system resources on the
server. However, there may be a certain amount of security through
obscurity that makes this ok. If all Java browsers enforce the policy
of only allowing connections to the home host of the applet, then you
won't be getting connections from other, parasitic applets. The
remaining danger is rogue Java browsers, and non-Java applications
that talk to the server, pretending to be Java applets. Some form of
authentication could be used to reduce the impact of these attacks.

   I do see this kind of architecture used to supply services at, say,
an organizational level. For example, the "scheduling" scenario could
be implemented quite handily, including authentication of access to
the schedules, and even distributed scheduling if the different
servers are talking to each other.

   Another scenario which works is email, even including transparent
encryption. This one is interesting to me, so I'll go into a little
more detail.
   In this scenario, the server acts as a file server for keyrings
(both public and secret) and mail spools. Here's a typical sequence of
events for me getting my mail and replying to one message:

1. I call up the JavaMail web page, which is just a wrapper for the
JavaMail applet.

2. The JavaMail applet starts with a forms-style login screen. I type
my username.

3. The applet asks the server for my mail spool (given the username
and perhaps also a password for authentication).

4. The applet displays my mail spool on the screen and lets me fiddle
with it, scrolling through it, reading messages, etc.

5. Let's say one of those messages is encrypted with my public key.
The applet, recognizing that fact, queries the server for my secret
key, encrypted of course (with a symmetric cypher).

6. I type my password to the applet, which lets it decrypt the secret
key.

7. Now, that it has my secret key, the applet can RSA-decrypt the
encrypted mail and show it to me.

8. I want to reply to the message, so I hit 'r'. The applet gives me a
window for typing my reply. When I'm done, I click "send". The applet
queries the server for the recipient's public key.

9. When the applet gets the public key, it RSA-encrypts the message
and sends it to the server for delivery.

10. When the mail has been delivered, the server notifies the applet
of the fact.

   To me, this is an exciting scenario. Note that, as long as you
trust the browser, this lets you read your mail from anywhere.

   I have no idea whether this scheme is practical. One temporary
drawback is the speed of RSA operations. However, this will get fixed
when there is native code generation or a bignum library, whichever
comes first. Even before then, performance can still be good, using
two techniques. First, implement a cache of decrypted session keys
(also stored on the server in symmetrically encrypted form). Second,
don't display a new email message until it's been decrypted. That way,
the RSA operation affects only the latency of mail delivery, not the
bandwidth of reading through messages. Of course, these techniques
will also dramatically improve performance even for native code
crypto.

   I can see people setting up servers like this for themselves.
However, here's an idea on how to set these servers up "for profit."
In return for providing file system and mail communications services,
the server would expect clients to search keyspaces during idle
cycles. When Java goes native code, the computing power thus tapped
could be quite substantial.

   I'm interested to hear what people think about these proposals. Is
this something that cypherpunks should be doing full steam ahead?

Raph