CHANGE: Re-enable `ReseedingRng`

[boquan-fang]

Summary

How does this affect the API / end-user? (Include API-breaking changes, value-breaking changes and API additions.)

rand's user can access the ReseedingRng struct that was previously avaible until rand v0.10. This struct has been removed in v0.10. A related issue: #1721.

Details

What changes does this require internally?

It might be as simple as reverting this PR: #1722.

git revert bfa14ab4d0f2a5c161478aafe4a1edee02547f03

Essentially, we would like this struct to be made available, instead of be deprecated completely.

Motivation

What is the motivation for this change?

Since every change has a cost (even if just API churn or extra code size), every change must have sufficient motivation. This is arguably the most important part of the RFC.

We use rand for generating random bytes in s2n-quic: a rust implementation of the QUIC protocol. We use rand for both public and private generator. We will add more details about how we use ReseedingRng in our own issue: aws/s2n-quic#2986.

Alternatives

Which alternatives might be considered, and why or why not?

One alternative is to implement a ReseedingRng wrapper in s2n-quic for our own usage. I think having it from rand is more preferable.

[dhardy]

Thanks for the report; it's been hard to find real uses of ReseedingRng outside of rand. I might reconsider if there are more requests, but find it unlikely given that most users will not need ReseedingRng and its removal significantly simplified rand.

For now, I'd recommend either copying ReseedingRng from before #1722 or merging its functionality into your RNGs as we did with ThreadRng.

[LiosK]

Could it be an option to expose BlockRng<ReseedingCore>> as say ReseedingStdRng? I know StdRng is sufficient usually, but since ThreadRng exists, I am strongly tempted to reproduce the "best practice" when a Send + Sync alternative is desired.

[LiosK]

Or something like struct ThreadRngCore(BlockRng<ReseedingCore>);. ReseedingRng was a clunky solution to mimic ThreadRng behavior so will not be necessary if the ThreadRng logic is accessible.

[dhardy]

So, something like this?

pub struct ReseedingStdRng { ... }
impl ReseedingStdRng {
    pub fn new() > Result<Self, SysError>;
    pub fn reseed(&mut self) > Result<(), SysError>;
}
impl TryRng for ReseedingStdRng {
    type Error = Infallible;
    // ...
}
impl TryCryptoRng for ReseedingStdRng {}

This should be a reasonable addition: it can replace most of the internals of ThreadRng without unnecessary parametrisation.

Would someone like to make a PR? (Not a promise, but I don't currently see a reason to block this.)

[newpavlov]

ThreadRng does not use ReseedingRng in rand v0.10. It no longer needs it since the new implementation gets number of generated blocks from the ChaCha cipher core.

We could re-introduce ReseedingRng<R: SeedableRng>, but I think it should be done in a separate RNG crate.

Since every change has a cost (even if just API churn or extra code size), every change must have sufficient motivation.

Every part of public API also has cost. Both for users and maintainers.

[LiosK]

Will try to make a PR later.

[dhardy]

ReseedingRng<R: SeedableRng>

No. To making it generic over R we'd need R: block::Generator + SeedableRng and then we'd want the block::CryptoGenerator trait again. Much simpler to just have ReseedingStdRng.

But you are right that even this simpler version probably doesn't need to be in rand. Why not put your own copy in s2n-quic? I doubt many crates would use ReseedingStdRng (but let us know if yours does).

[newpavlov]

I meant the less efficient but much simpler variant of ReseedingRng which checks the reseeding condition on each next_u32/u64/fill_bytes call instead of doing it on each block generation. IIRC I even seen it implemented internally in some crate while researching how ReseedingRng used in the wild.