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. An "RNG -> RNG
stream" adapter could easily be written.
 Original version:
 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.