Someone already reported this as a bug and it seems to already be fixed here: https://github.com/Microsoft/WinObjC/issues/36
@ubergeek42 is correct, this is currently fixed on master: https://github.com/Microsoft/WinObjC/blob/master/Frameworks/CoreFoundation/CFMisc.mm#L39-L52
Do I mistake or when GenerateRandomNumber fail it return always 0 ? If it’s the case it looks like https://xkcd.com/221/
explanation for cryptographically challenged?
I’m also cryptographically challenged, but it seems based on the bug report I linked in my other comment that arc4random is supposed to be a cryptographically secure random number generator, and calling rand() a few times doesn’t make that true.
For example: http://marc.info/?l=openbsd-tech&m=141773078029373&w=2
ARC4 is a common name for RC4. arc4random is an API function for cryptographically strong random numbers, which was originally based on the RC4 key scheduling algorithm. I think arc4random was actually introduced by OpenBSD. But, because RC4 is effectively broken, implementations of arc4random don’t typically use it.
In relation to the referenced code on Github, rand() is a function which is “pseudorandom” which means that it’s likely based on a known algorithm for generating “random” numbers – perhaps something like a Linear Congruential Generator.
Yes, rand() is almost always implemented with a LCG.
FreeBSD arc4random() implementation actually uses arc4, and I thus assume OS X does too. Of course, the OpenBSD implementation is chacha based.
Fwiw Linux (or rather, GNU) switched a few years ago to make rand() use the same algorithm as random(), which uses a different method. The motivation seems to have been that the LCG implementation of rand() produced pseudorandomness that was unequally distributed among the bits.
There is nothing wrong with using a LCG. Many are decent, like Park-Miller / MINSTD. It’s not hard to do better than the classic next = next * 1103515245 + 12345 that lots of libc implementations used for a while.
next = next * 1103515245 + 12345
Once you move past the “not awful” domain, the quality of a PRNG doesn’t really matter until you make the leap to cryptographically secure PRNGs.
I love that user ssl posted this.