Re: What remains to be done.

[Black Unicorn <unicorn@schloss.li>]

>From: Black Unicorn <unicorn@schloss.li>
>> A.  Methods to run secure websites on insecure servers.
>> [...]
>> A software solution which permits local decryption makes traffic 
>> analysis less useful, presents the opportunity to use front end and
>> disposable www pages on domestic ISPs while imposing no liability on
>> the ISP itself, and opens several more effective traffic analysis
>> deterants.

>I don't quite understand what is being proposed here.  If the
>information on the web site is encrypted, who is supposed to be able to
>decrypt it?  Just one person, or some select group of people?  My
>concern is the difficulty of keeping keys secret if they are made
>available to more than one or two people.

>Once the keys are known to those who would oppose the publication of
>the information they can go to the ISP just as easily as if the
>information were not encrypted, and get them to take it down if it is
>illegal.

>It would seem that an equally effective method would be to use no
>encryption, but just a secret URL, one which is not linked to from
>elsewhere - an "island in the net", so to speak (apologies to Bruce
>Sterling).

>Hal

I was concerned with an entirely different problem really.
Given the assumption that you and three of your best friends wish to use
WWW to share information, how can you do so without exposing the page
to the ISP?

Today, as far as I know, if you wish to hide what you have on a page you
have to control the server.  If you wish to try and deter traffic analysis
you have to own the servers in front of the server.  Cumbersome,
expensive and still not entirely effective.

If instead you could prevent the owner of the server from reading the
stuff in the first place, while allowing it to be read at leasure by the
users...

It would also be much easier to construct remailer type proxies in that
each server in the chain would be denied the content of data passing
through.

What I am hoping can be done is to stretch the points in "point to point
encryption" out past the ISP.

Now, if your concern is exposure by a member you have given access to the
webpage, the discussion becomes an issue of certification, and signatures.
An important point, but something of an overkill where the ISP has full
access to your webpage whatever your passwords might be.

Create a page where the data is locally encrypted, and which only accepts
connections from valid certificates and you go a long way to being able to
communicate via WWW securely even over insecure channels.  You also free
up the method to those who don't have time, or cannot afford to run their
own WWW server.

If the location of your page is exposed, so what?  Spend the $11 a month
to open a page on another ISP.  In the "island on the net" example, you
have to reroute the entire deal.

In addition, you have now eliminated what must be the number 1 problem in
running an "iffy" page.  ISP intereference.  You have removed their
liability.  How were they supposed to know what it was you were doing?
They don't have the keys.

Now if you really wanted to be slick about it, you would use a form of
encryption to multiple users option and encrypt the page to the public
keys of individuals.  Sure, they could release the keys and spill the
beans, but they would be compromising their own keys in the process.
Mileage on this deterant will vary according to what they may have done
with the key beforehand, and it requires a multiple purpose to those keys
(as with PGP).