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! :-)

Reply via email to