-
Notifications
You must be signed in to change notification settings - Fork 769
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
Conversation
cc: @burdges |
} | ||
} | ||
|
||
#[cfg(feature = "full_crypto")] | ||
impl From<RecoverableSignature> for Signature { | ||
fn from(recsig: RecoverableSignature) -> Signature { | ||
impl From<(k256::ecdsa::Signature, RecoveryId)> for Signature { |
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.
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.") |
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.
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."), |
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.
double-check needed here. Can we actually fail?
bot fmt |
@michalkucharczyk https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/5397860 was started for your command Comment |
@michalkucharczyk Command |
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'll give it a try tomorrow. Maybe before merge we should try to sync from genesis (aka burn-in test)?
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.
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 |
Sync from genesis test on kusama and polkadot was fine (with |
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.
LGTM
Co-authored-by: Davide Galassi <davxy@datawok.net>
Bring back k256/std. This reverts commit 38de881.
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 <davxy@datawok.net>
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 <davxy@datawok.net>
This PR replaces the usage of secp256k crate with k256 in
core::crypto::ecdsa
fornon-std
environments as outcome of discussion in #3448.secp256k1
is used instd
, 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 forstd
. That would require some performance evaluation (e.g. for EVM chains as per #3448 (comment)).Closes #3448