Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Fastest implementation of a true random number generator in C#

I was reading about Random.Next() that for "cryptographically secure random number suitable for creating a random password" MSDN suggests RNGCryptoServiceProvider Class

What the speed penality? There is some fastest way to get true random numbers?

EDIT: With Random.Next() I get a new random number. And with...

byte[] randomNumber = new byte[1];
RNGCryptoServiceProvider Gen = new RNGCryptoServiceProvider();
Gen.GetBytes(randomNumber);
int rand = Convert.ToInt32(randomNumber[0]);

I get a "cryptographically secure random number" I want know if the above code is fast compared with "Random.Next()" and if there is some fast way to get same results, ok?

like image 771
Click Ok Avatar asked Mar 20 '09 23:03

Click Ok


4 Answers

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.

like image 107
jalf Avatar answered Nov 08 '22 13:11

jalf


The rule of thumb when it comes to security and cryptography stuff:

Never write your own.

Go with the standard way of doing it and avoid dangerous optimizations.

Edit to address the updated question:

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.

like image 45
mmx Avatar answered Nov 08 '22 14:11

mmx


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.

like image 45
LukeH Avatar answered Nov 08 '22 14:11

LukeH


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.

like image 38
J.C. Inacio Avatar answered Nov 08 '22 14:11

J.C. Inacio