Какой-то парень сказал следующее:

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

Это всегда означает, что вы не можете генерировать истинные случайные числа только с помощью компьютера. И он сказал, что когда компьютеры были эквивалентны размеру одного микропроцессора Intel 8080 (~ 6000 клапанов). Компьютеры стали более сложными, и я считаю, что утверждение фон Неймана, возможно, больше не соответствует действительности. Считайте, что реализованный программный только алгоритм невозможен. Они работают на физическом оборудовании. Истинные генераторы случайных чисел и их источники энтропии также сделаны из аппаратного обеспечения.

Этот фрагмент Java помещен в цикл:

      file.writeByte((byte) (System.nanoTime() & 0xff));

Можно создать файл данных, который я представил в виде изображения:

Вы можете видеть структуру, но также с большой случайностью. Интересно, что размер этого PNG-файла составляет 232 КБ, но он содержит 250000 пикселей серой шкалы. Уровень сжатия PNG был максимальным. Это только степень сжатия 7%, т.е. довольно не сжимаемый. Также интересно то, что файл уникален. Каждое поколение этого файла представляет собой немного другой шаблон и имеет сжимаемость ~ 7%. Я подчеркиваю это, поскольку это важно для моего аргумента. Это ~ 7 бит / байт энтропии. Это, конечно, уменьшит использование более сильного алгоритма сжатия. Но не уменьшайте ничего до 0 бит / байт. Лучшее впечатление можно получить, взяв вышеуказанное изображение и заменив его цветовой картой на случайную: -

Большая часть структуры (в верхней половине) исчезает, поскольку это были просто последовательности схожих, но незначительно разных значений. Является ли это истинным источником энтропии, созданным простым исполнением Java-программы в многозадачной операционной системе? Не равномерно распределенный генератор случайных чисел, а источник энтропии для одного? Источник энтропии, построенный из программного обеспечения, работающего на физическом оборудовании, которое просто является ПК.

дополнительный

Чтобы подтвердить, что каждое изображение генерирует свежую энтропию без фиксированного шаблона, общего для всех, было сгенерировано 10 последовательных изображений. Затем они были объединены и сжаты с помощью самого мощного архиватора, который я могу получить для компиляции (paq8px). Этот процесс исключит все общие данные, включая автокорреляцию, оставляя только изменения / энтропию.

Конкатенированный файл сжат до ~ 66%, что приводит к скорости энтропии ~ 5,3 бит / байт или 10,5 Мбит / изображение. Удивительное количество энтропии$\smile$

Дополнение 2

Были отрицательные комментарии о том, что моя методология энтропии с помощью теста на сжатие является ошибочной, давая только слабую оценку верхней границы. Итак, я запустил объединенный файл через официальный тест криптографической оценки энтропии NIST, SP800-90B_EntropyAssessment . Это так же хорошо, как и для измерения энтропии не IID. Это отчет (извините, этот вопрос становится длинным, но проблема сложная):

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

В результате NIST считает, что я сгенерировал 5,6 бит / байт энтропии. Согласно моей оценке сжатия DIY, она составляет 5,3 бит / байт, что несколько более консервативно.

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

Я предлагаю следующие ссылки, которые могут поддержать мое требование:

Есть ли стохастические модели недетерминизма в скорости выполнения программы?

WCET Анализ вероятностных жестких систем реального времени

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

Параллели с квантовым принципом энтропийной неопределенности

Запись в блоге Алексея Шипилёва о хаотическом поведении nanoTime (). Его точечный сюжет не отличается от моего.

Тот факт, что вы не видите шаблон, не означает, что шаблон не существует. Тот факт, что алгоритм сжатия не может найти шаблон, не означает, что шаблон не существует. Алгоритмы сжатия не являются серебряными пулями, которые могут волшебным образом измерить истинную энтропию источника; все, что они вам дают, это верхняя граница количества энтропии. (Аналогично, тест NIST также дает вам только верхнюю границу.) Хаос - это не случайность.

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

