WIP: Bump to rand[_core] 0.9

[pinkforest]

Pending / Clarifications

• Breaking/Minor (Opt-in): Requires MSRV 1.63 - need to bump from current 1.60
• Breaking/Minor (Opt-in): rand_core 0.9 via API
• Breaking/Minor (Opt-in): We need to implement TryCryptoRng which needs API changes from current infallible API.
• group and ff needs to bump rand + rand_core - Bump rand + rand_core zkcrypto/group#55

Notes

• warning: use of deprecated function rand::thread_rng: renamed to rng <-- was renamed
• CryptoRngCore no more: Rework CryptoRng rust-random/rand#1273
• 0.9 OsRng does not seem to implement CryptoRng ? rust-random/rand#1561
• ThreadRng and OsRng implement diff Try/CryptoRng traits rust-random/rand#1566
• rand_core/getrandom is no more pub - Make getrandom a non-pub dep; rename feature to os_rng rust-random/rand#1537
• Let rand::rng() use OsRng unless thread_rng is enabled? rust-random/rand#1545

[tarcieri]

@pinkforest it needs to be os_rng now

[NimonSour]

Since rand_core changed the trait for OsRng from CryptoRngCore( which is RngCore + CryptoRng ) to TryRngCore +TryCryptoRngit makes sense to keep all the methods of types across dalek crates that are dependent on CryptoRngCore ( like generate and random ) as R : RngCore + CryptoRng plus adding the additional methods ( try_generate and try_random ) respectively where R : TryRngCore + CryptoRngCore.

Example for ed25519/src/signing.rs

    pub fn generate<R: RngCore + CryptoRng + ?Sized>(csprng: &mut R) -> SigningKey {
        let mut secret = SecretKey::default();
        csprng.fill_bytes(&mut secret);
        Self::from_bytes(&secret)
    }
    
    pub fn try_generate<R: TryRngCore + TryCryptoRng + ?Sized>(csprng: &mut R) -> Result<SigningKey,<R as TryRngCore>::Error> {
        let mut secret = SecretKey::default();
        csprng.try_fill_bytes(&mut secret)?;
        Ok(Self::from_bytes(&secret))
    }

It will offer some backward compatibility while aligning with rand_core's RngCoreand TryRngCore traits, where the user has a choice on RNG implementation.

[tarcieri]

it makes sense to keep all the methods of types across dalek crates that are dependent on CryptoRngCore ( like generate and random ) as R : RngCore + CryptoRng

CryptoRng now has a supertrait bound on RngCore, so instead CryptoRngCore should just be replaced with just CryptoRng. Adding RngCore + ... is redundant due to the supertrait bound. See:

https://docs.rs/rand_core/0.9.0/rand_core/trait.CryptoRng.html

Also you can call OsRng.unwrap_err() to get a CryptoRng-friendly version of OsRng.

[pinkforest]

I assume we can live with ff/group will get duplicate 0.8 rand until ff/group upgrades - unblocking us to adopt 0.9 ?

[baloo]

Could you retarget rustcrypto-new-releases?

[nresare]

Since it seems we have ended up in a bit of a holding pattern where everyone waits on everyone else to make the move to rand 0.9.x I went ahead and scoped out what would be needed for getting at least all the tests to compile. The changes needed can be viewed in this commit but it seemed impolite to open a second PR pretty much the same thing.

@pinkforest please let me know how/if you would like to incorporate those changes, I'm happy to see this addressed in whatever way. Some observations:

• To the best of my understanding, it is not possible to have both rand 0.9 and <0.9 in the dependency tree at the same time. Which means that we need to ensure that no dependency brings the old versions.
• This translates into a requirement to have new releases of ff and group. There are already a prerelease branch of ff 0.14 and a PR that updates group
• A somewhat more complex case is the dev-dependency merlin which in turn depends back on curve25519. I'll open a PR to at least get the ball rolling on getting that sorted, but I would imagine that this requires a coordingated release of new packages. Fun.
• The bulk of the changes needed are related to OsRng no longer implementing CryptoRng, instead opting to implement TryCryptorRng (presumably because things like reading from /dev/urandom means filesystem IO theoretically can fail). I have opted to use the ThreadRng available from rand::rng() but I guess we could change that to a OsRng wrapper that panics on failures

[tarcieri]

The bulk of the changes needed are related to OsRng no longer implementing CryptoRng, instead opting to implement TryCryptorRng (presumably because things like reading from /dev/urandom means filesystem IO theoretically can fail). I have opted to use the ThreadRng available from rand::rng() but I guess we could change that to a OsRng wrapper that panics on failures

You can get an OsRng that panics on failures with:

OsRng.unwrap_err()

...which returns an UnwrapErr<OsRng> that impls CryptoRng.

OsRng is a more conservative choice for things like key generation. Userspace RNGs have more sharp edges, e.g. fork safety, VM suspend/resume

[tcerqueira]

Suggested change

	rand_core = { version = "0.9", default-features = false, features = ["getrandom"] }
	rand_core = { version = "0.9", default-features = false, features = ["os_rng"] }

[tcerqueira]

Suggested change

	rand_core = { version = "0.9", default-features = false, features = ["getrandom"] }
	rand_core = { version = "0.9", default-features = false, features = ["os_rng"] }

[tarcieri]

Closing in favor of #777