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

core: replace secp256k with k256 in crypto::ecdsa #3525

Merged
merged 23 commits into from
Mar 9, 2024

Conversation

michalkucharczyk
Copy link
Contributor

@michalkucharczyk michalkucharczyk commented Feb 29, 2024

This PR replaces the usage of secp256k crate with k256 in core::crypto::ecdsa for non-std environments as outcome of discussion in #3448.

secp256k1 is used in std, meaning that we should not affect host performance with this PR.
k256 is enabled in runtimes (no-std), and is required to proceed with #2044.

If desirable, in future we can switch to k256 also for std. That would require some performance evaluation (e.g. for EVM chains as per #3448 (comment)).

Closes #3448

@michalkucharczyk michalkucharczyk added T0-node This PR/Issue is related to the topic “node”. R0-silent Changes should not be mentioned in any release notes labels Feb 29, 2024
@michalkucharczyk
Copy link
Contributor Author

cc: @burdges

}
}

#[cfg(feature = "full_crypto")]
impl From<RecoverableSignature> for Signature {
fn from(recsig: RecoverableSignature) -> Signature {
impl From<(k256::ecdsa::Signature, RecoveryId)> for Signature {
Copy link
Contributor Author

@michalkucharczyk michalkucharczyk Feb 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: (k256::ecdsa::Signature, RecoveryId) is a result of sign_prehash_recoverable. Convenient From.

context.sign_ecdsa_recoverable(&message, &self.secret).into()
self.secret
.sign_prehash_recoverable(message)
.expect("signing may not fail (???). qed.")
Copy link
Contributor Author

@michalkucharczyk michalkucharczyk Feb 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our API (e.g. TraitPair) we assume signing cannot fail (return type is not Option or Result).
Is expect fine here? What would be condition for potential failure?

Self::unchecked_from(
pubkey.to_sec1_bytes()[..]
.try_into()
.expect("valid key is serializable to [u8,33]. qed."),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

double-check needed here. Can we actually fail?

@michalkucharczyk
Copy link
Contributor Author

bot fmt

@command-bot
Copy link

command-bot bot commented Feb 29, 2024

@michalkucharczyk https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5397860 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 6-05ac224d-82d5-4c02-8f45-8696b2e2ed40 to cancel this command or bot cancel to cancel all commands in this pull request.

@command-bot
Copy link

command-bot bot commented Feb 29, 2024

@michalkucharczyk Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5397860 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5397860/artifacts/download.

Copy link
Member

@davxy davxy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll give it a try tomorrow. Maybe before merge we should try to sync from genesis (aka burn-in test)?

substrate/primitives/core/src/ecdsa.rs Show resolved Hide resolved
substrate/primitives/core/src/ecdsa.rs Outdated Show resolved Hide resolved
Two features added:
- backend_secp256k1
- backend_k256

This allows to choose a secp256k1 implementation backend for
crypto/ecdsa module.

backend_secp256k1 is by default enabled in std.
@davxy
Copy link
Member

davxy commented Mar 4, 2024

Maybe without leaving too much choice (choices sometimes makes the user confused 😆) we can just use secp256k1 on std and k256 for no-std. I mean, without introducing these two mutually exclusive features.

I'd personally find it easier if I have no idea what I'm doing and what is best

@michalkucharczyk michalkucharczyk requested review from a team and removed request for a team March 6, 2024 11:35
@michalkucharczyk
Copy link
Contributor Author

I'll give it a try tomorrow. Maybe before merge we should try to sync from genesis (aka burn-in test)?

Sync from genesis test on kusama and polkadot was fine (with k256 on host side).

Copy link
Member

@davxy davxy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@davxy davxy requested a review from a team March 8, 2024 16:08
@davxy davxy requested a review from a team March 8, 2024 16:13
substrate/primitives/core/Cargo.toml Show resolved Hide resolved
@michalkucharczyk michalkucharczyk added this pull request to the merge queue Mar 9, 2024
Merged via the queue into master with commit 9f5d9fa Mar 9, 2024
129 of 130 checks passed
@michalkucharczyk michalkucharczyk deleted the mku-k256-in-core-crypto-ecdsa branch March 9, 2024 10:49
dharjeezy pushed a commit to dharjeezy/polkadot-sdk that referenced this pull request Mar 24, 2024
This PR replaces the usage of
[secp256k](https://crates.io/crates/secp256k1) crate with
[k256](https://crates.io/crates/k256) in `core::crypto::ecdsa` for
`non-std` environments as outcome of discussion in paritytech#3448.

`secp256k1` is used in `std`, meaning that we should not affect host
performance with this PR.
`k256` is enabled in runtimes (`no-std`), and is required to proceed
with paritytech#2044.

If desirable, in future we can switch to `k256` also for `std`. That
would require some performance evaluation (e.g. for EVM chains as per
paritytech#3448 (comment)).

Closes paritytech#3448

---------

Co-authored-by: command-bot <>
Co-authored-by: Davide Galassi <[email protected]>
bgallois pushed a commit to duniter/duniter-polkadot-sdk that referenced this pull request Mar 25, 2024
This PR replaces the usage of
[secp256k](https://crates.io/crates/secp256k1) crate with
[k256](https://crates.io/crates/k256) in `core::crypto::ecdsa` for
`non-std` environments as outcome of discussion in paritytech#3448.

`secp256k1` is used in `std`, meaning that we should not affect host
performance with this PR.
`k256` is enabled in runtimes (`no-std`), and is required to proceed
with paritytech#2044.

If desirable, in future we can switch to `k256` also for `std`. That
would require some performance evaluation (e.g. for EVM chains as per
paritytech#3448 (comment)).

Closes paritytech#3448

---------

Co-authored-by: command-bot <>
Co-authored-by: Davide Galassi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

core/ecdsa implementation in runtime?
4 participants