Open isislovecruft opened 5 years ago
Doesn't this equally apply to prove/prove_with_rng
?
I'd vote for not depriving std-users from having prove_with_rng
. It's useful to compose with higher-level APIs that make the same distinction for the same reason and extra restrictions would force higher-level libs to make exactly the same dichotomy as lower-level lib.
As of footguns, i think it's enough that the safer-to-use API is (1) shorter-named (2) takes fewer arguments.
I would prefer not to have a verify_with_rng
and instead find a way for verification be a stand-alone operation that depends only on the proof.
Unfortunately, verification involves merging multiple statements in one with a random factor. Here are the available options to make thread_rng
dependency optional or remove entirely:
verify
/ verify_with_rng
as mentioned above.verify
uses deterministic challenges w/o any RNG at all (via Transcript instance). This is a bit weaker since attacker can learn those, but it seems to be strictly the same trick as deterministic merge of statements within the previous steps of the protocols, so if that's a weakness, the whole protocol is weak already.verify
uses internally thread_rng
if built with std
and uses deterministic challenges if not. That's IMHO a poor dichotomy akin to "try /dev/random, and if it's blocking, try /dev/urandom instead". This makes other people think that one option is clearly worse, but somehow still acceptable.I'd personally go with option 2 for verify
and have dual prove
/prove_with_rng
APIs to work around "RNG against no_std" problem.
Hi! It was briefly discussed in the dalek-cryptography slack that this crate currently cannot be used in
no_std
environments due to its internal usage ofrand::thread_rng()
, which obviously requires thread-local storage and thus thestd
library. @oleganza proposed exposing an API such asverify_with_rng()
, which then the currentverify()
would be a backwards-compatible wrapper for by passing in arand::thread_rng()
.verify_with_rng()
should have a trait bound forRng + CryptoRng
(and possibly alsoSeedableRng
? since theFromEntropy
trait also requiresstd
).Questions:
Would you like me to feature-gate the publicity of this? I.e.:
So that explicitly only
no_std
users are trusted with passing in their own correctly-seeded PRNG?