signature: tracking issue for rand_core (RandomizedSigner) stabilization

[tarcieri]

The signature crate contains the RandomizedSigner trait which are presently gated under the rand-preview rand_core feature.

Its main purpose is to allow a CSPRNG to be provided at the time a signature is computed. This is useful with algorithms like ECDSA or RSASSA-PSS which require an RNG at signing time.

There are also lingering concerns that deterministic signature algorithms like Ed25519 or ECDSA when implemented deterministically RFC6979 are brittle in the presence of fault attacks and should supplement their deterministic operation with additional randomness/entropy, which a RandomizedSigner API would allow for.

The main blocker at present is a 1.0 release of the rand_core crate.

Of all of the traits in the signature crate, this one is by far the most underexplored/experimented with. So far there are no crates which actually impl it.

[tarcieri]

The name RandomizedSigner is fairly long... would RngSigner perhaps be better?

[tarcieri]

#235 added RandomizedDigestSigner which is effectively blocked on both this issue and #92

[incertia]

With RandomizedSigner existing, it may be useful to also provide a RandomizedSignerMut trait. For example, LMOTS signatures can only be signed with a private key once (Mut would allow us to zero out the private key after a successful signature) and requires some random bytes to be generated. For consistency we would probably also have to add RandomizedDigestSignerMut as well.