Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for javascript-based encryption #4

Open
miguelfreitas opened this issue Dec 30, 2013 · 5 comments
Open

Implement support for javascript-based encryption #4

miguelfreitas opened this issue Dec 30, 2013 · 5 comments

Comments

@miguelfreitas
Copy link
Owner

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

  • the local user concept would need to be changed: instead of holding privkey it would be a mere collection of torrents to follow.
  • password protection to local user would just protect updating the list of torrents (following).
  • sendnewusertransaction may receive an additional pubkey parameter so the POW may be still implemented in C++ but without requiring wallet's data.
  • getposts already supports "allowed flags=2" parameter which may be used to download encrypted dms. perhaps another "required flags" parameters would be useful for filtering only this type.
  • newpostmsg/newdirectmsg/newrtmsg will need counterparts to receive the signed content.
@genjix
Copy link

genjix commented Jan 16, 2014

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
Copy link
Contributor

iShift commented Jan 16, 2014

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

@Tschaul
Copy link

Tschaul commented Jan 26, 2014

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
Copy link
Owner Author

@Tschaul good idea! (server challenge replaces password)

@Tschaul
Copy link

Tschaul commented Jan 27, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants