[TW5] TWederation and SJCL.js for public key crytpography

67 views
Skip to first unread message

Jed Carty

unread,
Feb 19, 2016, 5:09:45 AM2/19/16
to TiddlyWikiDev
As part of twederation I would like to be able to have some sort of access control to wiki contents. I am still thinking about how to do this and I hope that someone here has some experience with these things and can at least tell me if this would be possible. Any thoughts or suggestions on this or alternate implementations are always welcome.

My current not very developed idea:
In a trustless environment without persistent storage for a reader (ie a publicly hosted tiddlywiki being read by someone without write access) some sort of cryptography is the only real way to selectively make parts of the wiki accessible. Tiddlywiki already has sjcl.js as part of the core and my brief skimming of the documentation suggests that we can use elliptic curve cryptography. For the twederation experiments me and Mat have been working on part of connecting two wikis involves exchanging twCards which could easily contain a public key for private communication. So if I wanted to send a message to Mat that no one else could read I could just use his public key.

The biggest problem I see is local private key storage. This wouldn't be a huge problem if you are using a single computer all the time and have a password manager, but if you are using multiple devices there will probably be some usability concerns. I have read a tiny bit about processes for taking a password and generating a private key from it, but I am not sure how much they would apply in this context since everything about how the password is converted to the private key would be on the wiki and therefore assumed to be publicly viewable. I don't know specifics of how this works so at the moment it is just brainstorming.

I know that from a strict security perspective this would be difficult to make secure, but for the current purposes of twederation I don't think we need an actually secure setup, just enough that it would take real effort to break the encryption. Hopefully we would be able to make it secure, but that isn't a high priority for me at the moment.

My idea for how to encrypt a single message for multiple recipients would be to define groups of people and send everyone in the group the same key (in this case probably a symmetric key for simplicity) in a message encrypted using their public key. Then each person could decrypt the message and have access to this key which you could reuse to send to the entire group and have everyone able to decrypt the message without requiring individual things saved on your wiki for each message.

Someone would also have to create a widget that would decrypt the and display the messages in a way that doesn't affect the tiddler store so that the decrypted versions wouldn't be saved accidentally after viewing. I don't think that this would be too difficult, but depending on how much processing is required it may slow down the wiki.


NB: Almost all of the complaints I have seen about js-based encryption are based on client-server models and communicating keys. I am currently considering only the html wiki in the browser which avoids that problem completely. This doesn't mean that there aren't concerns but the generic 'javascript cryptography is bad' arguments may not be relevant to this situation.

It doesn't look like the ecc part of sjcl.js is included in the tiddlywiki core but since it is so small when minified it could probably be included as a plugin without problems.

PMario

unread,
Feb 19, 2016, 9:28:44 AM2/19/16
to TiddlyWikiDev
Hi Jed,

I think you are mixing 2 things here:

1) Your title says: "[TW5] TWederation and SJCL.js for public key crytpography"
2) TW uses a Password encryption at the moment.

You can't really use the existing (2) mechanism if you don't want to use an external key store, because it leads to your conclusion:

I have read a tiny bit about processes for taking a password and generating a private key from it, but I am not sure how much they would apply in this context since everything about how the password is converted to the private key would be on the wiki and therefore assumed to be publicly viewable. I don't know specifics of how this works so at the moment it is just brainstorming.

This means no encryption at all. So that's not the way :)

------------

add 1) Your title says: "[TW5] TWederation and SJCL.js for public key crytpography"

So you are talking about PGP like encryption, that uses a private and public key pair. Which immediately brings the "key management problem" with it, as you point out.

So one "hypothetical" but really bad solution would be to store the public and the private key in the TW, but encrypt the private key with a password.

So the one with the password can create the "private key" and use it to decrypt the tiddler. ->  This mechanism has the exact same result as the password method. ... So it's pretty much useless to increase security. It just makes everything more complicated.



add 2) TW uses a Password encryption at the moment. Which does this:

 - If you want to encrypt the tiddler store you "enter a password"
 - This password is made stronger, using some "salt" and many iterations. see: [1-5]
    - a key is created, that is used to encrypt the message (tiddlers). Described here [5] and [4]
    - This process creates the same key on every computer, -> if you know the password. [2]
    - The salt value and the number of iterations are there, to make several attacks against the password harder [5]
    - The default values used, imo are not changed by TW since [1] says they are sensible. Look at wikipedia [5] about this.


I think, we need a different discussion first.
... more replies to follow

have fun!
mario

[1] http://bitwiseshiftleft.github.io/sjcl/ paragraph 4 about PBKDF2
[2] https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L600
[3] http://bitwiseshiftleft.github.io/sjcl/doc/symbols/sjcl.html
[4] http://bitwiseshiftleft.github.io/sjcl/doc/symbols/src/core_convenience.js.html
[5] https://en.wikipedia.org/wiki/PBKDF2


PMario

unread,
Feb 19, 2016, 11:09:58 AM2/19/16
to TiddlyWikiDev
I think the workflow is key here. .. But let me think a bit more.
-m
Reply all
Reply to author
Forward
0 new messages