2

Working on libwallet we'd like to create a back-end for Rust friendly micro-controllers for possible future Substrate friendly hardware wallets. The nRF52 and other chips are very common in the embedded Rust ecosystem and come with their own crypto module that can sign/verify messages using the ed25519 signature algorithm without exposing private keys but most Substrate chains use sr25519 keys which are not likely to be supported natively by browsers or hardware providers.

I'm not a cryptography expert so It might even be a dump question, but it's my understanding that Schnorr/Ristretto signatures are not much different from Ed25519 signatures. In the docs of the schnorrkel implementation I find

These cannot be converted to any Ed25519 signature because they hash curve points in the Ristretto encoding.

From my developer understanding I get that the ristretto encoding part is a lossy process so going sr25519 -> ed25519 is not possible but it would seem to me that is not impossible to do the opposite ed25519 -> sr25519 ?
It would be really near to be able to use the available capabilities of those hardware modules to sign messages and convert them to Substrate compatible signatures, same for the public keys.

1 Answer 1

1

I am not a cryptography expert either, so your mileage may vary.

Both scheme uses the same elliptic curve, but different sign/verify methods. SR25519 fixes more than one problems with EDDSA signatures (cofactors, overflow, no multisig). You cannot convert signatures either way, but you can theoretically reuse the same private keys in both signature schemes. But that would be a bad idea and would go against domain separation of keys.

Most likely you will need to use the schnorrkel crate to run the algorithms on arithmetic instructions supported by your hardware.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.