Implement Proof Of Possession capability for all public key crypto types #6010
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Derive ProofOfPossession for all pubkey crypto type beside BLS.
|
We added backcerts of operator keys alraedy, no? Or was that an RFC but not yet implemented? We could use backcerts for proof-of-possession. Ideally, we should place system randomness into those backcerts and place them on-chain, but this requires tweaking ed25519 I guess. |
Contributor
Author
|
@burdges Could you point to the backcerts PR or its RFC so I can take a look? Thank you. |
|
It's seemingly just ownership proofs, but really they should sign the operators key, making them backcerts. I proposed having some master session key too, but that's a bigger change. We could simply back certify both the operators' key and some piece of system randomness sampled at node startup. |
Member
|
@drskalman, as we discussed, I believe that, along with the code (and prior to merging this PR), an amendment to the aforementioned RFC should be proposed and integrated. |
|
It's offten that backcerts get forgotten because we do not see them in TLS since the handshake itself represents the backcert, meaning the site itself sent you their certificate in the authenticated channel, so they approved that certificate. If we lack them in polkadot, then an adversary could pull tricks like claiming someone else's grandpa key was their grandpa key, maybe some unelected node, and then ignore grandpa themselves. We've no idea what bugs exist in substrate under such scenarios, but even if we handle them gracefully they still cause problems elsewhere. |
- Change PoP type to be &[u8] instead of signature so it works for BLS12.
enforcing conetxt
….com:w3f/polkadot-sdk into skalman--proof-of-possession-for-all-cryptos
bkchr
approved these changes
May 20, 2025
Member
|
/cmd fmt |
Contributor
|
Command "fmt" has failed ❌! See logs here |
auto-merge was automatically disabled
May 21, 2025 14:50
Head branch was pushed to by a user without write access
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Merged
via the queue into
paritytech:master
with commit May 28, 2025
b4b7439
180 of 181 checks passed
pgherveou
pushed a commit
that referenced
this pull request
Jun 11, 2025
…pes (#6010) - Implement `ProofOfPossession` traits with default implementation. - Implement their derive macro in a new proc-macro crate in `pubkeycrypto` create which eventually should contains all pubkey crypto scheme as recommended by #1975 - Derive ProofOfPossession for all pubkey crypto type beside BLS. - [x] Implement Nugget BLS proof of possession which should certifies that the unique secret key known to the prover is used to generate both public keys in G1 and G2. - [x] Implement sign Host function for BLS12-381 necessary to be able to generate proof of possion through runtime. - [x] Implement generation and verification of proof of possession functions in all RuntimeApp and RuntimeAppPublic s. --------- Co-authored-by: Andrew Burger <[email protected]> Co-authored-by: Davide Galassi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 20, 2025
# Description Adds a few crate bumps associated to PRs which missed to bump them, and updates parity-publish version across the board to 0.10.6 (to support rustc 1.88). Additionally, makes it so that parity-publish-check-compile runs first on all unreleased prdocs to bump associated crates, and only after moving those to an `unreleased` directory, runs on the current PR's prdoc. This is so that we first create a "local release" based on the unreleased prdocs, and then we follow with a "patch" release based on the previous local release, considering only the prdoc pushed with the current PR. If the workflow fails at the end it means current PR missed certain bumps. If we don't do the plan/apply twice we risk to miss bumps due to all prdocs being considered (current PR's prdoc + unreleased ones) when running parity-publish plan/apply, which might result in a set of crate bumps which are sufficient, but once some unreleased prdocs will be moved to a stable prodoc directory, because they will be part of a stable release, then the ones left will not be enough from a bump perspective (e.g. like it happened in #9320). That's why it is important to check every PR that adds a prdoc whether it is self-sufficient from a crates bumping perspective. If no prdoc is provided, the parity-publish does not need to be taken into consideration, but it should also pass nonetheless. ## Integration N/A ## Review Notes There seems to a be a corner case parity-publish can not easily catch. All bumps below are a manifestation of it. More details below: * #8714 - a major bump is necessary for `sp-wasm-interface` - context here: #8714 (comment) * `sp-keystore` was bumped during 2506 in #6010 , and the relevant prdoc got moved to stable2506 dir in #9320. This moved prdoc coexisted alongside other unreleased prdocs, and covered a needed patch bump for `sp-keystore`, that is not easily visible, and also required for crates publishing IIUC: 1. `sp-io` is major bumped because its direct dependency, `sp-state-machine`, was major bumped. 2. `sp-io` has a direct dependency on `sp-core` (minor bumped), and `sp-keystore` (not touched, not bumped by now) 3. `sp-io` fails to compile because it pulls same types from different `sp-core` versions (it implements `Keystore` trait from `sp-keystore` with methods signatures referencing types from `sp-core 38.0.0` by using the `sp-core 0.38.1` - unreleased yet - types, which confuses rustc). * `sp-rpc` needs a bump too due to pulling `sp-core 38.0.0`, like `sp-keystore`, and it is an indirect dependency of `polkadot-cli`, which has also a direct dependency on unreleased `sp-core 38.1.0`, so again, if we don't bump `sp-rpc` (historically it has been bumped only with major, but I think we can go with patch on this one), `polkadot-cli` can't compile. * `sc-storage-monitor` is in a similar situation as `sp-rpc`/`sp-keystore` - `polkadot-cli` depends on `sc-storage-monitor` (which is not bumped, and has a dependency on `sp-core 38.0.0`), but it also depends on `sp-core 38.1.0`. And yet again, something is used in `polkadot-cli` from the two different `sp-core` versions, which confuses rustc. --------- Signed-off-by: Iulian Barbu <[email protected]> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Alexander Samusev <[email protected]>
pepoviola
pushed a commit
that referenced
this pull request
Aug 26, 2025
# Description Adds a few crate bumps associated to PRs which missed to bump them, and updates parity-publish version across the board to 0.10.6 (to support rustc 1.88). Additionally, makes it so that parity-publish-check-compile runs first on all unreleased prdocs to bump associated crates, and only after moving those to an `unreleased` directory, runs on the current PR's prdoc. This is so that we first create a "local release" based on the unreleased prdocs, and then we follow with a "patch" release based on the previous local release, considering only the prdoc pushed with the current PR. If the workflow fails at the end it means current PR missed certain bumps. If we don't do the plan/apply twice we risk to miss bumps due to all prdocs being considered (current PR's prdoc + unreleased ones) when running parity-publish plan/apply, which might result in a set of crate bumps which are sufficient, but once some unreleased prdocs will be moved to a stable prodoc directory, because they will be part of a stable release, then the ones left will not be enough from a bump perspective (e.g. like it happened in #9320). That's why it is important to check every PR that adds a prdoc whether it is self-sufficient from a crates bumping perspective. If no prdoc is provided, the parity-publish does not need to be taken into consideration, but it should also pass nonetheless. ## Integration N/A ## Review Notes There seems to a be a corner case parity-publish can not easily catch. All bumps below are a manifestation of it. More details below: * #8714 - a major bump is necessary for `sp-wasm-interface` - context here: #8714 (comment) * `sp-keystore` was bumped during 2506 in #6010 , and the relevant prdoc got moved to stable2506 dir in #9320. This moved prdoc coexisted alongside other unreleased prdocs, and covered a needed patch bump for `sp-keystore`, that is not easily visible, and also required for crates publishing IIUC: 1. `sp-io` is major bumped because its direct dependency, `sp-state-machine`, was major bumped. 2. `sp-io` has a direct dependency on `sp-core` (minor bumped), and `sp-keystore` (not touched, not bumped by now) 3. `sp-io` fails to compile because it pulls same types from different `sp-core` versions (it implements `Keystore` trait from `sp-keystore` with methods signatures referencing types from `sp-core 38.0.0` by using the `sp-core 0.38.1` - unreleased yet - types, which confuses rustc). * `sp-rpc` needs a bump too due to pulling `sp-core 38.0.0`, like `sp-keystore`, and it is an indirect dependency of `polkadot-cli`, which has also a direct dependency on unreleased `sp-core 38.1.0`, so again, if we don't bump `sp-rpc` (historically it has been bumped only with major, but I think we can go with patch on this one), `polkadot-cli` can't compile. * `sc-storage-monitor` is in a similar situation as `sp-rpc`/`sp-keystore` - `polkadot-cli` depends on `sc-storage-monitor` (which is not bumped, and has a dependency on `sp-core 38.0.0`), but it also depends on `sp-core 38.1.0`. And yet again, something is used in `polkadot-cli` from the two different `sp-core` versions, which confuses rustc. --------- Signed-off-by: Iulian Barbu <[email protected]> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Alexander Samusev <[email protected]>
alvicsam
pushed a commit
that referenced
this pull request
Oct 17, 2025
…pes (#6010) - Implement `ProofOfPossession` traits with default implementation. - Implement their derive macro in a new proc-macro crate in `pubkeycrypto` create which eventually should contains all pubkey crypto scheme as recommended by #1975 - Derive ProofOfPossession for all pubkey crypto type beside BLS. - [x] Implement Nugget BLS proof of possession which should certifies that the unique secret key known to the prover is used to generate both public keys in G1 and G2. - [x] Implement sign Host function for BLS12-381 necessary to be able to generate proof of possion through runtime. - [x] Implement generation and verification of proof of possession functions in all RuntimeApp and RuntimeAppPublic s. --------- Co-authored-by: Andrew Burger <[email protected]> Co-authored-by: Davide Galassi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
alvicsam
added a commit
that referenced
this pull request
Oct 17, 2025
# Description Adds a few crate bumps associated to PRs which missed to bump them, and updates parity-publish version across the board to 0.10.6 (to support rustc 1.88). Additionally, makes it so that parity-publish-check-compile runs first on all unreleased prdocs to bump associated crates, and only after moving those to an `unreleased` directory, runs on the current PR's prdoc. This is so that we first create a "local release" based on the unreleased prdocs, and then we follow with a "patch" release based on the previous local release, considering only the prdoc pushed with the current PR. If the workflow fails at the end it means current PR missed certain bumps. If we don't do the plan/apply twice we risk to miss bumps due to all prdocs being considered (current PR's prdoc + unreleased ones) when running parity-publish plan/apply, which might result in a set of crate bumps which are sufficient, but once some unreleased prdocs will be moved to a stable prodoc directory, because they will be part of a stable release, then the ones left will not be enough from a bump perspective (e.g. like it happened in #9320). That's why it is important to check every PR that adds a prdoc whether it is self-sufficient from a crates bumping perspective. If no prdoc is provided, the parity-publish does not need to be taken into consideration, but it should also pass nonetheless. ## Integration N/A ## Review Notes There seems to a be a corner case parity-publish can not easily catch. All bumps below are a manifestation of it. More details below: * #8714 - a major bump is necessary for `sp-wasm-interface` - context here: #8714 (comment) * `sp-keystore` was bumped during 2506 in #6010 , and the relevant prdoc got moved to stable2506 dir in #9320. This moved prdoc coexisted alongside other unreleased prdocs, and covered a needed patch bump for `sp-keystore`, that is not easily visible, and also required for crates publishing IIUC: 1. `sp-io` is major bumped because its direct dependency, `sp-state-machine`, was major bumped. 2. `sp-io` has a direct dependency on `sp-core` (minor bumped), and `sp-keystore` (not touched, not bumped by now) 3. `sp-io` fails to compile because it pulls same types from different `sp-core` versions (it implements `Keystore` trait from `sp-keystore` with methods signatures referencing types from `sp-core 38.0.0` by using the `sp-core 0.38.1` - unreleased yet - types, which confuses rustc). * `sp-rpc` needs a bump too due to pulling `sp-core 38.0.0`, like `sp-keystore`, and it is an indirect dependency of `polkadot-cli`, which has also a direct dependency on unreleased `sp-core 38.1.0`, so again, if we don't bump `sp-rpc` (historically it has been bumped only with major, but I think we can go with patch on this one), `polkadot-cli` can't compile. * `sc-storage-monitor` is in a similar situation as `sp-rpc`/`sp-keystore` - `polkadot-cli` depends on `sc-storage-monitor` (which is not bumped, and has a dependency on `sp-core 38.0.0`), but it also depends on `sp-core 38.1.0`. And yet again, something is used in `polkadot-cli` from the two different `sp-core` versions, which confuses rustc. --------- Signed-off-by: Iulian Barbu <[email protected]> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Alexander Samusev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement
ProofOfPossessiontraits with default implementation.Implement their derive macro in a new proc-macro crate in
pubkeycryptocreate which eventually should contains all pubkey crypto scheme as recommended by Move crypto implementations out of sp-core #1975Derive ProofOfPossession for all pubkey crypto type beside BLS.
Implement Nugget BLS proof of possession which should certifies that the unique secret key known to the prover is used to generate both public keys in G1 and G2.
Implement sign Host function for BLS12-381 necessary to be able to generate proof of possion through runtime.
Implement generation and verification of proof of possession functions in all RuntimeApp and RuntimeAppPublic s.