#rng #external #arm #embedded #none-os

no-std exrng

RNG crate with lan features but using external RNG source

3 releases

0.1.2 Sep 4, 2019
0.1.1 Sep 3, 2019
0.1.0 Sep 3, 2019

#85 in #external

MIT/Apache

7KB
58 lines

exrng

rust RNG crate with lan features but using external RNG source


lib.rs:

exrng

This crate has all features of CryptoRNG and RngCore But just fill the rng buffer with external 32 bytes input for platform without RUST rng supported could saftisfy other crypto crate's need for RNG so that crate could be compiled BE SURE the input are real and good random number

Simple calling example

    use exrng::ExternalRng;
    use rand_core::RngCore;

    let rng_bytes:[u8;32] = [1u8;32];
    let mut rng = ExternalRng {rng_bytes,len:32};
    let mut zero = [0u8; 32];
    rng.fill_bytes(&mut zero);

Reason we build this crate

Here is a reference why we bring up this issue in crate schnorrkel Attach a CryptoRng to a SigningTranscript to repalce the default ThreadRng There are tricks like attach_rng(t,ChaChaRng::from_seed([0u8; 32])) for deterministic tests. We warn against doing this in production however because, although such derandomization produces secure Schnorr signatures, we do implement protocols here like multi-signatures which likely become vulnerabile when derandomized.

// pub fn attach_rng<T,R>(t: T, rng: R) -> SigningTranscriptWithRng<T,R>
// where T: SigningTranscript, R: RngCore+CryptoRng
// {
//   SigningTranscriptWithRng {
//      t, rng: RefCell::new(rng)
//   }
// }

Example for schnorrkel calling

// rand_core = {version="0.4.2"} //!!! must 0.4.x
// let trng_bytes = slice::from_raw_parts(random, PUB_KEY_LEN);
   // let signature: Signature = keypair.sign(
//       attach_rng(
//           context.bytes(&message_bytes[..]), 
//           exrng::ExternalRng{
//               rng_bytes:ExternalRng::copy_into_array(trng_bytes),
//               len:32}
//              ));

Dependencies

~63KB