Update rand and rand_core

[wysiwys]

This pull request updates the dependencies rand from 0.8 -> 0.9 and rand_core from 0.6 -> 0.9. It is based on dependabot's PRs (see #787 and #786).

Tests and benchmarks are also updated.

Occasionally, a feature (classic-mceliece in libcrux-psq) or a benchmark requires an older version of rand or rand_core. In this case, the older version of the affected crate is added to Cargo.toml with the name rand_old or rand_core_old, respectively.

• Use new trait TryRngCore where necessary
• Where applicable, use OsRng::try_fill_bytes() instead of OsRng::fill_bytes() (since OsRng no longer implements the CryptoRng trait, which provides this function).
• To handle certain cases where try_fill_bytes() returns an error, add an Error::InsufficientOSRandomness variant

[jschneider-bensch]

It looks like many of the examples and tests expect OsRng to implement RngCore instead of TryRngCore. I think in many we can just .unwrap() on try_fill_bytes().
In some, we run into the issue that OsRng no longer implements CryptoRng, but TryCryptoRng. E.g. the top level ECDH API requires CryptoRng for key generation, but internally key generation already uses try_fill_bytes, so I think TryCryptoRng would be sufficient (at least in this case that I checked). But maybe that can be a separate PR, since it changes the public API. We can use unwrap_err in these cases for now to get a CryptoRng from a TryCryptoRng.

[franziskuskiefer]

@wysiwys what's the state here? Do you need input or want someone else to take over?

[wysiwys]

@franziskuskiefer One thing I ran into that is holding back development on this branch is connected to a third-party crate, which is built on top of rand version 0.8. Specifically, there is a trait definition issue that arises when calling classic_mceliece_rust::keypair_boxed() in psq.rs.

To go into more detail, the inputs to that function must implement the rand::CryptoRng and rand_core::RngCore traits, but the versions of those traits from older versions of those libraries. However, in rand version 0.9 and the new, corresponding rand_core version, the definitions of these traits have been changed, which leads to a build error in this crate, since the input previously passed into it is no longer valid.

Once classic-mceliece-rust has released a new version, and depends on the latest version of rand, the development on the dependency update in this branch should go smoothly. In the meantime, is there a different solution or workaround that could be applied for this issue?

[franziskuskiefer]

We can't keep everything back because there's a bad dependency in a small part.
Either you update everything but psq to 0.9, or everything including psq but add a second API entrypoint for mceliece that gets the old rng.

[wysiwys]

We can't keep everything back because there's a bad dependency in a small part. Either you update everything but psq to 0.9, or everything including psq but add a second API entrypoint for mceliece that gets the old rng.

Thanks @franziskuskiefer . I went with the option of adding a second entrypoint for mceliece, since psq depends on libcrux_kem (and then the same rand dependency issue would apply to it as well).

[wysiwys]

The only other changes to the crates' public APIs are replacing inputs that are &mut (impl RngCore + CryptoRng) with &mut impl CryptoRng, since CryptoRng is now a supertrait of RngCore.

[wysiwys]

Also thanks @jschneider-bensch for providing this workaround for the rand=0.8 dependency requirement for classic-mceliece-rust. I incorporated the commit from your branch into this pull request.

[keks]

I think this looks good in general! I am a bit unsure around the generated code:

1. The toolchain hashes are gone in the headers and codegen.txt, I don't think this is supposed to happen.
2. This adds a header.txt, which seems like it maybe shouldn't be there?
3. The rlimit in the F* code is different, is that correct?