-
Notifications
You must be signed in to change notification settings - Fork 232
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
Bitswap auth #260
Labels
need/triage
Needs initial labeling and prioritization
Milestone
Comments
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'd like to propose an optional extension to bitswap for requiring authorisation to retrieve a block. We've already implemented this and integrated it in Peergos.
The proposal is to add optional auth byte[] to wants, blocks and block presence. Our updated protobuf is here -
https://github.com/Peergos/go-bitswap-auth/blob/master/message/pb/message.proto
The repo where we've implemented this is: https://github.com/peergos/go-bitswap-auth
Trying to directly upstream our code there probably doesn't make sense because of the changes we've made to some external interfaces, but if it does then we can consider relicensing it from AGPL in that situation.
We use this in Peergos (via ipfs-nucleus) to implement a post-quantum capability based auth scheme using S3 V4 signatures. You can read more about our design here: Peergos/Peergos#884 here: Peergos/Peergos#862 and here: https://peergos.org/posts/bats
On the bitswap level the motivation is the following: We wanted to add block level authorisation to retrieve each block. This means a different auth is required to be sent with each want request. In our usage the auth ended up being 89 bytes, but we haven't limited the size other than the pre-existing bitswap message size. When a block is returned you also need to return the auth string so the sender knows which want request was allowed in case of multiple concurrent want requests with different auth for the same cid. Similar reasoning applies to the BlockPresence message (we don't want to automatically expose the presence of a block).
In our usage the auth string is tied to the sender's peer ID so it doesn't matter that the auth string is being broadcast to the DHT. Clearly any other designs based on this will need the same property.
The text was updated successfully, but these errors were encountered: