Skip to content
This repository has been archived by the owner on Apr 24, 2024. It is now read-only.

Differences in sr25519 implementations in JS and rust #15

Open
ameba23 opened this issue Nov 1, 2023 · 0 comments
Open

Differences in sr25519 implementations in JS and rust #15

ameba23 opened this issue Nov 1, 2023 · 0 comments

Comments

@ameba23
Copy link
Contributor

ameba23 commented Nov 1, 2023

This relates to this crate using schnorrkel's SecretKey::from_ed25519_bytes when creating a sr25519 keypair from a given secret key.

It seems this is needed due to the different way sr25519 keypairs are created in @poltadot/keyring and sp-core::sr25519.

See the discussion in this PR:
#12

@frankiebee found this open issue in the schnorrkel repo where someone else has found this discrepancy: w3f/schnorrkel#77

@frankiebee also found where this from_ed25519_bytes gets used in polkadot's wasm-crypto which is called internally when sr25519 signing using @polkadot/keyring:
https://github.com/polkadot-js/wasm/blob/b82e28ad4ed888ef4a461ee8e0ba25acdb87dc1a/packages/wasm-crypto/src/rs/sr25519.rs#L125

TLDR: sr25519 Signing is not the same in polkadot-js and either of the substrate rust implementations (sp-core::sr25519 and subxt-signer). The public key included in a SignedMessage created with encrypt_and_sign is different to the corresponding public key when creating a keypair in any sr25519 implementation, or with SignedMessage::new.

Do not use encrypt_and_sign or decrypt_and_verify from rust.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant