hap.random: a new random number library for D

Nick Sabalausky via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Tue Jun 10 23:56:12 PDT 2014


On 6/10/2014 7:08 PM, Chris Cain wrote:
>
> 3. I'd also REALLY like to see seed support ranges/values giving ANY
> type of integer and guarantee that few bytes are wasted (so, if it
> supplies 64-bit ints and the generator's internal state array only
> accepts 32-bit ints, it should spread the 64-bit int across two cells in
> the array). I have working code in another language that does this, and
> I wouldn't mind porting it to D for the standard library. I think this
> would greatly simplify the seeding process in user code (since they
> wouldn't have to care what the internal representation of the Random
> state is, then).

Joseph and I have recently had some discussion on the idea of random 
streams which could work as you describe (The full discussion was in the 
digitalmars.D thread titled "isUniformRNG"). A finalized design would be 
dependent on Phobos's redesign of streams. But an unofficial design does 
exist, as it was needed for a crypto RNG I wrote[1][2]. An "RNG -> RNG 
stream" adapter could easily be written.

[1] Original version:
https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d

[2] Phobos submission:
https://github.com/D-Programming-Language/phobos/pull/2208

> 4. I'd just like to say the idea of using ranges for seeds gets me giddy
> because I could totally see a range that queries https://random.org for
> true random bits to seed with, wrapped by a range that zeroes out the
> memory on popFront. Convenient and safe (possibly? Needs review before I
> get excited, obviously) for crypto purposes!

Personally, I wouldn't trust an internet-hosted RNG for crypto purposes 
as there's too many ways it could go wrong on either end. However, 
*mixing* it in as an additional source of entropy (together with a local 
source of non-determinism and a proper crypto-grade PRNG such as 
Hash_DRBG) sounds promising to me. Although I'm not a cryptography expert.

> 5. Another possible improvement would be something akin to a "remix"
> function. It should work identically to reseeding, but instead of
> setting the internal state to match the seed (as I see in
> https://github.com/WebDrake/hap/blob/master/source/hap/random/generator.d#L485),
> remixing should probably be XOR'd into the current state. That way if
> you have a state based on some real entropy, you can slowly, over time,
> drip in more entropy into the state.

Interesting that you mention that. Hash_DRBG does pretty much that 
(although it's a little more complicated than an simple XOR). While I'm 
not particularly familiar with any others, I'd imagine that's probably a 
typical behavior among cryptographic PRNGs in general.



More information about the Digitalmars-d-announce mailing list