Там являются основания полагать , что мы , вероятно , может получить некоторое количество случайности за счет использования тактового джиттера и дрейфа между двумя аппаратными часами , но это тонкая и сложная, так что вы должны быть осторожны. Я бы не советовал пытаться реализовать самостоятельно. Вместо этого я бы предложил вам использовать высококачественный источник энтропии (обычно реализуемый в большинстве современных операционных систем). Для получения дополнительной информации см. Также Википедию , hasged и /crypto//q/48302/351 (о которых вы, похоже, уже знаете).

Наконец, комментарий к вашему открывалке:

«Любой, кто пытается генерировать случайные числа детерминистскими средствами, конечно, живет в состоянии греха».

Это всегда означает, что вы не можете генерировать истинные случайные числа только с помощью компьютера.

Нет, обычно это не так, и это не то, что говорится. Это говорит о том, что вы не можете генерировать истинные случайные числа детерминистскими средствами . Можете ли вы сделать это на компьютере, зависит от того, является ли компьютер детерминированным или нет. Если компьютер детерминирован или ваша программа использует только детерминированные операции, вы не сможете. Однако многие компьютеры содержат недетерминированные элементы, и если ваша программа использует их, требуется более подробный анализ, прежде чем вы сможете решить, можно ли их использовать для генерации случайных чисел. В вашем случае nanoTime()это недетерминированный.

Если вы используете какой-то аппаратный источник энтропии / случайности, вы не «пытаетесь генерировать случайность детерминистскими средствами» (мой акцент). Если вы не используете какой-либо аппаратный источник энтропии / случайности, то более мощный компьютер просто означает, что вы можете совершать больше грехов в секунду.

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

Цитата - хотя содержательная - по сути тавтология. Там нет ничего, что можно было бы опровергнуть, и нет никакой возможной эволюции аппаратного обеспечения, которая могла бы сделать это уже не правдой. Дело не в аппаратном обеспечении, а в определении детерминированного алгоритма. Он просто замечает, что детерминизм и случайность несовместимы. Для любого детерминированного алгоритма все его поведение предсказывается его начальными условиями. Если вы думаете, что нашли исключение, вы не понимаете, что значит быть детерминированным.

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

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

Когда вы интерпретируете «жизнь в состоянии греха» как «бессмыслицу», тогда это совершенно правильно.

Вы использовали довольно медленный метод System.nanoTime()для генерации довольно слабой случайности. Вы измерили некоторые

... скорость энтропии ~ 5,3 бит / байт ...

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

Вместо этого попробуйте заполнить массив криптографическим хешем, таким как MD5. Вычислять последовательность, как md5(0), md5(1), ...(из каждого значения, взятого один или несколько байтов, это не имеет значения). Вы не получите никакого сжатия вообще (да, MD5 сломан, но все еще достаточно хорош, чтобы произвести несжимаемые данные).

Можно сказать, что энтропии нет вообще, но вы бы измеряли 8 бит / байт.

Когда вам действительно нужно что-то случайное, вам нужно не только использовать HW-источник, вы также должны знать определенную нижнюю границу того, сколько энтропии оно действительно производит. Хотя, скорее всего, есть некоторая случайность nanoTime(), я не знаю ни одной нетривиальной нижней границы.

Когда вам нужна случайность для криптографии, вам действительно нужно прибегнуть к чему-то, предоставленному вашей ОС, вашим языком или хорошей библиотекой. Такие провайдеры собирают энтропию из нескольких источников и / или выделенных HW, и в такие оценки энтропии была проведена довольно большая работа.

Обратите внимание, что вам обычно не нужна энтропия. Хороший (детерминированный) PRNG, инициализированный несколькими случайными байтами, пригоден для криптографии и, следовательно, также для всего остального.

Я думал, что я буду вмешиваться в значение «случайного». Большинство ответов здесь говорят о выходе случайных процессов , по сравнению с выходом детерминированных процессов. Это совершенно хорошее значение слова «случайный», но оно не единственное.

Одна проблема с выходными данными случайных процессов заключается в том, что их трудно отличить от выходных данных детерминированных процессов: они не содержат «записи» о том, насколько случайным был их источник. Крайним примером этого является известный комикс XKCD, в который всегда возвращается генератор случайных чисел 4с комментарием кода, утверждающим, что он случайный, потому что он был получен в результате броска кубика.

