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

Bitswap auth #260

Open
ianopolous opened this issue Jan 5, 2022 · 0 comments · May be fixed by #270
Open

Bitswap auth #260

ianopolous opened this issue Jan 5, 2022 · 0 comments · May be fixed by #270
Labels
need/triage Needs initial labeling and prioritization
Milestone

Comments

@ianopolous
Copy link
Member

ianopolous commented Jan 5, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
No open projects
Status: 🔎 In Review
Development

Successfully merging a pull request may close this issue.

2 participants