From d0ff8c8ef692b274178b48e15a5488139bd95aa8 Mon Sep 17 00:00:00 2001 From: Skalman Date: Wed, 28 May 2025 10:13:38 -0400 Subject: [PATCH 1/2] unedit version of PoP RFC --- ...ove-the-security-of-proof-of-possession.md | 98 +++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 text/xxxx-improve-the-security-of-proof-of-possession.md diff --git a/text/xxxx-improve-the-security-of-proof-of-possession.md b/text/xxxx-improve-the-security-of-proof-of-possession.md new file mode 100644 index 000000000..b3d6aefcb --- /dev/null +++ b/text/xxxx-improve-the-security-of-proof-of-possession.md @@ -0,0 +1,98 @@ +# RFC-XXXX: Adding customized mandatory context to proof of possession statement + +| | | +|-----------------|-------------------------------------------------------------------------------------------------| +| **Start Date** | 20 May 2025 2025 | +| **Description** | Change `SessionKeys` runtime api to generate an customized ownership proof for each crypto type | +| **Authors** | Andrew Berger - Syed Hosseini | + +## Summary + +This RFC is an amendment to RFC-0048. It proposes to change the `OpaqueKeysInner:create_ownership_proof` and `OpaqueKeys:: ownership_proof_is_valid` +to invoke generation and validation procedure specific to each crypto time. This enable different crypto scheme implement +the proof of possession fitted to their security need. In short, this RFC delegates the procedure of generating and validating proof of possession to the crypto scheme. + + +## Motivation + +Following RFC-0048, All submitted key accompany a signature of `account_id` by the same key proving that the submitter knows the private key corresponding to the submitted key. However, a scheme might need to mandate a context for generating proof of possession and a different context for signing anything else to prevent rogue key attack. While this is critical for scheme with aggregatable public key, the other (non-aggregatable) crypto scheme opt for backward compatiblity and accept signatures not prepended with mandatory context. + +Current RFC, however does not allow for using different api and procedure for generating proof of possession for different crypto scheme. + +After this RFC, the procedure for generating and verifying proof of possession would be in discretion of the crypto scheme themselves not deterministically tied to the way they sign other messages. + +## Stakeholders + +- Polkadot runtime implementors +- Polkadot node implementors +- Validator operators + +## Explanation + +The RFC does not change the structure introduced by RFC-0048. The proof is a sequences of +signatures: +```rust +type Proof = (Signature, Signature, ..); +``` + +However to generate each signature are generated by the crypto scehem instead of being each private session key signing the `account_id`. +By default, the following statement signed by the crypto scheme is: + +``` +rust +"POP_"|account_id +``` +However, new crypto scheme could specify different structure for their proof of possession. + +Because RFC-0048 has not been deployed, the version of the `SessionKeys` could be set to `1` as requested by RFC-0048. + +## Drawbacks + +Crypto scheme needs to implement a `generate_proof_of_possession` and `verify_proof_of_possession` in addition to old capabilities (`sigen`, `verify`, etc). + +## Testing, Security, and Privacy + +The proof of possession for current crypto schemes is virtually the same as the one defined in RFC-0048. On the other hand the changes proposed by this RFC, allows the generation secure proof of possession for BLS keys. + +## Performance, Ergonomics, and Compatibility + +### Performance + +The performance is the same as the one discussed in RFC-0048. + +### Ergonomics + +Separating generation of proof of possession from signing, it allows more freedom to crypto scheme to implement proof of possession fitted to their need. + +### Compatibility + +The significant difference, is that proof of possession suggested by RFC-0048 is signed: + +``` +rust +account_id +``` + +vs current proposal suggests to change the statement to: +``` +rust +"POP_"|account_id +``` + +for the current crypto scheme. However, future crypto scheme such as BLS which are not bound to backward compatibility could produce more sophisticated proof of possession. + +## Prior Art and References + +This is a minor amendment to RFC-0048. + +## Unresolved Questions + +None. + +## Future Directions and Related Material + +Substrate implementation of the generation of proof of possession for all crypto scheme (current and the experimental ones) is implemented in [Pull 6010](https://github.com/paritytech/polkadot-sdk/pull/6010). + +Substrate implementation of [RFC-0048](https://github.com/paritytech/polkadot-sdk/pull/1739). + +Implementation of `OpaqueKeysInner:create_ownership_proof` and `OpaqueKeys:: ownership_proof_is_valid` should call `generate_proof_of_possion` and `verify_proof_of_possession` runtime APIs rather directly calling sign. From 3acd0f5966824a93ecca9ff24f9875542e6f4f4b Mon Sep 17 00:00:00 2001 From: Skalman Date: Wed, 28 May 2025 10:14:35 -0400 Subject: [PATCH 2/2] Edited PoP RFC --- ...ove-the-security-of-proof-of-possession.md | 61 +++++++++---------- 1 file changed, 29 insertions(+), 32 deletions(-) diff --git a/text/xxxx-improve-the-security-of-proof-of-possession.md b/text/xxxx-improve-the-security-of-proof-of-possession.md index b3d6aefcb..e12d5ddaf 100644 --- a/text/xxxx-improve-the-security-of-proof-of-possession.md +++ b/text/xxxx-improve-the-security-of-proof-of-possession.md @@ -1,58 +1,54 @@ # RFC-XXXX: Adding customized mandatory context to proof of possession statement -| | | -|-----------------|-------------------------------------------------------------------------------------------------| -| **Start Date** | 20 May 2025 2025 | -| **Description** | Change `SessionKeys` runtime api to generate an customized ownership proof for each crypto type | -| **Authors** | Andrew Berger - Syed Hosseini | +| | | +|--|--| +| **Start Date** | 20 May 2025 2025 | +| **Description** | Change `SessionKeys` runtime API to generate a customized ownership proof for each crypto type | +| **Authors** | Andrew Berger - Syed Hosseini | ## Summary -This RFC is an amendment to RFC-0048. It proposes to change the `OpaqueKeysInner:create_ownership_proof` and `OpaqueKeys:: ownership_proof_is_valid` -to invoke generation and validation procedure specific to each crypto time. This enable different crypto scheme implement -the proof of possession fitted to their security need. In short, this RFC delegates the procedure of generating and validating proof of possession to the crypto scheme. - +This RFC is an amendment to RFC-0048. It proposes changing the OpaqueKeysInner:create_ownership_proof and OpaqueKeys:: ownership_proof_is_valid to invoke generation and validation procedures specific to each crypto type. This enables different crypto schemes to implement proof of possession that fits their security needs. In short, this RFC delegates the procedure of generating and validating proof of possession to the crypto schemes rather than dictating a uniform generation and verification. ## Motivation -Following RFC-0048, All submitted key accompany a signature of `account_id` by the same key proving that the submitter knows the private key corresponding to the submitted key. However, a scheme might need to mandate a context for generating proof of possession and a different context for signing anything else to prevent rogue key attack. While this is critical for scheme with aggregatable public key, the other (non-aggregatable) crypto scheme opt for backward compatiblity and accept signatures not prepended with mandatory context. - -Current RFC, however does not allow for using different api and procedure for generating proof of possession for different crypto scheme. +Following RFC-0048, all submitted keys accompany a signature of the account_id by the same key, proving that the submitter knows the private key corresponding to the submitted key. However, a scheme should mandate a context-specific approach for generating proof of possession and a different context for signing anything else to prevent rogue key attacks \[3\]. While this is critical for schemes with aggregatable public keys, the other (non-aggregatable) crypto schemes opt for backward compatibility and accept signatures not prepended with mandatory context. -After this RFC, the procedure for generating and verifying proof of possession would be in discretion of the crypto scheme themselves not deterministically tied to the way they sign other messages. + +However, the current RFC does not allow using different API calls and procedures to generate proof of possession for different crypto schemes. -## Stakeholders +After this RFC, the procedure for generating and verifying proof of possession would be at the discretion of the crypto scheme itself, not deterministically tied to the way they sign other messages. Stakeholders -- Polkadot runtime implementors -- Polkadot node implementors -- Validator operators +* Polkadot runtime implementors +* Polkadot node implementors +* Validator operators ## Explanation -The RFC does not change the structure introduced by RFC-0048. The proof is a sequences of -signatures: +The RFC does not change the structure introduced by RFC-0048. The proof is a sequence of signatures: + ```rust type Proof = (Signature, Signature, ..); ``` -However to generate each signature are generated by the crypto scehem instead of being each private session key signing the `account_id`. -By default, the following statement signed by the crypto scheme is: +However, each signature is generated by the crypto scheme instead of each private session key signing the `account_id`. By default, the following statement is signed by the crypto scheme: ``` rust "POP_"|account_id ``` -However, new crypto scheme could specify different structure for their proof of possession. -Because RFC-0048 has not been deployed, the version of the `SessionKeys` could be set to `1` as requested by RFC-0048. +The prefix could alert signers if they are misled into signing false proof of possession statements. More importantly, a new crypto scheme could specify a different structure for its proof of possession. + +Because RFC-0048 has not been deployed, the version of the `SessionKeys` could still be set to `1` as requested by RFC-0048. ## Drawbacks -Crypto scheme needs to implement a `generate_proof_of_possession` and `verify_proof_of_possession` in addition to old capabilities (`sigen`, `verify`, etc). +Crypto scheme needs to implement an explicit `generate_proof_of_possession` and `verify_proof_of_possession` runtime API in addition to old capabilities (`sigen`, `verify`, etc). ## Testing, Security, and Privacy -The proof of possession for current crypto schemes is virtually the same as the one defined in RFC-0048. On the other hand the changes proposed by this RFC, allows the generation secure proof of possession for BLS keys. +The proof of possession for current crypto schemes is virtually identical to the one defined in RFC-0048. On the other hand, the changes proposed by this RFC allow the generation of secure proof of possession for BLS keys. ## Performance, Ergonomics, and Compatibility @@ -62,24 +58,25 @@ The performance is the same as the one discussed in RFC-0048. ### Ergonomics -Separating generation of proof of possession from signing, it allows more freedom to crypto scheme to implement proof of possession fitted to their need. +Separating the generation of proof of possession from signing allows a crypto scheme more freedom to implement proof of possession that is fitted to its needs. ### Compatibility -The significant difference, is that proof of possession suggested by RFC-0048 is signed: +The significant difference is that proof of possession suggested by RFC-0048 is signed: ``` rust account_id ``` -vs current proposal suggests to change the statement to: +vs the current proposal suggests changing the statement to: + ``` rust "POP_"|account_id ``` -for the current crypto scheme. However, future crypto scheme such as BLS which are not bound to backward compatibility could produce more sophisticated proof of possession. +for the current crypto scheme. However, future crypto schemes such as BLS, which are not bound to backward compatibility, could produce more sophisticated proof of possession. ## Prior Art and References @@ -91,8 +88,8 @@ None. ## Future Directions and Related Material -Substrate implementation of the generation of proof of possession for all crypto scheme (current and the experimental ones) is implemented in [Pull 6010](https://github.com/paritytech/polkadot-sdk/pull/6010). +\- \[1\] Substrate implementation of the generation of proof of possession for all crypto schemes (current and experimental ones) is implemented in Pull 6010. -Substrate implementation of [RFC-0048](https://github.com/paritytech/polkadot-sdk/pull/1739). +\- \[2\] Substrate implementation of [RFC-0048](https://github.com/paritytech/polkadot-sdk/pull/1739), in which the implementation of `OpaqueKeysInner:create_ownership_proof` and `OpaqueKeys:: ownership_proof_is_valid` should be modified to call `generate_proof_of_possion` and `verify_proof_of_possession` runtime APIs instead of directly calling the sign. -Implementation of `OpaqueKeysInner:create_ownership_proof` and `OpaqueKeys:: ownership_proof_is_valid` should call `generate_proof_of_possion` and `verify_proof_of_possession` runtime APIs rather directly calling sign. +\- \[3\] Ristenpart, T., & Yilek, S. (2007). The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks. In , Annual {{International Conference}} on the {{Theory}} and {{Applications}} of {{Cryptographic Techniques} (pp. 228–245). : Springer). \ No newline at end of file