Альтернативный подход к определению «случайности», называемый колмогоровской сложностью , основан на самих данных, независимо от того, как они были сгенерированы. Колмогоровская сложность некоторых данных (например, последовательность чисел) - это длина самой короткой компьютерной программы, которая выводит эти данные: данные «более случайны», если они имеют более высокую колмогоровскую сложность.

Использование вами алгоритмов сжатия, таких как PNG, и сравнение длины до и после сжатия аналогично идее сложности Колмогорова. Однако колмогоровская сложность позволяет кодировать данные в виде программы на любом языке программирования, полного по Тьюрингу, а не в ограниченном формате, таком как PNG; «распаковка» таких кодировок (программ) выполняется путем их запуска, что может занять произвольное количество времени и памяти (например, больше, чем доступно в нашей ничтожной вселенной).

Теорема Райса говорит нам, что мы, в общем, не можем различить программы, которые зацикливаются навсегда, и программы, которые выводят наши данные. Следовательно, очень трудно найти колмогоровскую сложность некоторых данных: если мы запишем программу, которая генерирует эти данные, на самом деле может быть более короткая программа (т.е. более низкая сложность), но мы ее не заметили, потому что не могли отличить его от бесконечной петли. Следовательно, сложность Колмогорова неисчислима, хотя, если бы мы знали числа Занятого Бобра, мы могли бы вычислить их, используя те, чтобы ограничить количество времени, которое мы проверяем каждой программой.

В случае данных вашего примера, чтобы найти его колмогоровскую сложность (т. Е. «Внутреннюю случайность»), нам нужно найти кратчайшую детерминированную программу, которая выводит ту же последовательность байтов и принимает ее длину.

Теперь мы можем ответить на ваш вопрос с точки зрения колмогоровской сложности, и мы находим, что цитата верна: мы не можем генерировать случайные числа (высокая колмогоровская сложность) детерминистскими средствами.

Почему бы нет? Давайте представим, что мы пишем небольшую компьютерную программу и используем ее для генерации последовательности случайных чисел. Должна применяться одна из следующих ситуаций:

• Мы генерируем огромное количество продукции. Однако, поскольку мы знаем, что этот вывод генерируется небольшой программой, вывод (по определению) имеет низкую колмогоровскую сложность, и, следовательно, он не является «случайным» в этом смысле.
• Мы генерируем так мало чисел, что их запись заняла бы примерно столько же или даже меньше битов, чем запись нашей короткой генерирующей программы. В этом случае числа относительно несжимаемы, что указывает на то, что они довольно случайны в смысле Колмогорова. Однако, поскольку объем вывода сопоставим с тем, что мы вкладываем (исходный код программы), можно сказать, что программа не «генерировала» случайность, мы сделали это, выбрав эту программу. В конце концов, в этом случае наша генерирующая программа могла бы быть просто списком этих точных чисел (например print([...])).

В любом случае, мы не «генерируем» больше случайности, чем вкладываем («случайность» исходного кода нашей генерирующей программы). Мы могли бы попытаться обойти это, используя более длинную генерирующую программу, чтобы избежать вывода, имеющего короткий генератор, но есть только два способа сделать это:

• Систематически «раздувать» код каким-то образом. Однако сложность Колмогорова не заботится о конкретной программе, которую мы использовали для генерации данных: она заботится только о том, какая из генерирующих программ самая маленькая. Систематическое раздувание не добавляет колмогоровской сложности, потому что такие шаблоны в коде сами могут быть сгенерированы с очень небольшим объемом кода. Например, если мы возьмем run(shortGenerator)и добавим целый груз систематического раздувания, чтобы получить run(bloatedGenerator), короткий генератор все еще существует в форме run(addBloat(shortGenerator)).
• Добавьте раздувание несистематически , то есть без каких-либо шаблонов, чтобы addBloatфункция в конечном итоге оказалась раздутой так же, как и сам код. Тем не менее, отсутствие шаблонов - это именно то, что делает что-то случайным (высокая сложность по Колмогорову). Следовательно , вздутие программы генерирующей таким способа действительно увеличить хаотичность (Колмогоров сложности) на выходе, но это также увеличивает количество случайности (сложность Колмогорова) , что мы должны предоставить в виде исходного кода. Следовательно, все еще мы обеспечиваем «случайность», а не программу. В приведенном выше примере простого написания print([...])добавление несистематического раздувания эквивалентно простому написанию большего количества «случайных» чисел в этом жестко закодированном списке.

