I was reading about Random.Next() that for \"cryptographically secure random number suitable for creating a random password\" MSDN suggests RNGCryptoServiceProvider Class
The simplest way to answer your question might be to turn your question upside down.
Assume that the CryptoServiceProvider implementation holds all the advantages. It is just as fast and uses just as little memory as Random.Next.
Then why do both implementations exist? Why do we even Have Random.Next in the framework?
Look at what we know about each implementation. One generates cryptographically secure random number, the other makes no promises.
Which is simpler? Generating random numbers that are sufficiently random to be used in cryptography, or generating numbers that simply "look" random, but don't guarantee anything else? If there wasn't a cost associated with generating cryptographically secure random numbers, then every random number generator would do it.
You can usually assume that standard library functions are designed to do what it says on the box and do it well. Random.Next is designed to get you the next random number in a sequence of pseudo-random numbers as efficiently as possible.
CryptoServiceProvider is designed to generate random numbers strong enough to be used in cryptography, and do that as efficiently as possible. If there was a way to do this as efficiently as Random.Next, then Random.Next would use it too.
Your question seems to assume brain damage on the part of the framework designers - that they somehow designed a needlessly slow function to generate cryptographically secure random numbers, even though there was a faster way.
The fastest way to generate cryptographically secure random numbers is most likely to call the function designed by experts to generate cryptographically secure random numbers.
The rule of thumb when it comes to security and cryptography stuff:
Go with the standard way of doing it and avoid dangerous optimizations.
Use Random.Next
when you need statistically random numbers not used in security sensitive code and RNGCryptoServiceProvider
in security sensitive code. It's not as fast as Random.Next
but it has acceptable performance. You should benchmark to see the actual difference. It usually doesn't make sense to sacrifice security for performance.
The "cryptographically secure random number" generated by your example code will only ever be between 0 and 255 inclusive!
If you want to return all possible Int32
values then you should use 4 random bytes. Your code should look something like this:
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] rndBytes = new byte[4];
rng.GetBytes(rndBytes);
int rand = BitConverter.ToInt32(rndBytes, 0);
A quick benchmark on my (old-ish) machine suggests that Random.Next
is approximately 200x faster than using RNGCryptoServiceProvider
.
AFAIK a true random generator will never be implemented in C#. That can only be done with the help of hardware?
What you should be doing first and foremost, is learning the basic differences between a RNG, PRNG, and CSPRNG.
Only after this should you be deciding on what you really need, and what possible implementations could be. As a general rule, though, you should just accept what has been established and proven to be a proper implementation.
A side issue, but interesting, is your use of "true" in the question. True random numbers do not exist in hardware or software. They exist in "real life" as in radioactive decay or noise on a line, but can not be generated by a program. Thus, please note jalf's use of "pseudo-" and check jcinacio's links to wikipedia.