Rng: Add prng, hwrng support

[Remmirad]

This is an idea to provide prngs seeded by RIOTs hwrng interface. This uses random as one prng.

In addition I implemented rand:RngCore and rand::SeedableRng with random to provide the rand::Rng interface to be usable here. Also a function is provided to seed an rand::StdRng (Seems not need std despite its name) with hwrng to have two different prngs at hand.

The rand part was mostly added because I like the interface of rand::Rng but it's just an idea and it definitely needs to be discussed if it is worth the extra dependencies. Or maybe should be behind a feature.

Structure looks like this:

• hwrng.rs: Wrapper around hwrng interface
• random.rs: Wrapper around random module + implementation of rand interfaces
• prng.rs: User faced helper methods to create a prng via hwrng seeding

Edit: This needs a change in rust-riot-sys to create bindings to random (See RIOT-OS/rust-riot-sys#26)

[chrysn]

I haven't plowed through the random.rs yet, but do I get this right that while hwrng.rs and prng.rs's rand_prng already give the user all they need, the riot_prng (backed by random.rs) is "only" there to avoid pulling in code for StdRng in situations when RIOT's rng is either already there or for other reasons works better than the pure Rust version?

(The "only" is in quotes because these are legitimate reasons; I wonder though whether we should have unified API, and what can be done to make this more visible.)

[chrysn]

No need for unsafe here; as per above the error type is uninhabited, the error handling will just collapse.

(And if the RIOT HWRNG ever does become fallible, we'll get a clean crash rather than UB).

[Remmirad]

fixed in 2b99ee5

[chrysn]

As I understand, the sensible way to use all of this is through the prng module.

Is there any good reason that the hwrng module and the random module are pub in the first place, or that RandomSeed::new_from_hwrng would be public?

[Remmirad]

Yes it is intended to be used through prng. I just left the rest public in case someone might need it e.g to seed his own prng but we could make it private to make people use the "intended" way. I do not have a strong opinion on that matter.

[chrysn]

Then please limit the public parts. Public APIs that are not used are a needless compatibility liability -- whereas the two functions that will stay pub can easily be maintained. If it turns out that any part of this is needed, it's still easy to make a few more parts pub, whereas going back on that is a breaking change.

[Remmirad]

I made the two modules random and hwrng private

[Remmirad]

Is this even still relevant with the other random module now present in the wrappers? As far as I can see they both do roughly the same with the main differences being:

• This PR allows to overwrite the current Random state in safe Rust by instantiating multiple instances of it. (Should probably be changed to allow only a single creation)
• This PR would allow to use different seed sizes (The relevant parts are private at the moment though)
• Allows to seed the rand StdRng with RIOTs hwrng (Is that even needed? Maybe if multiple RNG instances are required?)
• This tries to enforce sha256 and not allow to use sha1 (At least for the CryptoRng this might be desirable?)
• Always forces the user to provide a seed or use the hwrng to create one (without the use of periph_hwrng the auto_init seed might be very bad according to RIOT docs?)

Depending on any of the above being desirable this PR could just be closed or some of the changes could be merged into the current solution.