Естественно для серьезного применения желательно комбинировать несколько независимых источников.
Еще можно поиграть в теорию заговора и предположить, что производители звуковых карт в сговоре с ...(подставить нужное) вычищают случайность и подставляют предсказуемую последовательность ПСЧ)
Согласен, я писал что структура случайности зависит даже от софтовых настроек (они могут включить предобработку внутри карты). Поэтому статью не стоит рассматривать скорее, как направление, в котором надо копать, а не безапелляционное руководство к действию. Условия в которых описанный подход работает с моими звуковыми картами четко указаны, я не отрицаю возможность существования других ситуаций)
Если установлено, что случайность содержится в битах {5,6,7}, то проще к ним применить туже процедуру, что и в статье (возможно лучше рассматривать их три независимых канала, надо тестировать). Т.к. взятие среднего все равно не обеспечит равномерного распределения.
Если же известно что в потоке есть случайность но не известно в каких именно битах (или она плавает между битами), то надо брать все целиком и скармливать SHA1)
1. Функция распределения у звуковой карты нам не известна. Так же не известно является ли она постоянной во времени или зависит от температуры/ветра на Марсе или еще чего.
2. Но вы не отрицаете, что он стремится к нулю для случайных величин? Как минимум он позволяет отсеять величины явно не случайные. Более сложные статистические тесты приведены по ссылкам.
На Питоне короче, легче и быстрее вносить изменения, т.к. это эксперимент и параметры приходится варьировать) Считайте, что прототип мы пишем на Питоне, чтобы потом реализовать сразу как надо на С++ (если нужна скорость например, или хотим сделать библиотеку)
Как теорфизик (еще и работающий по специальности) я бы сказал, что в нашей жизни всё случайно. Но вероятность разных событий естественно подчиняется физическим законам (а касательно жизни — здравому смыслу). Т.е. если учиться в университете умным 100% не станешь, но вероятность поумнеть там значительно выше, чем если вместо универа лежать на диване и смотреть сериалы.
Данная имитация полезна тем, что просто интересна) Ну и в принципе, после должной проверки может использоваться как дополнительный источник случайности там, где она нужна (в криптографии например).
В качестве развлечения, я реализовал шифрование RC4, где данные шифруются случайным ключом (полученным как в статье), а ключ шифруется паролем. Таким образом обходится уязвимость RC4 к повторному использованию одного пароля.
Скажем так, в том месте статьи, где это утверждение стоит, его можно считать гипотезой (достаточно разумной :) ).
А в целом по статье это результат эксперимента) В случае аудиокарты (моих двух) и записи «тишины», 2-3-4 бит не могут нести случайные данные, так они банально всегда равны нулю, а меняется только самый младший.
Равномерность распределения это не проблема, она практически ни в одном аппаратном ГСЧ не достигается «из коробки». У меня равномерность лечится алгоритмом фон Неймана, можно также криптографические хеши использовать, но только после того как установлена случайность источника.
randomsound — судя по описанию, передает данные в random pool ядра линукса. Это специальная часть ядра, которая может принимать «случайность» данных в любых формах из разных источников. Внутри (ядра линукса) применяется ряд алгоритмов, чтобы равномерно распределить «случайность» среди битов массива (кажется там MD5 или что-то на подобии), также ведется учет имеющихся битов случайности.
Единственная возможная проблема (в код не смотрел) может быть, что надо каким-то образом оценить «количество случайности» перед передачей данных ядру.
cyorand — для именно исследования поведения аудиокарт на мой взгляд подходит слабо, т.к. там применен некий доморощенный алгоритм смешения исходных данных, который случайности не добавляет (ибо это не возможно:) ), а картину запутывает. Интересно было бы посмотреть на тесты более продвинутыми пакетами типа diehard или NIST.
Если вырезать алгоритм смешивания, то получится аналог описанного в статье, только на Си. Я люблю Си и первый вариант моей программы тоже был на нем, но он не так нагляден, как Питон (желающие могут заглянуть в код cyorand).
В смысле группировать сэмплы и брать по одному биту от группы? Это немного лишнее усложнение, приведенный пример unbiasing'а хоть и примитивный, но надежный. Если он не даст равномерное распределение, то последовательность не случайная 100%.
Сказанное справедливо для записи «тишины». Если есть сигнал, то можно/лучше не делать unbiasing, а замешать порцию данных чем-нибудь вроде SHA1 и использовать как seed для качественного генератора ПСЧ.
Еще можно поиграть в теорию заговора и предположить, что производители звуковых карт в сговоре с ...(подставить нужное) вычищают случайность и подставляют предсказуемую последовательность ПСЧ)
Если подумать то в практическом отношении разницы нет) В науке это называется «теория скрытых параметров». См. ru.wikipedia.org/wiki/Теория_скрытых_параметров
Если установлено, что случайность содержится в битах {5,6,7}, то проще к ним применить туже процедуру, что и в статье (возможно лучше рассматривать их три независимых канала, надо тестировать). Т.к. взятие среднего все равно не обеспечит равномерного распределения.
Если же известно что в потоке есть случайность но не известно в каких именно битах (или она плавает между битами), то надо брать все целиком и скармливать SHA1)
2. Но вы не отрицаете, что он стремится к нулю для случайных величин? Как минимум он позволяет отсеять величины явно не случайные. Более сложные статистические тесты приведены по ссылкам.
Данная имитация полезна тем, что просто интересна) Ну и в принципе, после должной проверки может использоваться как дополнительный источник случайности там, где она нужна (в криптографии например).
В качестве развлечения, я реализовал шифрование RC4, где данные шифруются случайным ключом (полученным как в статье), а ключ шифруется паролем. Таким образом обходится уязвимость RC4 к повторному использованию одного пароля.
А в целом по статье это результат эксперимента) В случае аудиокарты (моих двух) и записи «тишины», 2-3-4 бит не могут нести случайные данные, так они банально всегда равны нулю, а меняется только самый младший.
Равномерность распределения это не проблема, она практически ни в одном аппаратном ГСЧ не достигается «из коробки». У меня равномерность лечится алгоритмом фон Неймана, можно также криптографические хеши использовать, но только после того как установлена случайность источника.
Единственная возможная проблема (в код не смотрел) может быть, что надо каким-то образом оценить «количество случайности» перед передачей данных ядру.
cyorand — для именно исследования поведения аудиокарт на мой взгляд подходит слабо, т.к. там применен некий доморощенный алгоритм смешения исходных данных, который случайности не добавляет (ибо это не возможно:) ), а картину запутывает. Интересно было бы посмотреть на тесты более продвинутыми пакетами типа diehard или NIST.
Если вырезать алгоритм смешивания, то получится аналог описанного в статье, только на Си. Я люблю Си и первый вариант моей программы тоже был на нем, но он не так нагляден, как Питон (желающие могут заглянуть в код cyorand).
(о! и я опечатку заметил, ща пофиксим)
Сказанное справедливо для записи «тишины». Если есть сигнал, то можно/лучше не делать unbiasing, а замешать порцию данных чем-нибудь вроде SHA1 и использовать как seed для качественного генератора ПСЧ.