miguelfreitas / twister-core

twister core / daemon
MIT License
1.42k stars 252 forks source link

Implement support for javascript-based encryption #4

Open miguelfreitas opened 10 years ago

miguelfreitas commented 10 years ago

Thoughts about what needs to be done to create a privatekey-less twister server for a full JS client with encryption.

genjix commented 10 years ago

Fantastic, I've been interested in this too. So far just studying how Twister works.

1) For the local user: so nodes would have the concept of users still, which would be a list of usernames to call startTorrentUser() on? And then the user could query the data for those names through the classic interface.

2) Followers: can they not be signed by your key client side?

3) If you're going to have a server doing POW, then it should only do one nickname at a time with a queue for nickname registrations. However I see this as an attack: I could easily fill up the queue with my nickname registrations dropping other people. Would be better (long-term) if a separate tool (maybe also another service communicating with twisterd) handles doing the POW.

4 & 5) sounds good

iShift commented 10 years ago

you mean you want to rewrite twister to full js? and how you want to get rid of private keys ?

Tschaul commented 10 years ago

The server could challenge the client for the private key for authentication before updating the followings.

Or the followings are simply not stored on the server but on the client and anyone could request any feed/torrent from any node. That way you could be connected to multiple servers. One of which is your outgoing server which you use to post/send messages. The other one(s) you would use to track your feeds/torrents. The second server would not have to know who you are. So your followings would be secret if you want.

miguelfreitas commented 10 years ago

@Tschaul good idea! (server challenge replaces password)

Tschaul commented 10 years ago

We could do the following:

The server publishes a nonce (random number used only once) which it updates say once a day. Clients could query the nonce without authentication. Then the valid password could be derived by the user simply as privkey(nonce) and checked for validity by the server. The advantage is that the server does not have to send an request to the client.