April 23, 2015 | Author: Mircea Popescu

I. Use javacript to

  1. Locally generate a (RSA) public-private keypair. Store both as base64 modulii in separate cookiesii.
  2. Decrypt all elements sent encrypted to the local privkey and inject them into the DOM.
  3. Encrypt all submitted elements (text and pictures) going out through POST requests. Keep state of the list of foreign keys to which material should be encrypted.

II. Use whatever you use to host a website interfacing with I. above. The website should at a minimum offer

  1. a plaintext meet and greet space,
  2. a means for users to sort and be sorted into groups,
  3. a means to readily update content once intended recipients change.

All binary resources (ie images, videos, whatever) should be proxied via single use URL (once a GET request is served for that URL, it is inactivated. All text resources should be injected in the DOM locally, after having been decrypted locally via js.

This arrangement is not particularly bandwidth intensive (at least in the case of text, encryption serves as de-facto compression) and not particularly CPU intensive (users do most of the heavy lifting locally, so you get to leverage the pooled CPU of the community). It is very much legally immune : the operator can never be served a supoena of any particular utility, seeing how the website database servers merely host encrypted material to which the operator does not hold the key.

Open for comments.

  1. See Hanewinkel's tool for this purpose - notice that he also has a javascript encryption implementation on the other page there. []
  2. Note that the hardening of the privkey bearing cookie is a very iffy problem - I sadly don't know enough about the whole webshitstack to specify this correctly. Please help. []
Category : Job Board  | 29 responses.