Add external RNG input

[chesterliliang]

External RNG

We are working on porting w3f/schnorrkel to embedded device. Merlin is one of its dependency. Embedded device always has hardware random source which is from physical noise, very secure. Meanwhile, some functions like thread_rng in rand or rand_core could not be compiled in no_std environment on thzumbv7m-none-eabi or similar. So we added a function with extra para to make it is possible to use external RNG in transcript.rs

pub fn finalize_trng(mut self,trng: &[u8]) -> TranscriptRng
    {
        let mut random_bytes = [0u8; 32];
        random_bytes.copy_from_slice(&trng[..]);

        self.strobe.meta_ad(b"rng", false);
        self.strobe.key(&random_bytes, false);

        TranscriptRng {
            strobe: self.strobe,
        }
    }

To see how the embedded porting works, you could ref wookong-dot-schnorrkel

[hdevalence]

Hi, I think that merlin is supposed to depend only on rand_core, not rand, so the thread_rng should not be pulled in -- is there an obstacle to having the embedded hardware device implement the RngCore trait from rand_core?

[burdges]

Afaik merlin has no_std support since #42 (comment) so I think this issue can be closed.

We're discussing the schnorrkel issue in w3f/schnorrkel#31

[chesterliliang]

Hi Hdevalence and Burdges. Thanks for quick response. I said wrong in my comment that merlin does depend rand_core only. And I see Burdges tried to modify schnorrkel to reduced the dependence on rand. We will keep working on to see how to improve it.
However, we still prefer external RNG as a good optional choice for schnorrkel or relative ed25519-dalek. I will explain reasons in w3f/schnorrkel#31

[burdges]

I think almost anything you passed into finalize activates std prior to rand_os 2.1 rust-random/rand#859 gets deployed. In other words, merlin itself was no_std but could not previously be deployed no_std.

Also, the fixed rand_os crate only exits for rand_core 0.5 but merlin depends upon rand_core 0.4. I think your fixes go:

• vendor merlin to upgrade the rand_core dependency, maybe using their shim (4.2?),
• vender rand_os 1.3 as 1.4 to back port the fix, or implement the OsRng wrapper on getrandom yourself.

[burdges]

Anyone who runs into this can use the RngCore5As4 workaround in w3f/schnorrkel@8150ef6