Плюсы и минусы RNGCryptoServiceProvider

Криптографически стойкий ГСЧ будет медленнее - для этого потребуется больше вычислений - и будет спектрально белым, но он не будет так хорошо подходить для моделирования или методов Монте-Карло, потому что они делать занимают больше времени, и потому что они могут не будет повторяться, что приятно для тестирования.

В общем, вы хотите использовать криптографический PRNG, когда вам нужен уникальный номер, такой как UUID, или в качестве ключа для шифрования, и детерминированный PRNG для скорости и моделирования.

Да, есть еще один. Как писал Чарли Мартин, System.Random быстрее.

Хочу добавить следующую информацию:

RNGCryptoServiceProvider - это стандартная реализация генератора случайных чисел, совместимого со стандартами безопасности. Если вам нужна случайная переменная в целях безопасности, вы должны использовать этот класс или его эквивалент, но не используйте System.Random, потому что он очень предсказуем.

Для всех других целей приветствуется более высокая производительность System.Random и аналогичных классов.

System.Random не является потокобезопасным.

В дополнение к предыдущим ответам:

System.Random следует использовать в моделировании или численных решателях для науки и техники, где есть существенные негативные последствия неточных результатов моделирования или сбоя сходимости. Это связано с тем, что реализация Microsoft - глубоко ошибочный в нескольких отношениях, и они не могут (или не будут) легко исправить это из-за проблем совместимости. См. эта почта.

Так:

• Если есть противник, который не должен знать сгенерированную последовательность, затем используйте RNGCryptoServiceProvider или другой тщательно разработанный, реализованный и проверенный криптографически стойкий RNG, а в идеале используйте аппаратную случайность, где это возможно. Иначе;

• Если это приложение, такое как моделирование, которое требует хороших статистических свойств, затем используйте тщательно разработанный и реализованный некриптографический PRNG, такой как Мерсенн Твистер. (В этих случаях криптографический ГСЧ также будет верный, но часто слишком медленным и громоздким.) Иначе;

• ТОЛЬКО, если использование чисел совершенно тривиально, например, решение, какое изображение показывать следующим в случайном слайд-шоу, затем использовать System.Random.

Недавно я очень ощутимо столкнулся с этой проблемой, когда работал над симуляцией Монте-Карло, предназначенной для проверки эффектов различных схем использования медицинских устройств. Моделирование дало результаты, которые находятся в пределах противоположное направление, которые можно было бы разумно ожидать.

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

Вот график значений п ‑, которые были получены в увеличивающемся количестве пакетов моделирования:

Красный и пурпурный графики показывают статистическую значимость различий между двумя моделями использования в двух исследуемых выходных показателях.

Голубой график представляет собой особенно шокирующий результат, потому что он представляет значения п ‑ для характеристики случайного Вход для моделирования. (Это было нанесено на график только для подтверждения того, что входные данные не были ошибочными.) Входные данные, конечно, были изначально одинаковыми для двух исследуемых моделей использования, поэтому не должно быть статистически значимой разницы между Вход для этих двух моделей. . И все же здесь я видел более чем 99.97% уверенность, что есть было такая разница !!

Сначала я подумал, что в моем коде что-то не так, но все проверило. (В частности, я подтвердил, что потоки не совместно используют экземпляры System.Random.) Когда повторное тестирование показало, что этот неожиданный результат очень согласован, я начал подозревать System.Random.

Я заменил System.Random реализацией Mersenne Twister - никаких других изменений - и сразу же результат стал кардинально другим, как показано здесь:

Эта диаграмма отражает отсутствие статистически значимой разницы между двумя моделями использования параметров, используемых в этом конкретном наборе тестов. Это был ожидаемый результат.

Обратите внимание, что на первой диаграмме вертикальная логарифмическая шкала (по значению п ‑) охватывает семь десятилетий, тогда как во второй есть только одна декада, демонстрируя, насколько выражена статистическая значимость ложных расхождений! (Вертикальная шкала указывает вероятность того, что расхождения могли возникнуть случайно.)

Я подозреваю, что происходило то, что System.Random имеет некоторые корреляции в течение некоторого довольно короткого цикла генератора, и разные шаблоны внутренней выборки случайности между двумя тестируемыми моделями (которые имели существенно разное количество обращений к Random.Next) привели к тому, что это повлияло на две модели в различные способы.

Так получилось, что моделирование Вход основано на тех же потоках ГСЧ, которые используются в моделях для внутренних решений, и это, очевидно, привело к тому, что эти несоответствия выборки повлияли на входные данные. (На самом деле это было удачей, потому что в противном случае я, возможно, не понял бы, что неожиданный результат был ошибкой программного обеспечения, а не каким-то реальным свойством моделируемых устройств!)