Random number generator protection: BCryptGenRandom vs RNGCryptoServiceProvider
For those in a hurry, this is NOT related to the controversial Dual_EC_DRBG
internally set NIST SP800-90A.
About two RNGs:
-
Based on Microsoft BCRYPT based on C API.
BCryptGenRandom
NIST SP800-90A compliantCTR_DRBG
(i.e. uses the approved AES block cipher to generate random bits). However, it is not clear if it is using a hardware random source as a seed (or part of a seed) ... -
Microsoft.NET
RNGCryptoServiceProvider
is C #. Have a look at the .NET source code (or here ), I can see that this is calling a C ++ methodCapiNative.GenerateRandomBytes()
. There should have been a P / Invoke for the C # => C ++ transition, but I couldn't find it anywhere in the source code. So I don't know how this is implemented.
Does anyone have more information on these two random number generators? Do both of them use random HW seeds (either through diode noise on old networks, or controversial RDRAND
on recent internet).
PS: Not sure if it should be on Security, StackOverflow or Cryptography ...
source to share
Microsoft .NET RNGCryptoServiceProvider is C # based
Not exactly, the managed framework class is just a thin wrapper over the Crypto api built into Windows. All of the System.Security.Cryptography classes whose name ends with ServiceProvider
are wrappers for the built-in API. Those whose name ends with Managed
are implemented in pure managed code. Accordingly, classes XxxServiceProvider
use FIPS validated cryptography, but classes XxxManaged
do not.
It's not really pinvoke, it uses a common mechanism to call directly in CLR code. Jitter accesses the table with C ++ function addresses and directly compiles the CALL code instruction. The mechanism is described in this answer . While it is not possible to look at the actual code, it is not included in the SSCLI20 distribution and has been modified to use the QCall mechanism in .NET 4.
So the claim is unprovable, but it is likely that the RNGCryptoServiceProvider and the algorithm provider you pass to BCryptGenRandom () are using the same source for random numbers. Which on Windows is an unnamed exported function in advapi.dll, this answer gives a great summary of what it uses.
If this really concerns you, and you want a reliable source of information, then don't take advice from the free Q + A website for your security needs. Please contact Microsoft support.
source to share
Microsoft RNGCryptoServiceProvider
is mentioned in RFC 4086 :
7.1.3. Windows CryptGenRandom
Microsoft's recommendation to users of widely deployed Windows operating systems typically use the CryptGenRandom pseudo-random number dialing service with the CryptAPI cryptographic service provider. This refers to a cryptographic service provider library, a pointer to a buffer with which the caller can provide entropy and into which the generated pseudo-randomness is returned, and an indication of the number of random octets.
The Windows CryptAPI Cryptographic Service Provider stores a seed state variable with each user. When CryptGenRandom is called, this is combined with any randomness provided in the call and with various system and user data such as process id, thread id, system clock, system time, system counter, memory status, free disk clusters, and user state hashing ... All data is sent to SHA-1, and output is used to pinch the RC4 keystream. This key stream is used to produce the requested pseudo-random data and update the user's seed state variable.
".NET" Windows users will probably find it easier to use the RNGCryptoServiceProvider.GetBytes Method Interface.
source to share