search

w3f / schnorrkel

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

Is soft public key derive ready for production usage? #74

Closed xlc closed 3 years ago

xlc commented 3 years ago

We would like to use this code to generate addresses to receive deposit. Is it considered production ready?

https://github.com/polkadot-js/wasm/blob/8fac7feabd4576351f6a9a62a79c24fa4485e792/packages/wasm-crypto/src/rs/sr25519.rs#L67-L73

burdges commented 3 years ago

Yes. We support soft public keys in production now. I've never encouraged the practice because it messes up some protocols, although only malleable VRFs conflict currently, and I made VRFs "default" to non-malleable.

I'll caution that Gav and I miss-communicated about what chaincode means, so you should do everything substrate's way but maybe this confuses someone coming from BIP32 land.

xlc commented 3 years ago

Thanks for answering. We are using polkadot.js to handle keys so we should be good.

burdges commented 3 years ago

Just fyi, the issue with malleable VRFs is that if 

preoutput[i] = sk[i] * RistrettoPoint::hash_from_bytes(input)

with sk[2] = d * sk[1]for d a known soft derivation factor, then an adversary can compute preoutput[2] = d * preoutput[1], so the adversary can learn one VRF output in advance based upon another one, even though they cannot forge the VRF signature. We make the VRF non-malleable by including the public key in input. This is also why you cannot really use BLS for blockchain accounts.