Comments (11)
^ Updated thinking in the issue description ... thoughts welcome!
from go-threads.
First question is check if I'm on the same page on what the code currently does when AddFollower
:
- Push all logs we know to the follower
- Adds the follower addr to our own log addr-book
- Push our own log info (which now has the new follower as an addr), to other peers log writers of the thread
Where Push
we mean sending log information, which currently contains all keys of the logs, addrs, and heads... not logic yet for only sending correct keys depending if sending things to followers or readers. Is this correct?
I feel I'm missing something. Since this is direct-talking with other peers, aren't channels assumed to be secure? Why do you need a shared key? (or maybe this is for external invites?).
from go-threads.
Yep, same page. The channels are secure but the crux here is ensuring that a follower can serve a thread (and all its logs and keys, including read keys) to new consumers without knowing the read key.
So, given a thread address like,
/ip4/x.x.x.x/tcp/4006/p2p/<peerID>/thread/<threadID>
Where the host is a follower, how can I get a hold of the read keys? The proposal above is to back-channel a key that was used to encrypt the log read keys in the address. Something like,
/ip4/x.x.x.x/tcp/4006/p2p/<peerID>/thread/<threadID>?key=xxx
Multiaddresses don't have query params like that but something to that effect. The client would parse out the key and NOT send it to the follower. It just uses it to decrypt the read keys on receipt.
from go-threads.
Oh, that's more clear now.
Some thoughts/questions/claims to check:
- So
/ip4/x.x.x.x/tcp/4006/p2p/<peerID>/thread/<threadID>?key=xxx
is sent over a secure-channel only between non-followers roles in the thread. Correct? - The
LogInfo
pushed to the follower would have the read key encrypted withkey
, correct? - If two-pair of peers do this protocol, they both would generate different
keys
since they never thought other keys before. How this fit with the concept of a unique key per thread? Is this uniqueness really necessary?
from go-threads.
So
/ip4/x.x.x.x/tcp/4006/p2p/<peerID>/thread/<threadID>?key=xxx
is sent over a secure-channel only between non-followers roles in the thread. Correct?
Yep. For example, in an email, text, slack, other thread, etc. This is analogous to sharing a link to a google doc: "anyone with the link can read and write".
The
LogInfo
pushed to the follower would have the read key encrypted withkey
, correct?
Yep.
If two-pair of peers do this protocol, they both would generate different
keys
since they never thought other keys before. How this fit with the concept of a unique key per thread? Is this uniqueness really necessary?
I was thinking that the key could be passed around and used if it's present, such that I could serve an address to your follower:
- Get or create a symmetric share key for the thread (you will have it if you or anyone else has already added a follower). Store the key in the metadata store because it's for the whole thread.
The key could be tied to the follower so that each follower has their own, but then a third peer that was already in the thread would not be able to pick up new logs from a follower since it wouldn't have the key used to encrypt its logs. Tricky to visualize without drawing it out. Ideally, all followers would host logs encrypted with the same key.
from go-threads.
Definitely sounds good that key can be shared as you mention.
But even if that's the intention, I think it can't be avoided that some two peers generate new key unintentionally. What I'm imagining this could happen:
- A thread with many peers with no existing followers for anyone. Two peers add new followers for them before receiving the other notice about a generated key. Result: two distinct _key_s exist, two different followers have encrypted data with different keys.
- A less pessimistic scenario can be a non-updated writer comes online again and, for some reason, doesn't receive the push of a prior writer generated key. So, adding a follower would generate a new key.
To be clear, I think is optimal to re-use key if one is known. But I think this multiple keys situation can't be avoided, and not really clear about how to handle it... since readers should have a way to realize if the key they're assuming to be true for decryption is the correct one. (I can imagine solutions, but that'd add some extra metadata (e.g: hash of the key or something similar)).
from go-threads.
The key could be created when the thread is created, and then always shared with the address when adding new peers. In a sense, this would be like using a keypair for the thread (like the logs), where peers all have the private key and followers only have the public key except we have the benefit of better encryption and shorter keys (no need for signing).
from go-threads.
Ah, I was thinking that the ?key=
part was created the first time a follower was invited in the thread. So, the way yo mention avoids what I described.
This means that it exists a shared key for all log writers.
Maybe stupid question: if non-follower roles should have read-access to all the thread logs, and now non-follower roles have a shared key: why this key isn't the actual read key of all logs? (and lower key management complexity?)
from go-threads.
Right, I was thinking above that the key would be created dynamically, but then you got me thinking.
As for the single read key, that's a good question. Couple thoughts:
- It's still an open question whether or not a log should be able to be used in multiple threads
- Have log-based read keys might make key rotation easier (for blocking a peer)
from go-threads.
* It's still an open question whether or not a log should be able to be used in multiple threads
Maybe the safe bet is to keep them separate (key and read key) to avoid handcuffs and leave it flexible.
* Have log-based read keys might make key rotation easier (for blocking a peer)
Now that you mention that. In that case the key should also be changed? (to avoid blocked peer to decrypt again the rotated key) Or can we assume all followers know that that peer was blocked to ignore requests?
from go-threads.
As per much Slack chatting, closing this in favor of just using the same read and follow keys for all logs.
from go-threads.
Related Issues (20)
- How to make sure open the same DB on different threadsd node?
- Collection with name collection can't be properly indexed HOT 4
- AddThread without creating a log HOT 2
- Make sure net/api/client.Subscribe loop ends gracefully when client is closing HOT 3
- Calling net.Record.PrevID() crashes when the client is closing HOT 2
- --- FAIL: TestModifiedSince (0.00s) HOT 1
- Don't allow setting arbitrary PrevID for records HOT 3
- Lost records from the Subscribe() channel when records arrive concurrently HOT 1
- Found an interesting bug related to synchronisation of threads HOT 10
- feat: New API or method to `getRecords` _back_ from offset to limit
- Occasional CI timing out
- ReadFilter not working
- Proposal for go-threads improvements HOT 1
- Your Paper has a wrong definition of the CID in ipfs HOT 6
- ThreadDB Sharding and Replication? HOT 3
- DB API: Count only query option
- rpc error: code = Unknown desc = log already exists HOT 3
- How well does it scale? HOT 1
- Future of this project HOT 1
- General Question on ThreadDB functionality HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-threads.