From: John Brothers <johnbr@atl.mindspring.com>
Date: Mon, 23 Sep 1996 06:01:00 +0800
To: cypherpunks@toad.com
Subject: Internet File System?
Message-ID: <1.5.4.32.19960922191022.00736898@pop.mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain



The other day, it occurred to me that Java could really take off if there
was some sort of file system.  And, since you can't write to local files
with Java, the obvious solution is to set up the 'fopen, fclose(), etc)
set of functions that are 'rpcs' to some server application on the same
computer as the web server the applet comes from.

Since I never manage to come up with new concepts, I assume someone is already
working on this, or has already created this.  

In any case, I've been trying to figure out the best balance of security
characteristics for this sort of system.  I've written something up at
a very high level -- Please let me know what is wrong
with it. 

1)  Before any files can be written or read, the applet has to prompt the
    user for a password.   
2)  Password is encrypted one-way, and sent to the server.
3)  Server establishes a 'session' (TCP) with the client.  At the point, the
    options are:  
     -- use SSL to maintain security (probably the best, if available)
     -- providing some sort of encryption, similar to SSL
4)  Server would handle all the traditional file manipulation routines, 
    possibly with some restrictions (no access to directories, maybe?)
5)  If someone wanted to get a local copy, they would have to ftp to the
    server, and go to the appropriate place to get it.

I can tell this has a couple of weaknesses:
 a) central authority for creating accounts, maintaining users, etc.
 b) server side can view all the files at will.
 b) susceptible to trojan servers

I don't know how to reliably solve a).  If you don't have some sort of central
user admin, you can't avoid denial of service/resource wasting attacks.

b) Could be solved by having the user type in (or cut and paste, etc) their
   entire public key.   They could ftp the encrypted document back, and
   decrypt it with the private key.  This would detect and prevent a lot
   of problems, but dealing with the key would be a bit cumbersome.  

c) If the server has to send out some sort of validation code that the
   clients have to accept, it will work ok.  But if the attacker has access
   to the server, they may have access to the java code, and may be able
   to modify it to not perform the validation.

Any ideas ?

  Thanks for your time.
---
John Brothers 
   Do you have a right not to be offended?