Call RtlGenRandom() instead of CryptGetRandom() on Windows

[cpeterso]

On Windows, os.rs can call RtlGenRandom() directly instead of jumping through hoops to obtain an HCRYPTPROV handle from CryptAcquireContextA()/CryptReleaseContext() before calling CryptGenRandom() (which just calls RtlGenRandom() itself).

Chromium, boringssl and ring, and Firefox all call RtlGenRandom() directly (which is actually exported from advapi32.dll as SystemFunction036()).

[alexcrichton]

The documentation for RtlGenRandom has a scary warning at the top:

The RtlGenRandom function is available for use in the operating systems specified in the Requirements section. It may be altered or unavailable in subsequent versions. Instead, use the CryptGenRandom function.

That seems... worrying?

[GabrielMajeri]

I don't think there are any reasons to worry about using this function:

• the function is used by the rand_s function from the CRT. A lot of applications statically link the CRT, Microsoft wouldn't risk removing this function and break them.

• on this Firefox Bugzilla thread, a commenter said:

I've mailed a dev inside Microsoft to see what's the story behind this, as the warning on RtlGenRandom's documentation is not really founded on a realistic scenario and causes confusion: what's the deal: will they change it or not.

The response:

I got word back from Microsoft. The unofficial word is that it's not very likely that RtlGenRandom will change, also due to the reliance of their own rand_s function in the CRT.

Furthermore, from that same thread:

There's actually an advantage of using RtlGenRandom over CryptGenRandom which is that RtlGenRandom just does the RNG work and nothing else, while CryptGenRandom requires more overhead because it loads the whole CryptAPI code.

[alexcrichton]

sounds convincing to me!