search

w3f / schnorrkel

Schnorr VRFs and signatures on the Ristretto group
BSD 3-Clause "New" or "Revised" License
309 stars 93 forks source link

gitrandom_or_panic #98

Closed burdges closed 10 months ago

burdges commented 10 months ago

We'll see if CI likes this..

burdges commented 10 months ago

We'll eventually fix the multi-signature stuff and then system randomness really matters. If we let folks derandomize this too easily, then we'd possible end up with ecosystem tooling that depends upon derandomized signatures.

tomaka commented 10 months ago

Although perhaps a better approach would be to just nuke/simplify this completely and have the user always explicitly pass an RNG? (so, e.g. delete the generate() and only leave the generate_with)

I agree with this.

If we let folks derandomize this too easily

People who aren't sure what they're doing will simply do something like generate_with(rand::random()), which is fine. The easy way is already the secure way. Someone who intentionally makes the effort to use a non secure PRNG will also probably use generate_with anyway.

burdges commented 9 months ago

Ain't worried about key generation here. We still envision doing multi-signatures properly, but multi-signatures break completely without system randomness, because they must generate their nonce without full information. It's this line specifically: https://github.com/w3f/schnorrkel/blob/master/src/musig.rs#L490

I originally imposed this everywhere because I figured air gapped signers would never catch up on multisignatures otherwise. That was maybe heavy handed, but maybe not. It stoped a few people doing dumb shit like signing form the runtime too. I flaged a case where someone was using bad randomness in ECDSA too. Requiring system randomness is not currently one of the decissions in schnorrkel which I regret. ;)