C# RNGCryptoServiceProvider 的优缺点

Pros and cons of RNGCryptoServiceProvider

提问by configurator

What are the pros and cons of using System.Security.Cryptography.RNGCryptoServiceProvidervs System.Random. I know that RNGCryptoServiceProvideris 'more random', i.e. less predictable for hackers. Any other pros or cons?

什么是使用的利弊System.Security.Cryptography.RNGCryptoServiceProviderVS System.Random。我知道这RNGCryptoServiceProvider“更随机”，即对于黑客来说更不可预测。有什么其他优点或缺点吗？

---

---

UPDATE:

更新：

According to the responses, here are the pros and cons of using RNGCryptoServiceProviderso far:

根据回复，以下是目前使用的优缺点RNGCryptoServiceProvider：

Pros

优点

• RNGCryptoServiceProvideris a stronger cryptographically random number, meaning it would be better for determining encryption keys and the likes.

• RNGCryptoServiceProvider是一个更强的加密随机数，这意味着它会更好地确定加密密钥等。

Cons

缺点

• Randomis faster because it is a simpler calculation; when used in simulations or long calculations where cryptographic randomness isn't important, this should be used. Note: see Kevin's answerfor details about simulations - Randomis not necessarily random enough, and you may want to use a different non-cryptographic PRNG.

• Random更快，因为它是一个更简单的计算；当在加密随机性不重要的模拟或长时间计算中使用时，应该使用它。注意：有关模拟的详细信息，请参阅Kevin 的回答-Random不一定足够随机，您可能希望使用不同的非加密 PRNG。

采纳答案by Charlie Martin

A cryptographically strong RNG will be slower --- it takes more computation --- and will be spectrally white, but won't be as well suited to simulations or Monte Carlo methods, both because they dotake more time, and because they may not be repeatable, which is nice for testing.

加密强的 RNG 会更慢 --- 它需要更多的计算 --- 并且会是光谱白的，但不太适合模拟或蒙特卡洛方法，因为它们确实需要更多的时间，而且因为它们可能不可重复，这对测试很好。

In general, you want to use a cryptographic PRNG when you want a unique number like a UUID, or as a key for encryption, and a deterministic PRNG for speed and in simulation.

通常，当您需要一个唯一的数字（如 UUID）或作为加密的密钥时，您希望使用加密 PRNG，以及用于速度和模拟的确定性 PRNG。

回答by Jader Dias

Yes, there is only one more. As Charlie Martin wrote System.Randomis faster.

是的，只有一个。正如查理马丁所写System.Random的那样更快。

I would like to add the following info:

我想添加以下信息：

The RNGCryptoServiceProvideris the default implementation of a security standards compliant random number generator. If you need a random variable for security purposes, you must use this class, or an equivalent, but don't use System.Random because it is highly predictable.

这RNGCryptoServiceProvider是符合安全标准的随机数生成器的默认实现。如果出于安全目的需要随机变量，则必须使用此类或等效类，但不要使用 System.Random，因为它具有高度可预测性。

For all other uses the higher performance of System.Random, and equivalent classes, are welcome.

对于所有其他用途System.Random，欢迎使用和等效类的更高性能。

回答by Yury Chaikou

System.Randomis not thread safe.

System.Random不是线程安全的。

回答by Kevin

In addition to the prior answers:

除了之前的答案：

System.Randomshould NEVERbe used in simulations or numerical solvers for science and engineering, where there are material negative consequences of inaccurate simulation results or convergence failure.?This is because Microsoft?s implementation is deeply?flawedin several respects, and they cannot (or?will?not) easily fix it due to compatibility issues.?See?this?post.

System.Random应该永远不要在模拟或数字求解理工科被使用，其中也有不准确的模拟结果或收敛failure.?This材料负面后果，因为微软？的实现深？有缺陷的几个方面，他们不能（或？将？不会）由于兼容性问题而轻松修复它。？看到了吗？这个？帖子。

So:

所以：

• If there is an adversary who shouldn?t know the generated sequence, then use RNGCryptoServiceProvideror another carefully designed, implemented and validated cryptographically strong RNG, and ideally use hardware randomness where possible.?Otherwise;

• If it is an application such as a simulation that requires good statistical?properties, then use a carefully designed and implemented non?crypto PRNG such as the Mersenne?Twister.?(A?crypto?RNG would also be correctin these cases, but often too slow and?unwieldy.)?Otherwise;

• ONLYif the use of the numbers is completely trivial, such as deciding which picture to show next in a randomized slideshow, then use System.Random.