Сжатие не является точным тестом на случайность, и при этом не смотрит на изображение и не говорит «что выглядит случайным».

Случайность проверяется эмпирическими методами . Фактически существуют наборы специально разработанных программ / алгоритмов для проверки случайности, например TestU01 и тесты Diehard .

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

Если бы вы исследовали свое изображение попиксельно, вы, скорее всего, нашли бы много коротких паттернов с возрастающей ценностью перед внезапным падением. Если бы вы создали график со значением x, являющимся номером выборки, а значением y, являющимся значением, полученным из функции «random», вы, скорее всего, обнаружили бы, что ваши данные на самом деле выглядят как пилообразная волна:

Это шаблон, созданный значениями, которые увеличиваются при модульной арифметике (примером которой являются ваши вычисления: время увеличивается почти с постоянной скоростью и & 0xFFдействует как mod 256).

Вы путаете понятие случайных чисел с «числами, которые кажутся случайными».

Чтобы понять цитату фон Неймана, мы должны понять, что значит «генерировать случайные числа». Ответ Варбо связывает превосходный XKCD с этой целью:

Когда мы говорим о случайных числах, мы не говорим о самих значениях. Очевидно, что 4 не более случайна, чем 3. Мы говорим о способности третьей стороны предсказывать это значение лучше, чем случайный шанс. Случайное число - это число, которое не предсказуемо. Иногда мы добавляем условия к этому. Криптографически безопасный генератор псевдослучайных чисел (CSPRNG) генерирует числа, которые не могут быть предсказаны лучше случайного случая, если злоумышленник не знает начальное число / ключ, но если мы говорим о действительно случайных числах (не псевдослучайных), обычно это число, которое нельзя предсказать, даже с полным знанием системы, включая любые ключи.

Теперь ваш пример, как отмечали многие, не является детерминированным. Программа не указывает, из какого значения получается System.nanoTime(). Таким образом, он не относится к тому же классу, что и использование CSPRNG для генерации псевдослучайных чисел. Первый может быть недетерминированным, а второй - детерминированным, если значение ключа является детерминированным. Первый содержит операции, которые не определены как имеющие детерминированные значения.

Тем не менее, вы заметите, что я сказал, что это может быть недетерминированным. Имейте в виду, что System.nanoTime()он не предназначен для предоставления значений для этой цели. Это может быть или не быть достаточно недетерминированным. Приложение может настроить системные часы так, чтобы вызовы для System.nanoTime()всех происходили с кратностью 256 наносекунд (или близко). Или вы можете работать в Javascript, где недавние эксплойты Spectre заставили основные браузеры намеренно уменьшить разрешение своих таймеров. В этих случаях ваши «случайные числа» могут стать весьма предсказуемыми в средах, которые вы не планировали.

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

Все зависит от того, что вы намерены. Если вы шифруете свои любовные письма Спанч Бобу, чтобы ваша сестра не могла их прочитать, требования к так называемым случайным числам довольно низки. System.nanoTime()используется, как вы, вероятно, достаточно хорошо. Если вы защищаете ядерные секреты от передового иностранного государства, которое активно ищет их, вы можете рассмотреть возможность использования оборудования, которое предназначено для решения этой проблемы.

Я не думаю, что вы поняли претензию. Дело в том, что если существует детерминированная процедура для генерации «случайного» ряда чисел (или чего-то еще, на самом деле), то поиск шаблона - просто задача поиска этой процедуры!

Следовательно, всегда существует детерминированный метод для предсказания следующего целого числа. Это именно то, чего мы не ожидаем, если примем случайность!

Любая достаточно сложная детерминированность неотличима от стохастичности.

--Из пользователя Wrzlprmft

Следовательно, даже если что-то выглядит случайным, с какой стати мы можем смоделировать это как «случайное», если у нас есть детерминированная процедура для его генерации?

