Add UniScalarRng

[moCello]

Resolves: #121

[HDauven]

LGTM, small comment.

[vlopes11]

I think we are adding unnecessary complexity by introducing a new RNG. Making it a function of JubJubScalar would be simpler & more consistent

[vlopes11]

Not sure we need an iterator here. This will make it harder for the compiler to optimize. Being a small, fixed size array, why not just take the next_u64?

[vlopes11]

Ditto; unnecessary usage of iterators

[vlopes11]

The returned value is a raw little-endian representation of the scalar limbs. This is not the expected serialized format, I wonder why we are doing it.

If we are to generate the limbs, we should probably send them directly to the scalar. We only have to return "bytes" because we opted to create a new RNG, when in fact what we need is to sample uniform 4-tuple u64.

[vlopes11]

I'm not sure why we create a new RNG when we just want to create new random scalars from a given uniform RNG.

What we are attempting to achieve is to have a uniform implementation for JubJubScalar that takes a uniform sampler, not to create our own samples (that in the end will increase the type complexity of the stack).

Why not just implement this as a function JubJubScalar::random or JubJubScalar::uniform_random?

I favor replacing the previous implementation since the uniform bits is a desirable property in any context.

[vlopes11]

A more suitable approach would be to use a fuzzing library. Consider quickcheck

[moCello]

After extensive discussions we decided to not change the random scalar generation because it was deemed secure enough for our purpose:

We will use this paper to determine whether the current implementation of the random scalar implementation as done in the Field trait implmentation is cryptographically safe.

In the current implementation of random, we sample a random element with 512 bits, and reduce it by the modulo of the field of JubJubScalar to generate a valid scalar.

For JubJubScalar we have:

p := 0x0e7db4ea6533afa906673b0101343b00a6682093ccc81082d0970e5ed6f72cb7
p = 6554484396890773809930967563523245729705921265872317281365359162392183254199

and

s := 2^512
s = 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096

To check whether the above approach is secure, we do the following:

For p < s calculate r and m so that

s = rp + m

This leads to:

r := 2045593080716281616348203381729468609728209645786990242449482205581148743408809

and

m := s - p * r
m = 2244478849891746936202736009816130624903096691796347063256129649283183245105

Now we can check whether:

r > 2^64 * root(m/p)
r > 2^64 * root(0.34243408237518300501)
r > 18446744073709551616 * 0.58517867559847308999

This clearly holds true, which means that we fall in the first conversion of the paper above, and can safely sample an element from the field over 2^512 and take it modulo p.

This concludes that we don't need to make any adjustments to the current implementation of random scalar generation.