[Cryptography] End to End encrypted Web

Phillip Hallam-Baker phill at hallambaker.com
Wed Nov 30 10:40:38 EST 2016


The code isn't complete yet, but I thought I would share my work on
building an end-to-end encrypted Web server and comment blog. I am calling
this Mesh/Web. I am also calling proxy re-encryption recryption as it is
shorter and less confusing when there is a Web proxy involved.

Here is the setup:

* All the files that make up the  and comment forum are hosted on Carol's
content delivery network. Neither Carol nor any of her employees has any
access to the plaintext of the content or comments.

* Carol's CDN is entirely stock. The only thing that is at all different is
that the content type returned is application/remesh

* Alice, is the group administrator. She holds the encryption keypair for
the site. When she adds users to the reading group, she cuts a recryption
key and a decryption key for the new user and creates a recryption access
entry (RAE) for that user.

* The RAE is encrypted under the public key of a recryption server chosen
by Alice. This is an online server that performs one half of the
decryption, allowing the other party to complete it.

The users access the site through one of

* A standard Web browser connecting through a proxy that performs
conversion of the application/remesh content to unencrypted content.

* A standard Web browser with a plug-in

* A standard Web browser that supports the new scheme.

* A separate Web browser that supports the new scheme that is limited to
only access sites of the new type. This might be bound via trusted hardware
in some form.


This scheme allows anyone to read the encrypted material if Alice grants
access. Alice can withdraw that access at any time provided that the
recryption service refuses future requests from the blocked user. It is
obviously not possible to retroactively block content the user has already
read. Future access will be cut off completely after rekeying occurs.


#Complications

The system presented is end-to-end secure. The main problem being that Web
endpoints are notoriously squishy. In particular we have to cope with the
abomination that is JavaScript.

One very simple solution is to require all active content to be signed by a
key that is endorsed by Alice. This is quite practical as the
application/remesh content type can have signature capability.

Web sites are interactive. How can a site be interactive if the server
can't understand the content? It isn't difficult. The application/remesh
content type could support a 'log mode' in which the file contains a list
of comments. The site knows what node the user has commented on but not
what the node says or what the comment was.

Of course we can add further privacy enhancements but the core concept here
is that what is stored in the cloud need not risk confidentiality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161130/076f22e0/attachment.html>


More information about the cryptography mailing list