Это, я думаю, ключевая проблема. Вы только показали некоторую форму неразличимости PRNG и «истинной случайности».

Однако то, что эти понятия равны, следовательно, не следует. В частности, случайность - это математическое, теоретическое понятие. Выше мы уже показали, что теоретически рассмотрение PRNG как «истинной случайности» приводит к противоречию. Следовательно, они не могут быть равны.

Я думаю, что другие уже указали на это, но это не то, что подчеркивает, поэтому позвольте мне также добавить к обсуждению.

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

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

Более того, на самом деле, вы только что сделали это , но это не так очевидно на первый взгляд.

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

Теперь посмотрим на ваш алгоритм. На чем это основано? Сколько у вас государства? Это детерминированный?

  file.writeByte((byte) (System.nanoTime() & 0xff));

Давайте проигнорируем file.writeи любые проблемы очистки буферов, ожидания ввода-вывода (вы пытались добавить сильный шум на кабели жесткого диска на мгновение? Нет? Эй, вы могли бы это сделать. Эй, тогда это недетерминировано! :)), и давайте сосредоточимся на источнике, это более важно.

Время является своего рода состояние. Это меняется, но большинство из них одинаковы. Вот почему вы пытались обойти это и взяли & 0xFF, чтобы отбросить большую часть штата. Но вы не отбросили все это, какое-то состояние предыдущего чтения может просочиться в следующее, так что оно определенно не является полностью недетерминированным *)

Но мы не заинтересованы в этом. Чтобы «доказать», что цитата неверна:

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

Вам нужно доказать это детерминистскими средствами.
Что нас интересует, так это то, является ли ваш алгоритм полностью детерминированным ?

..И очевидно, что это не так.

  System.nanoTime() & 0xff

Это измерение времени. Время и измерение . Часть измерения может сделать ее детерминированной, если значение кэшируется. Я предполагаю, что это не так, иначе эта функция не имела бы смысла. Затем, если он читается на лету из источника, у нас есть значение на основе времени. Поскольку ( я снова полагаю ), вы не запускали это на выделенном оборудовании для одной задачи, то иногда может происходить переключение контекста. Даже если у вас было выделенное аппаратное обеспечение для одной задачи, измерение времени может быть недетерминированным из-за смещения температуры / влажности в источнике времени, времени синхронизации шины и т. Д.

Я полностью согласен, что я раздражен здесь. Дрифты не будут такими большими, чтобы оказывать большое влияние (хотя на самом деле nanotimeони могут быть). Что еще более важно, nanotimeэто должно быть быстро. Он не читает из источника в реальном времени. Он основан на внутреннем количестве команд / циклов процессора. Это на самом деле детерминировано, если вы гарантируете отсутствие переключения контекста.

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

*) Интересно, что вы, вероятно, могли бы увеличить реальную случайность, если бы вы пошли жестким путем. Делайте & 0x01, по крупицам, и ожидайте в потоке заметное время, прежде чем читать каждый бит. Генерирование данных таким образом было бы невероятно долгим, но я бы даже сказал, что это можно считать почти действительно случайным, если вы работаете в не-ОСРВ, а также IFF в каждое «заметное время» достаточно высоко, чтобы обеспечить ОС либо ушла в спячку, либо переключилась на другую задачу.

Я думаю, что ответ, который вам нужен, начинается с этого комментария, который вы сами сделали в ответ на другой ответ:

Этот паттерн является результатом взаимодействия Java, JVM, ОС, кэшей CPU +, жесткого диска, музыки транса, которую я передавал, которая использует циклы CPU / RAM и все что между ними. Шаблон просто возникает из одной строки кода Java внутри цикла for / next. Значительная часть энтропии происходит от базовых аппаратных схем.

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

Вы использовали компьютер, неотъемлемая часть которого является детерминированной, но энтропия возникла из внешних недетерминированных (или, по крайней мере, недетерминированных для всех практических целей и задач на данный момент) источников: вы или взаимодействующий внешний мир с компьютером (и в меньшей степени любые физические недостатки в компьютерном оборудовании, которые могут повлиять на время вещей).

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

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

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

