`sign(...)` in `sr25519` requires randomness

[puzzle-rusher]

Is there an existing issue?

• [X] I have searched the existing issues

Description of bug

When I tried to use sr25519::Pair::sign function from sp-core with default-features = false, features = ["full_crypto"] I ran into an error like

thread 'delegated_approve_success' panicked at 'Attempted to use functionality that requires system randomness!!', .../schnorrkel-0.9.1/src/lib.rs:244:55

Then I added "getrandom" in the sp-core's cargo.toml and added rand to full_crypto dependencies and it started working.

Maybe I did something wrong, please give me a solution to this problem.

If there are no hacks here, I suggest two solutions, to do something like above or remove sign function from full_crypto feature.

[ggwpez]

What are you trying to do?
Where do you want to call the sign function? In a test, a pallet or off-chain?

Creating a signature always requires randomness.

[burdges]

There are derandomized signatures, but signatures always require secrets, and if you've a problem with randomness, then you typically also have a problem with secrets.

In fact, sr25519 like ed25519 can derandomized, but it's easier to miss-use the interface provided. We plan to fix the interface, but it's not a high priority.. https://github.com/w3f/schnorrkel/issues/82

There are variations on sr25519 in the schnorrkel crate that cannot be derandomized, so it's simplest for downstream users if we assume that if you've secrets then you've system randomness too.

[puzzle-rusher]

What are you trying to do? Where do you want to call the sign function? In a test, a pallet or off-chain?

Creating a signature always requires randomness.

I am trying to test my function that verifies the signature inside. In a test, but it doesn't matter, I think.

I am not against the randomness in creating a signature, but I'm against the unclear API that makes it difficult to use in some cases. So I came up with some solutions.

[ggwpez]

I am trying to test my function that verifies the signature inside. In a test, but it doesn't matter, I think.

It does matter, tremendously, that is why I asked.
In a test you can do anything; in a pallet not. Make sure to only add the full_crypto feature to your dev-dependencies for your test.

There is an SE answer here which covers signing and verifying in a test: https://substrate.stackexchange.com/a/4225/94
The main thread for pallet signature verification: https://substrate.stackexchange.com/a/316/94
And a complete project which does off-chain signature creation and on-chain verification in case you are interested in digging into the code: https://github.com/perun-network/perun-polkadot-pallet

[bkchr]

Not sure why you are writing your test in Wasm. You would need to provide some more information on what you are doing to get help.

The full_crypto feature is automatically enabled when std is enabled. So, no special handling is needed there.

[davxy]

I try to reformulate the issue of @puzzle-rusher .

Fact: sp-core crate allows to disable std (default_features = false) and at the same time enable full_crypto.

So regardless of what he is trying to do, the intended target (wasm/native), the usage (test/non-test/bench) and if is correct or not; what I think he wanted to highlight is that is possible to do so.

Thus, when the user builds sp-crypto with default-features = false and full_crypto feature, schnorkell fails at runtime with such a message (triggered here).