search

w3f / schnorrkel

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

Add rand back #87

Open burdges opened 1 year ago

burdges commented 1 year ago

Revert https://github.com/w3f/schnorrkel/commit/c333370c164746c6e4c2e74fd9b7a53c72dd10f9 and fix rand. We've way less churn in rand today, and this syscall surely hurt performance ala https://github.com/paritytech/polkadot-sdk/issues/732

koute commented 1 year ago

Whether this eats up a lot of performance or not very much depends on 1) how many calls we're making, and 2) which exact version of Linux the user's running (IIRC there were some performance optimizations done to getrandom).

Nevertheless, this is a good idea.

My runtime SIMD detection PR was recently merged in curve25519-dalek, so as soon as there's a new release I'll be making a PR switching to the new version and releasing a new schnorrkel. I can also take care of this issue then if you want. (Unless you want to do it yourself earlier.)

burdges commented 1 year ago

Oh either way.

We've no reason for a separate rand feature I think. If getrandom works then ThreadRng works. As an aside, getrandom's custom feature should simplify life for possible cargo patch users (hardware wallets?), so afaik that's not a concern either.