Обновить

Комментарии 10

вы серьёзно считаете что процессы внутри софта - могут генерировать постоянный поток случайных чисел сравнимых с реальными физическими процессами?

извините, все что вы написали - правда на 90 %.
на оставшиеся 10, это то почему я бы вам не доверил написание криптографических систем.
я не могу в рамках комментарий объяснить насколько вы не правы.
ужасно ужасно

Блин. Называйте это не "семенем", а затравкой пожалуйста. И как я понимаю, в random.org не псевдослучайные числа генерируются - а самые настоящие случайные. И шум от молний используется не как затравка - а как сам источник случайных чисел.

боюсь что хаб "криптография" упоминать в связи с этой поделкой было неосторожно :) эдак можно было предложить и ГСЧ в виде таймстемпа в миллисекундах взятого по модулю N предложить в качестве "криптографии". Во времена актуальности шифра Цезаря наверное и это выглядело бы надёжно...

Если нужен "безопасный" рандом, то посмотрите в RandomNumberGenerator.Create, он точно лучше, чем самописные решения.

Если нужен повторяемый рандом (для тестирования, например) то обычный Random всё ещё хорош.

Статья в целом непонятна (мне лично) - какую проблему решаем?

Недавно была статья тоже про самописный алгоритм ГСЧ, там приводились ссылки на тесты для проверки качества ГСЧ. Можно наверное и погуглить их.

Ну и так

Требования к качественным ГСЧ

  • Достаточно длинный период, чтобы избежать зацикливания в пределах решаемой задачи. ru.wikipedia.org*руни.рф

  • Статистическая равномерность распределения — каждое число в заданном диапазоне должно появляться с одинаковой вероятностью. sky.pro

  • Статистическая независимость — невозможность предсказать следующее число на основе предыдущих значений. sky.pro

  • Воспроизводимость — возможность воспроизвести ранее сгенерированную последовательность при известном начальном значении.

Интересно, десятичные знаки числа пи удовлетворяют этим условиям? )

Что-то подобное я также писал, но там я сориентировался больше не как на параллельных процессах, как на UB посредством состояния гонки: https://habr.com/ru/articles/715744/. При UB мы смешиваем воедино несколько параллельных функций для генерации одного байта, что с точки зрения накопления энтропии - более правильно. Но вопрос на счёт истинности вашего и моего генератора в любом случае открыт: как правильно человек написал в комментарии, это может быть генератором хаоса, у которого просто огромное количество состояний. В любом случае, даже если бы я применял такие генераторы - их следует объединять в пул с другими генераторами.

Вроде есть стандартные методы на тестирование качества случайности выдаваемых чисел. Было бы интересно их применить и сравнить с аналогичными.

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

Да потоки выполняются параллельно, но если мы берем допустим самый простой вывод в консоль, то какой результат выведется вперед мы никак не сможем узнать.

И именно на этой основе я создал свой алгоритм генерации случайного числа.

Лихо.

Дональд Э. Кнут предметно и по делу, абсолютно без лишней "воды", посвятил существенную часть второго тома своего фундаментального труда разным вопросам случайных чисел в контексте программирования. Разработчики операционных и криптографических систем тратят усилия на драйверы специальной аппаратуры и разнообразные ухищрения с наблюдениями за событиями в системе для получения энтропии. А оказывается (нет) что всё это можно было заменить, используя (якобы) случайный порядок доступа потоков к разделяемому ресурсу - консоли блокировке объекта lObj...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации