Call RtlGenRandom() instead of CryptGetRandom() on Windows #111
Comments
|
The documentation for
That seems... worrying? |
|
I don't think there are any reasons to worry about using this function:
The response:
Furthermore, from that same thread:
|
|
sounds convincing to me! |
This commit updates the OS random number generator on Windows to match the upstream implementation in the `rand` crate. First proposed in rust-random/rand#111 this implementation uses a "private" API of `RtlGenRandom`. Despite the [documentation][dox] indicating this is a private function its widespread use in Chromium and Firefox as well as [comments] from Microsoft internally indicates that it's highly unlikely to break. Another motivation for switching this is to also attempt to make progress on rust-lang#44911. It may be the case that this function succeeds while the previous implementation may fail in "weird" scenarios. [dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx [comments]: rust-random/rand#111 (comment)
std: Update randomness implementation on Windows This commit updates the OS random number generator on Windows to match the upstream implementation in the `rand` crate. First proposed in rust-random/rand#111 this implementation uses a "private" API of `RtlGenRandom`. Despite the [documentation][dox] indicating this is a private function its widespread use in Chromium and Firefox as well as [comments] from Microsoft internally indicates that it's highly unlikely to break. Another motivation for switching this is to also attempt to make progress on #44911. It may be the case that this function succeeds while the previous implementation may fail in "weird" scenarios. [dox]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx [comments]: rust-random/rand#111 (comment)
rand_s() is readily available in Windows's CRT, accessible through <stdlib.h>. Unfortunately its output is limited to an integer, thus requiring multiple calls to fill a large buffer. RtlGenRandom() is the other hand can accomodate any buffer size, but is a pure Windows (NT) function, not available in Windows's CRT, as it's declared in <ntsecapi.h> and available in advapi32.dll. And according to Microsoft documentation, the availability of the function is unclear, it's future too. https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom But according to Rust community the function is used in Firefox, Chromium, etc, thus it's unlikely to be removed. rust-random/rand#111 Especially since the rand_s() documentation state its uses RtlGenRandom(): https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rand-s?view=vs-2019 So rand_s() uses RtlGenRandom(), hence make use of advapi32.dll, then there's no need to use rand_s() when RtlGenRandom() is available. This patch makes use of RtlGenRandom(), and fallback to rand_s() if the former fail. Note: for newer Windows versions (>= 10), RtlGenRandom() could be replaced by newer, recommanded functions: BCryptGenRandom(BCRYPT_RNG_ALG_HANDLE, buffer, len, 0); https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom https://docs.microsoft.com/en-us/windows/win32/seccng/cng-algorithm-pseudo-handles
On Windows, os.rs can call
RtlGenRandom()directly instead of jumping through hoops to obtain anHCRYPTPROVhandle fromCryptAcquireContextA()/CryptReleaseContext()before callingCryptGenRandom()(which just callsRtlGenRandom()itself).Chromium, boringssl and ring, and Firefox all call
RtlGenRandom()directly (which is actually exported from advapi32.dll asSystemFunction036()).The text was updated successfully, but these errors were encountered: