PRNG - currently available solutions aren't addressing many use cases

Calvin Metcalf calvin.metcalf at gmail.com
Tue Dec 1 19:47:42 UTC 2015


node crypto is asynchronous or sync and it returns a buffer of binary data
uint8's are just the default way of that node buffers represent data
On Tue, Dec 1, 2015, 2:20 PM Michał Wadas <michalwadas at gmail.com> wrote:

> As we all know, JavaScript as language lacks builtin randomness related
> utilities.
> All we have is Math.random() and environment provided RNG - window.crypto
> in browser and crypto module in NodeJS.
> Sadly, these APIs have serious disadvantages for many applications:
>
> Math.random
> - implementation dependant
> - not seedable
> - unknown entropy
> - unknown cycle
> - returns float
> + portable
>
> window.crypto
> - not widely known
> - not portable
> - not seedable
> - low level interface requiring passing typed array
> - allow to get maximally 65k values at once
> + cryptographically secure
> + allow any type of generated numbers
>
> require('crypto')
> - not portable
> - asynchronous
> - low level interface
> - returns series of uint8
> - not seedable
> + cryptographically secure
> + asynchronous (can be advantage or disadvantage, depending on use case)
>
> As we can see, all these either unreliable or designed mainly for
> cryptography.
>
> That's we need easy to use, seedable random generator.
>
> Why shouldn't it be provided by library?
> - average developer can't and don't want to find and verify quality of
> library - "cryptography is hard" and math is hard too
> - library size limits it usability on Web
> - no standard interface for PRNG - library can't be replaced as drop-in
> replacement
>
> Specification should probably include:
> - seedable random generator instance (new RamdomGenerator(algorithm,
> seed)) with methods random(), ramdomInteger(min, max),
> fillWithRamdom(typedArray)
> - seedable sequence (infinite iterator)
> - promise-based solution for asynchronous tasks
>
> Questions, ideas:
> - should we provide Array.prototype.shuffle?
> - should be internal state of generator exposed? Should it be read-only?
> - how many algorithms should be obligatory?
> - should we have methods like randomFloat32 corresponding to typed arrays?
> - GPU accelerated PRNG as optional extension?
> - UUIDs built in standard library?
>
> Have I missed some use cases or restrictions?
>
> Michał Wadas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151201/4b01e2ee/attachment.html>


More information about the es-discuss mailing list