On Wednesday, 11 June 2014 at 06:41:34 UTC, Joseph Rushton Wakeling wrote:
>> Done :) ... if I get a response, I'll make sure to incorporate everything said.
>
> Great, let me know how that goes. :-)

Well, the ultimate conclusion of the conversation with the guy is that:
1. ISAAC probably isn't cryptographically secure. Despite not having found any attacks, it just isn't proof of security. It's not been looked at enough to really approve of its usage for that purpose (I'm kind of agreeing with this)

2. ISAAC in his opinion probably isn't appropriate for non secure uses for much the same reason.

I don't agree with that because everything I've seen for ISAAC shows that it has some really good statistical properties. Even if it's not cryptographically secure, it appears to produce "better" pseudorandom numbers to me than something like MT19937 or Well* (and ISAAC is really fast after the initial cost has been paid back)

Ultimately, I think ISAAC (and ISAAC-64) _will_ get more scrutiny in the future as it's a PRNG used in Rust, for instance. I would not suggest it for default purposes, but I think having it as a non-crypto RNG in D wouldn't be a bad idea for those who want to choose to use it.

3. Better ideas for crypto PRNGs are AES-CTR or Salsa20.

I agree with this approach for the crypto section of std.random. I'd also suggest Blum Blum Shub as another thing to add. It's awfully slow, but it's probably one of the few PRNGs that is "provably strong" (that is, it's been reduced to a known hard problem).

Also, he suggested me to refer to a presentation he made last year: http://aumasson.jp/data/talks/randomness_hackepfl13.pdf

I've gone through it and it looks like excellent reference material. Note slide 76 saying: "Don't use RaaS (things like random.org) -> random bits may be shared or reused". Also, it has suggestions for entropy on Windows (CryptGenRandom) which is something that will be necessary as well.

Overall, very enlightening.

On Thursday, 12 June 2014 at 08:49:45 UTC, Chris Cain wrote:
> Well, the ultimate conclusion of the conversation with the guy is that:
> 1. ISAAC probably isn't cryptographically secure. Despite not having found any attacks, it just isn't proof of security. It's not been looked at enough to really approve of its usage for that purpose (I'm kind of agreeing with this)
>
> 2. ISAAC in his opinion probably isn't appropriate for non secure uses for much the same reason.
>
> I don't agree with that because everything I've seen for ISAAC shows that it has some really good statistical properties. Even if it's not cryptographically secure, it appears to produce "better" pseudorandom numbers to me than something like MT19937 or Well* (and ISAAC is really fast after the initial cost has been paid back)

This comes back to another necessary project -- there needs to be a decent suite of tests of randomness for D.  I think in this case it's probably best to try and wrap TestU01 etc.

In the circumstances, it sounds like ISAAC would be better placed in hap.random.generator than hap.random.crypto, though.

> Ultimately, I think ISAAC (and ISAAC-64) _will_ get more scrutiny in the future as it's a PRNG used in Rust, for instance. I would not suggest it for default purposes, but I think having it as a non-crypto RNG in D wouldn't be a bad idea for those who want to choose to use it.

Yea, this would be great.

> 3. Better ideas for crypto PRNGs are AES-CTR or Salsa20.
>
> I agree with this approach for the crypto section of std.random. I'd also suggest Blum Blum Shub as another thing to add. It's awfully slow, but it's probably one of the few PRNGs that is "provably strong" (that is, it's been reduced to a known hard problem).

Sounds good.

> Also, he suggested me to refer to a presentation he made last year: http://aumasson.jp/data/talks/randomness_hackepfl13.pdf

I'll give this a glance when I get home -- one thing I should probably do is collate a reference list for future hap.random development.

> I've gone through it and it looks like excellent reference material. Note slide 76 saying: "Don't use RaaS (things like random.org) -> random bits may be shared or reused". Also, it has suggestions for entropy on Windows (CryptGenRandom) which is something that will be necessary as well.

Sounds excellent.  I agree entirely about random.org, although I still think we should provide access to it via hap.random.device -- we should just surround it with necessary caveats.

> Overall, very enlightening.

Thanks for the research! :-)

On 6/12/2014 4:49 AM, Chris Cain wrote:
>
> Also, it has suggestions for entropy on
> Windows (CryptGenRandom) which is something that will be necessary as well.
>

It should be RtlGenRandom: It's used by CryptGenRandom, it loads/requires/involves far less unnecessary cruft, and it's well-established as *not* being something MS even *could* change/remove even if they wanted to (due to some of they ways MS themselves already rely on it):

http://blogs.msdn.com/b/michael_howard/archive/2005/01/14/353379.aspx

But this updated system entropy generator you suggest already exists:

https://github.com/D-Programming-Language/phobos/pull/2208/files#diff-713ce153554afc99a07767cc8ba940aeR1189
https://github.com/D-Programming-Language/phobos/pull/2208/files#diff-713ce153554afc99a07767cc8ba940aeR1106

It's also ready-to-use as part of DAuth (which I admit might need a new name to avoid confusion with the totally unrelated OAuth):

https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d#L51
https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d#L201

Naturally, it doesn't yet exist in hap.random because, as Joseph said, hap.random's "step one" is to match the current std.random as closely as possible. I'd be happy to put together a PR to adapt my RNG stuff above to hap.random whenever it would be desired.

