4 ms·
Not that familiar with Rust, but should the key generators perhaps take CryptoRng rather than Rng in their signatures, to prevent footgunning by users of the cr
by regecks 7y ago
Not that familiar with Rust, but should the key generators perhaps take CryptoRng rather than Rng in their signatures, to prevent footgunning by users of the crate?
https://github.com/ArgusHQ/wagyu/blob/6b723d5c2c90ac87bcb44efe987276f90f94e2a2/bitcoin/src/private_key.rs#L28 https://github.com/ArgusHQ/wagyu/blob/6b723d5c2c90ac87bcb44e...
The CLI does use StdRng which is a CryptoRng, so no real problems.
- deleted 7y ago[deleted]
- whyever 7y agoYes, that would be better! However, they seem to be using `XorShiftRng` in their tests, which is no cryptographically secure, so they can't use `CryptoRng` over `Rng` in their API without resorting to compile-time magic. I think they should just use `StdRng`, which is cryptographically secure and quite fast.
- deleted 7y ago[deleted]
- Ar-Curunir 7y agoIt's useful to have a seed able Rng when running tests in cryptographic use cases, as it allows you to reproducibly debug failures. I guess that's why they're using XorShiftRng. There are definitely cryptographically safe SeedableRngs; maybe they should use those?
- whyever 7y agoYes, I would recommend to use `rand_chacha::ChaCha20Rng`, which is equivalent to `rand::rngs::StdRng`, but is guaranteed to be value stable.
- staticassertion 7y agoI would imagine that they could solve this fairly easily by wrapping XorShiftRng in a newtype, and then implementing CryptoRng for that newtype. It's an awful thing to do in consumable code, but so long as it's done in the test module it should be perfectly fine.