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:

[2] Phobos submission:

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
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.

Reply via email to