Почему использование система классов C#. Случайный вообще вместо Системы. Безопасность. Криптография. RandomNumberGenerator?
Можно записать часть программного обеспечения "бизнес-аналитики" - но это довольно сложно. Такое программное обеспечение действовало бы как своего рода менеджер путем анализа данных и предоставления рекомендаций. Думайте о программе с MBA. Выгода, чтобы на самом деле записать, что программа как этот требует не только, чтобы создающие аналитические инструменты позволили приложению автоматически просканировать через информацию, ища бизнес-шаблоны, но также и дать программе "интуицию", которую имеет большинство успешных управляющих делами. Программа, которая работает на основе строгих правил, не обязательно примет лучшие решения, просто лучшие зарегистрированные решения.
со мной связалась компания (это - пример практического применения для бизнес-аналитики), который хотел, чтобы приложение контролировало тенденции в определенных категориях рынка и использовало те тенденции для предсказания оптимальных цен на их продукты. Они продавали роскошные продукты, цены которых колебались в течение года и согласно различным экономическим показателям. Большинство их менеджеров могло сделать этот вид ценовой установки, и они надеялись автоматизировать его. Анализ потребовал, чтобы сделать, это включило бы усовершенствованную статистику, некоторый искусственный интеллект для интерпретации его, не говоря уже о способности получить данные, в которых он нуждался самостоятельно. Вводный бюджет проекта составлял $2 миллиона. Не что-то для беззаботного.
9 ответов
Скорость и намерение. Если вы генерируете случайное число и не нуждаетесь в безопасности, зачем использовать медленную криптографическую функцию? Вам не нужна безопасность, так зачем заставлять кого-то думать, что этот номер может быть использован для чего-то безопасного, когда это не так?
Помимо скорости и прочего полезный интерфейс ( NextDouble () и т. д.), также возможно создать повторяемую случайную последовательность, используя фиксированное начальное значение. Это весьма полезно, среди прочего, во время тестирования.
Random gen1 = new Random(); // auto seeded by the clock
Random gen2 = new Random(0); // Next(10) always yields 7,8,7,5,2,....
Если мне не нужна безопасность, то есть мне просто нужно относительно неопределенное значение, а не криптографически стойкое, Random имеет гораздо более простой интерфейс в использовании.
Наиболее очевидные причины уже были упомянуты, поэтому вот более неясная: криптографические ГПСЧ, как правило, необходимо постоянно заполнять «реальной» энтропией. Таким образом, если вы используете CPRNG слишком часто, вы можете исчерпать пул энтропии системы, который (в зависимости от реализации CPRNG) либо ослабит его (таким образом, позволяя злоумышленнику предсказать его), либо он будет блокироваться при попытке заполнить его пул энтропии (таким образом, становясь вектором атаки для DoS-атаки).
В любом случае, ваше приложение теперь стало вектором атаки для других, совершенно не связанных приложений, которые - в отличие от вашего - фактически жизненно зависят от криптографические свойства CPRNG.
Это актуальная проблема реального мира, BTW,
Не всем нужны криптографически безопасные случайные числа, и они могли бы получить больше от более быстрой простой команды. Возможно, еще важнее то, что вы можете контролировать последовательность чисел System.Random.
В моделировании с использованием случайных чисел, которые вы, возможно, захотите воссоздать, вы повторно запускаете моделирование с тем же начальным значением. Это может быть удобно для отслеживания ошибок, когда вы также хотите воссоздать заданный ошибочный сценарий - запуск вашей программы с той же последовательностью случайных чисел, которая привела к сбою программы.
Если вы программируете карточную онлайн-игру или лотерею, вам следует убедиться, что последовательность действий практически невозможно угадать. Однако, если вы показываете пользователям, скажем, цитату дня, производительность важнее безопасности.
System.Random гораздо более производительный, поскольку он не генерирует криптографически безопасные случайные числа.
Простой тест на моей машине, заполняющий 4-байтовый буфер случайными данными 1 000 000 раз, занимает 49 мс для Random, но 2845 мс для RNGCryptoServiceProvider. Обратите внимание, что если вы увеличиваете размер заполняемого буфера, разница уменьшается, поскольку накладные расходы для RNGCryptoServiceProvider менее актуальны.
This has been discussed at some length, but ultimately, the issue of performance is a secondary consideration when selecting a RNG. There are a vast array of RNGs out there, and the canned Lehmer LCG that most system RNGs consists of is not the best nor even necessarily the fastest. On old, slow systems it was an excellent compromise. That compromise is seldom ever really relevant these days. The thing persists into present day systems primarily because A) the thing is already built, and there is no real reason to 'reinvent the wheel' in this case, and B) for what the vast bulk of people will be using it for, it's 'good enough'.
Ultimately, the selection of an RNG comes down to Risk/Reward ratio. In some applications, for example a video game, there is no risk whatsoever. A Lehmer RNG is more than adequate, and is small, concise, fast, well-understood, and 'in the box'.
If the application is, for example, an on-line poker game or lottery where there are actual prizes involved and real money comes into play at some point in the equation, the 'in the box' Lehmer is no longer adequate. In a 32-bit version, it only has 2^32 possible valid states before it begins to cycle at best. These days, that's an open door to a brute force attack. In a case like this, the developer will want to go to something like a Very Long Period RNG of some species, and probably seed it from a cryptographically strong provider. This gives a good compromise between speed and security. In such a case, the person will be out looking for something like the Mersenne Twister, or a Multiple Recursive Generator of some kind.
If the application is something like communicating large quantities of financial information over a network, now there is a huge risk, and it heavily outweights any possible reward. There are still armored cars because sometimes heavily armed men is the only security that's adequate, and trust me, if a brigade of special ops people with tanks, fighters, and helicopters was financially feasible, it would be the method of choice. In a case like this, using a cryptographically strong RNG makes sense, because whatever level of security you can get, it's not as much as you want. So you'll take as much as you can find, and the cost is a very, very remote second-place issue, either in time or money. And if that means that every random sequence takes 3 seconds to generate on a very powerful computer, you're going to wait the 3 seconds, because in the scheme of things, that is a trivial cost.
Для разных нужд требуются разные ГСЧ. Для криптографии вы хотите, чтобы ваши случайные числа были как можно более случайными. Для моделирования методом Монте-Карло вы хотите, чтобы они равномерно заполняли пространство и могли запускать ГСЧ из известного состояния.