On Thursday, 12 June 2014 at 17:35:39 UTC, Nick Sabalausky wrote:
> Naturally, it doesn't yet exist in hap.random because, as Joseph said, hap.random's "step one" is to match the current std.random as closely as possible. I'd be happy to put together a PR to adapt my RNG stuff above to hap.random whenever it would be desired.

Wow! Looks great :)

Thanks for all the work on that.

On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling wrote:
> I think that hap.random fixes certain fundamental design issues with std.random.  However, this needs to be put to the test "in the wild", so I'd really appreciate it if as many people as possible could try it out with their code, and report on the experience:

A few things I'd really like to hear back on, if anyone can give them a go:

  * try using hap.random via rdmd -- does it work?

  * try making a dub package dependent on hap.random --
    does it work?

  * try importing only some, not all, of the hap.random
    modules (e.g. import hap.random.generator) -- does
    this still work?

  * how does it work for people on non-Linux OS's?

Thanks!

    -- Joe

On Thursday, 12 June 2014 at 21:51:28 UTC, Joseph Rushton
Wakeling wrote:
> A few things I'd really like to hear back on, if anyone can give them a go:

... obviously I have tested the above myself, but "Works for me"
is not a valid quality control strategy ;-)

The other thing I'd really like to know about is how the
effectiveness of stuff like sample and cover is affected by the
transition to classes.  For RNGs I doubt it will be much, because
one tends to allocate and initialize the RNG quite high-up in the
application and then pass it to the internals.

By contrast something like sample() might well be called
extensively in various inner loops of the program, and the fact
that each call involves a class being allocated could be
problematic in terms of triggering the GC.

On Monday, 9 June 2014 at 18:09:21 UTC, Joseph Rushton Wakeling wrote:
> I think that hap.random fixes certain fundamental design issues with std.random.  However, this needs to be put to the test "in the wild", so I'd really appreciate it if as many people as possible could try it out with their code, and report on the experience:
>
>    * Does it run faster, slower, etc?
>
>    * Do any undesirable memory allocation issues arise?
>
>    * Is the API (broadly similar but not identical to std.random)
>      pleasant to use?

I realized that it ought to be possible to allow a more direct drop-in replacement for std.random by adding static opCalls to the classes which were previously structs.

Thoughts on this, in favour, against ... ?

On 6/19/2014 5:27 PM, Joseph Rushton Wakeling wrote:
>
> I realized that it ought to be possible to allow a more direct drop-in
> replacement for std.random by adding static opCalls to the classes which
> were previously structs.
>
> Thoughts on this, in favour, against ... ?

I'm on the fence:

Pro: Upgrade paths and backwards compatibility are great, especially for Phobos.

Con: If any semantics are changed (default ref/value passing is the only one that comes to mind), then maybe it would mask potential upgrade issues. Breakage would force users to notice the change and (hopefully) deal with it appropriately.

I don't personally see it as a big deal either way, though.

On Thursday, 19 June 2014 at 21:27:17 UTC, Joseph Rushton Wakeling wrote:
> I realized that it ought to be possible to allow a more direct drop-in replacement for std.random by adding static opCalls to the classes which were previously structs.
>
> Thoughts on this, in favour, against ... ?

I'd say do it and make it @deprecated ... in general, I think allowing a "struct like constructor" for a class is bad style (at least for std, anyway) and should be discouraged, but deprecating it makes it an easy upgrade initially and will make it easier for people to compare the old vs new way with their code.

On Friday, 20 June 2014 at 18:15:49 UTC, Nick Sabalausky wrote:
> I'm on the fence:
>
> Pro: Upgrade paths and backwards compatibility are great, especially for Phobos.
>
> Con: If any semantics are changed (default ref/value passing is the only one that comes to mind), then maybe it would mask potential upgrade issues. Breakage would force users to notice the change and (hopefully) deal with it appropriately.
>
> I don't personally see it as a big deal either way, though.

Sorry for taking so long to follow up on this, it's been a busy period ...

Anyway, here's my thinking behind the opCall idea.  One of the major shifts of the move to classes is that, suddenly, all of these entities have to be explicitly allocated.  That means that there's some measure of responsibility on the library to offer a sane default style of allocation, as appropriate for the expected use-cases and performance requirements.

Now, apart from the random number generators, all of the remaining library functionality already has helper functions which can handle this.  Currently they just "new" stuff, but there's no reason this can't be adapted as needed, possibly with the option for some kind of templating around different allocation strategies.

However, RNGs themselves don't have any corresponding helper functions, and manually writing them out would fast become annoying (imagine having to create, say, xorshift, xorshift32, xorshift64, ... etc. as helper functions to create Xorshift, Xorshift32, Xorshift64, etc., instances).

opCall provides a natural way of implementing such construction helper functions that is likely very general purpose, and encouraging it as the default use-case has a further benefit of encouraging the user to always seed their RNGs, if opCall has a form like this:

    static typeof(this) opCall(Seed)(Seed seed)
    {
        return new typeof(this)(seed);
    }

It _could_ be done as a temporary measure, deprecated from the start, to allow drop-in replacement but encourage appropriate adaptation.  But it could also be a way to serve the user with sensible default allocation strategies that minimize the potential performance impacts of the switch to classes.