Improve random number generation on Mac OS X and iOS

[briansmith]

Avoid using dev/urandom on Mac OS X and instead do whatever is most like using the getrandom syscall on Linux (See #148).

References:

• http://stackoverflow.com/questions/9234686/generating-random-numbers-securely-in-objective-c
• https://stackoverflow.com/questions/21734909/is-os-xs-secrandomcopybytes-fork-safe
• https://developer.apple.com/library/prerelease/ios/documentation/Security/Reference/RandomizationReference/index.html#//apple_ref/c/func/SecRandomCopyBytes

Note, in particular, that SecRandomCopyBytes was added in OS X 10.7 (Lion). According to this Rust issue, 10.7 is the lowest version supported by Rust anyway, although we should verify that hasn't changed since then.

[briansmith]

http://stackoverflow.com/questions/21734909/is-os-xs-secrandomcopybytes-fork-safe
http://opensource.apple.com//source/Security/Security-55471/libsecurity_keychain/lib/SecRandom.c
http://opensource.apple.com//source/CommonCrypto/CommonCrypto-60049/lib/CommonRandom.c

http://opensource.apple.com/source/Security/Security-55179.11/sec/Security/SecFramework.c

So, basically, it's just reading from /dev/random like we already do on Mac OS X. So, really nothing useful there. But, on iOS it seems to be required to use the provided API since (direct) access to /dev/random is blocked by the sandbox.

[briansmith]

I thought about this some more, and I think it would be good to do this on both Mac OS X and iOS. The main advantage for doing it on Mac OS X is that it would share the same file handle with the toolkit-provided function and hopefully then have less overhead in cases where Rust and non-Rust code are mixed, e.g. when a Rust lib is being included in an ObjC or C project.

[briansmith]

BTW, this can be implemented very easily by extending the definition of sysrand in ring/src/rand.rs. Can be done with 100% Rust code, I think.

[frewsxcv]

A pull request was opened for this: #398.

[briansmith]

This was done in #398 by @dirk. Thanks!