-
Notifications
You must be signed in to change notification settings - Fork 11.7k
[Bridge Node] Introduce new onchain authentication key #19351
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
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
849eb43
to
03cb609
Compare
let registration = CommitteeMemberRegistration { | ||
sui_address: sender, | ||
bridge_pubkey_bytes, | ||
bridge_network_pubkey_bytes, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: you are accepting a public key here, but not checking whether the party that registers it has in fact the secret key associated with it. This for example lets me register with your key. Is this a problem to you? (I do not think so, but worth checking + documenting).
Also: is there a doc about how we will be using this key to then authenticate at a network level?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that's ok, as I don't see any utility for an attacker to register with someone else's pubkey:
- We check that there is no key duplication within the committee, so you won't be able to impersonate an active member.
- If you add an arbitrary pubkey (one that doesn't exist), you just footgun yourself, since your requests will not have the elevated trust assumptions that this could provide.
re: doc - I do not, but I can work on one. There is a long discussion thread externally, with lots of thoughts and opinions, and 3 proposed schemes. All of them would involve introducing a new key. I will try and organize them into a doc today.
abort ESenderIsNotInBridgeCommittee | ||
} | ||
|
||
public(package) fun update_bridge_network_pubkey( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we allow validator to update the network pub key after registration? we will need to expose this function in bridge.move if we want to support that.
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
Description
Introducing new onchain ECDSA key to be used for client authentication schemes. Can provide more details on demand
Test plan
Included tests
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.