Чтобы добавить к предыдущим ответам, вот простой способ обдумать этот вопрос.

Все дело в разнице между случайным и детерминированным . Мы приедем к фон Нейману и тому, что он говорил, потом.

Случайные числа

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

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

• «Хорошие» источники - это вещи, похожие на ожидание процесса радиоактивного распада или другого квантового процесса, который по своей природе непредсказуем. Выход из термочувствительного полупроводника. Случайный шум в диоде или другом электрическом материале. Подсчет фотонов от Солнца.

• Помимо этого, мы также можем добавить некоторые, которые мы считаем «неплохими», которые помогают, поскольку они не имеют к ним никакого отношения: ожидание следующего щелчка мышью или сетевого пакета. Последний бит микротайма при записи следующего файла. Вывод «известной, но математически довольно случайной» функции генератора псевдослучайных чисел. Предыдущая энтропия от предыдущего использования случайных чисел.

Цель здесь состоит в том, чтобы получить число, которое все еще не может быть предсказано , независимо от того, что вы знаете во вселенной , и статистически с такой вероятностью это будет так, как это, без математически обнаруживаемого паттерна, смещения или предсказуемости, и без корреляции с событием, которое можно отслеживать и использовать для прогнозирования. (Или если это связано с событием, то это делается таким образом, что соединение становится невероятно ненадежным, например, «только наносекундная цифра времени последнего щелчка мыши»)

Детерминированные числа

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

Так, например, если вы выберете число, скажем, от 1 до 10 миллионов, запишите его в двоичном формате и неоднократно «хешируете» его, вы получите довольно случайную последовательность цифр. Это почти случайно - но на самом деле это совсем не случайно. С помощью алгоритма и любого состояния можно предсказать, каким будет следующее число.

Мы называем это «псевдослучайным», потому что он выглядит и выглядит в основном случайным, даже если это не так.

Вот хороший пример. Подумайте об этой последовательности трехзначных «случайных чисел»: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217. Допустим, я вам говорю Я могу генерировать миллион чисел таким же образом. Затем вы можете передать статистику, который подтвердит (скажем), что они распределены поровну или что бы это ни было. Там нет очевидного предсказуемого паттерна. Они выглядят довольно случайно, верно? Но теперь я говорю вам, что они на самом деле

500-ая + цифра числа Пи, сгруппированная в 3 с.

Вдруг, однако случайный

цифры Пи

может быть, вы можете сразу предсказать, что следующие 2 числа будут 986 и 094.

Чтобы было ясно, я не знаю точно, насколько случайно

цифры Пи

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

Между

Между ними есть целый ряд «вещей, которые выглядят случайными и часто в некоторой степени случайными». Чем больше случайности и почти случайности можно смешивать, тем меньше вероятность того, что выходные данные будут иметь возможность обнаруживать любой шаблон или любой выходной сигнал, математически прогнозируемый.

Вернемся к фон Нейману и вашему вопросу

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

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

Теперь мы можем перефразировать ваш вопрос следующим образом: «Вывод моего (или любого современного) компьютера может выглядеть и вести себя совершенно случайно, значит ли это, что цитата фон Неймана устарела и неверна?»

Проблема еще это: Даже если выход вашего компьютера может выглядеть и вести себя случайным образом , он все еще не может быть действительно случайным образом . Если он рассчитывается только детерминистически, это означает, что нет ничего, что не могло бы предопределить причинно-следственную связь с получением следующего числа (именно это означает «детерминистический» в этом смысле). Мы начинаем с некоторых существующих данных (известных), применяем известный процесс (сложный, грязный или любой другой) и получаем то, что кажется новым «случайным числом». Но это не случайно, потому что процесс был детерминированным.

Если вы говорите, что ваш метод будет включать в себя настоящий аппаратный генератор случайных чисел, чтобы исправить это (например, случайное число, генерируемое в результате радиоактивного распада или шума в полупроводнике), то ваш ответ теперь может быть случайным - но ваш метод по определению больше не является детерминированным именно потому , что вы больше не можете предсказать результаты (или эффекты), учитывая входные / исходные данные (причины) .

Фон Нейман выигрывает в обоих направлениях, почти по определению!