• 如果存在不应该知道生成序列的对手，则使用RNGCryptoServiceProvider或其他精心设计、实施和验证的加密强 RNG，并在可能的情况下理想地使用硬件随机性。除此以外;

• 如果是需要良好统计特性的模拟应用程序，则使用精心设计和实现的非加密 PRNG，例如Mersenne?Twister.?（A?crypto?RNG在这些情况下也是正确的，但是经常太慢而且笨拙。）？除此以外;

• 仅当数字的使用完全无关紧要时，例如决定在随机幻灯片中显示下一张图片，然后使用System.Random.

---

---

I?recently encountered this issue very tangibly when working on a Monte?Carlo simulation intended to test the effects of different usage patterns for medical devices.?The simulation produced results that went mildly in the opposite?directionof what would have been reasonably?expected.

我最近在进行 Monte Carlo 模拟时非常明显地遇到了这个问题，该模拟旨在测试医疗设备的不同使用模式的影响。模拟产生的结果与合理的预期相反。.

Sometimes when you can?t explain something, there?s a reason behind it, and that reason could be very?onerous!

有时，当你无法解释某事时，背后有一个原因，而这个原因可能非常严重！

Here?s a plot of the p?values that were obtained over an increasing number of simulation batches:

这是在越来越多的模拟批次中获得的p值的图：

The red and magenta plots show the statistical significance of differences between the two usage models in two output metrics under study.

红色和洋红色图显示了所研究的两个输出指标中两个使用模型之间差异的统计显着性。

The cyan plot is a particularly shocking result, because it represents p?values for a characteristic of the random inputto the simulation.?(This?was?being plotted just to confirm the input wasn?t?faulty.)?The input was, of course, by design the same between the two usage models under study, so there should not have been any statistically significant difference between the inputto the two models.?Yet here I?was seeing better than 99.97%?confidence that there?wassuch a?difference!!

青色图是一个特别令人震惊的结果，因为它代表了模拟随机输入特征的p值。？（这？被绘制只是为了确认输入不是？t？错误。）？输入是，当然，在研究中的两个使用模型之间设计相同，因此两个模型的输入之间不应该有任何统计上的显着差异。但在这里，我看到了比 99.97% 更好的信心吗？有这么大的区别！！

Initially I?thought there was something wrong in my code, but everything checked out.?(In?particular I?confirmed that threads were not sharing System.Random?instances.)?When repeated testing found this unexpected result to be highly consistent, I?started suspecting?System.Random.

一开始我以为我的代码有问题，但一切都检查出来了。？（特别是我？确认线程没有共享System.Random？实例。）？当反复测试发现这个意外的结果高度一致时，我开始怀疑？System.Random.

I?replaced System.Randomwith a Mersenne?Twister implementation?—?no other changes,?—?and immediately the output became drastically different, as?shown?here:

我？替换System.Random为 Mersenne？Twister 实现？—？没有其他变化，？—？并且输出立即变得截然不同，如图所示？这里：

This chart reflects there being no statistically significant difference between the two usage models for the parameters being used in this particular test?set.?This was an expected?result.

此图表反映了在此特定测试集中使用的参数的两种使用模型之间没有统计上的显着差异。这是预期的结果。

Note that in the first chart, the vertical log?scale (on?the p?value) covers seven?decades, whereas there is only a single decade in the?second?—?demonstrating just how pronounced the statistical significance of the spurious discrepancies was!?(The?vertical?scale indicates the probability the discrepancies could have arisen by?chance.)

请注意，在第一个图表中，垂直对数标度（在p值上）涵盖了七个十年，而第二个十年中只有一个十年——这证明了虚假差异的统计显着性是！？（垂直？尺度表示差异可能偶然出现的概率。）

I?suspect what was happening was that System.Randomhas some correlations over some fairly short generator cycle, and different patterns of internal randomness sampling between the two models under test (which?had substantially different numbers of calls to?Random.Next) caused these to affect the two models in distinct?ways.

我怀疑发生的事情是System.Random在一些相当短的生成器周期内有一些相关性，并且被测试的两个模型之间的内部随机抽样的不同模式（其中？有很大不同的调用次数？Random.Next）导致这些影响了两个模型以不同的方式。

It so happens that the simulation inputdraws from the same RNG streams as the models use for internal decisions, and this apparently caused these sampling discrepancies to impact the input.?(This?was actually a lucky thing, because otherwise I?may not have realized that the unexpected result was a software fault and not some real property of the devices being?simulated!)

碰巧模拟输入来自与模型用于内部决策的相同 RNG 流，这显然导致这些采样差异影响输入。？（这实际上是一件幸运的事情，因为否则我可能没有意识到意外结果是软件故障，而不是被模拟设备的某些真实属性！）