Tuesday, 27 May 2014


We are each surrounded by information. This data is one way to store, catalogue and process all aspects of our lives. The miasma of data does not belong to us, but the parts that we want and need to store and access certainly can feel very personal. I don't share my pa$$word with anyone. If they have to have access they are issued with their own key.

For the past couple of years, in my spare time, I have been thinking about the most practical ways to store this data.

Then I met tiddlywiki. The moment that I saw how tiddlywiki could work with a server I saw one way to unify all of your personal data; securely store it in a distributed fashion and give others access. Even the configuration was going to simply be another piece of data within miasma, (or rather me-as-data.)

Each atom of information is a "ma" - deliberately still dividable, (literally into two separate letters, but metaphorically this means data systems can divide a piece of data into arbitrary blocks and encrypt and store them as efficiently as possible. (Even extract and re-encrypt if a better or more secure system is discovered.)

Using Shamir's Secret Sharing access can be granted, or revoked to the granularity required by the user.

I wanted the system to be able to store itself on multiple locations and have the flexibility to automatically merge distributed collections between locations and time, (credit to git-scm.)

So each ma of data has to have the option of being encrypted in one or more ways, depending upon the access of the recipient. For example, we can sign the data with one of our secret keys and encrypt the data with the public key of the recipient. For a transitory message, "shall we have pizza tonight?" that is not only over kill, it is disempowering. Communities may agree that certain individuals should have access to that piece of information. [0] Through meta-data mining a corporation could profit from sending your pizza vouchers or some other action, when clearly your message was not meant for public consumption. This is passive corporate abuse, (I'm working hard not to call it digital-rape.) Just because person A's perception of person B is interpreted as communicating one intention [1], it does NOT enter person B into any form of contract with person A and it does not entitle person A to use person B or to push them into having to respond. (Yes, I'm tired of spam, cold-calls and heckles.) There are too many people in the world for society to demand a "no" when a lack of response should equate to "leave me alone, I don't even want to burn through another second of my short existence receiving an apology from you." (Though large cash compensation is fine, as long as you don't imagine that you are purchasing anything. Think of giving money as a modern form of plenary indulgence.)

So as you can see - the moment that you move out of the field of math and into data you have to consider the wider social aspects, (and they are many and varied.)

The Practical

ref: http://cookieclicker.wikia.com/wiki/Cookie_Monster_%28JavaScript_Add-on%29#Using

I envisage a tiddlywiki style javascript overlay that can be loaded from any hosting site, ( github, pastebin, your local USB flashdrive) from a bookmark as an overlay to any, (and all, or just HTML5 Local Storage [2]) data storage, (webmail). That can leverage the remote site as a data storage system, (unsubscribed IMAP tree) to store the various pieces of data encrypted with a symetrical key, (AES) and re-encryptable on the fly, (decrypt -> encrypt{3DES} -> store) the moment that the existing key is compromised or the protocol falls to cryptoanalysis.

The system, (lets call is nuage) will also be able to share collections of data with individuals, (if it is an overlay to a webmail, then it can 7zip the data into an attachment and send it, and if they recipient has the same system, then it can process the message without user intervention.)

Most importantly the system will let you dump a backup to local disk as an encrypted archive, (either encrypted with a passphrase that you chose or with one that you never know that rests within the system's own meta-metadata and is shared to one of your nuage remote locations.)

Lastly - it has to be distributed. A copy can be forked onto or into any and all storage media and self merging. (Yes, that's going to be fun for someone.)

So each "ma" could take the form of


Though it is important that the meta data of ver(sion) cdate, adate, mdate, be optional and that the type of encryption be stated either at the start of the string, (thanks dovecot) or as a separate meta string "enc-type":"elgamal" with the option of the "key ID":"EE87B9F78EFC079FB0A4B4DE4AC889DAFA479164" (there will be times when linking a piece of data with a key will be damaging, so having the ability to leave the user to store that piece of information in their head is important. That said, I've found that addresses and especially passwords should have a data on them, so that the system can let me know which ones have not been changed for $update_pw_after_x_days.)

At other times you want to be able to identify a piece of data so:

(Obviously this would also have to reference the public key in question.)

There is a lot of room for expansion, and thankfully javascript has matured, (and more importantly the libraries now exist) to be able to implement this idea.

[0] police access to encryption keys
[1] "We are both here for the same thing!"
[2] due to the limits of locl storage, a progress bar must be available.

No comments:

Post a Comment

About this blog

Sort of a test blog... until it isn't