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

И выкладывать эти данные в сеть. Их может использовать любой желающих.
Ну так это будет генератор для параноиков :) (хотя не знаю, по какому принципу там рабтает рандом...)
Насколько я помню, он слушает радио волны на определëнных частотах. (не раскрываются).
У них на сайте написано.
> На солнечном берегу моря где-нибудь в районе диких пляжей Бали, установить устройство, оцифровывающее выход с очень чувствительного микрофона.
А потом некий параноик запишет пару лет этого шума, проанализирует — и обнаружит, что он с точностью 99.9% представляет собой сумму каких-нибудь трехсот периодических функций.
и это вполне возможно — рандом может выдать и 50 подряд 1ц, и 5 миллионов единиц подряд.
и он будет рандомом — если он честный рандом
Хэш периодической функции — тоже периодическая функция.
Ок, я понял, что вас не удовлетворяет шум моря как источник энтропии )
До тех пор, пока сайт, выкладывающий данные, не окажется скомпрометирован и не начнет выкладывать данные, нужные Большому Брату.
Если открыть эти данные, число перестанет быть случайным, т.к. известно время запроса.
Спасибо за интересную статью.
У меня вопрос появился. Так как при накоплении достаточной энтропии происходит постоянное обновление внутреннего ключа, значит если скормишь один и тот же seed получатся разные последовательности? Получается fortuna нельзя использовать в качестве классического поточного шифра?
И не только Фортуну, но и вообще любой генератор случайных чисел, использующий дополнительные источники энтропии.
Я бы вообще не стал поточные использовать, на примере того же RC4 все вскрывали на раз при дурной реализации криптосистемы. И даже без ключа.
Есть хорошие поточные шифры, тот же HC-128 например, и вообще все финалисты проекта estream. У них своя ниша, надо просто знать что где использовать
Несомненно! Мне поточные кажутся более чувствительными к косякам их использования. Да и привык уже к AES.
AES (да и любой другой блочный шифр) в режиме CTR становится поточным (:
И я все-таки не понял, почему хэши не финализируются. При финализации добавляется длина данных и куча нулей, вряд ли это существенно испортит качество хэша. Единственный довод, который вижу — уменьшение времени выполнения.
Шифрование блочным шифром постоянно увеличивающегося счетчика — основная часть CTR-режима работы блочного шифра.

У меня возника идея: а зачем пулы, зачем усложнять? Берем какой-то даже поганый источник энтропии, хоть бы и системное время. Хэшируем, и используем как ключ для того же AES в том-же CTR-режиме. В отдельном потоке он будет с какой-то периодичностью лопатить, сохраняя последний блок. Как только приходит запрос — отдаем последний сохраненный блок, если не хватило — генерим следующий блок. Запросы на случайные данные будут приходить в случайные моменты времени, то есть чтобы их «угадать» придется от души попроматывать AES-CTR. Умножаем количество проматываний на число «разумных» с точки зрения атакующего значений системного времени при инициализации и получаем очень большое число :-) Дополнительно можно на каждом n-ном проходе шифра ксорить ключ с предыдущим результатом работы шифра и генерить новый блок для выдачи наружу.
Хэши финализируются когда приходит их время, т.е. когда мы сливаем пулы во внутренний генератор. После этого накапливают энтропию заного
Внутреннее состояние хэша != хэш. Там же внутри может быть все что угодно в каком угодно виде. Ну и после того как мы отдали энтропию генератору, она в этом пуле больше не имеет смысла, так что финализация тут само то)
Как делается финализация в MD5 и ripeMD128: к данным подмешивается длина данных и куча нулей, причем при помощи HashUpdate, который же применяется для хэширования самих данных. Потом в ripeMD128 внутреннее состояние выплевывается в результат, БЕЗ преобразований, так что состояние хэша и есть хэш. Я уверен, что в MD5/SHA1 и других ripe-хэшах все делается также.
Видимо, потому что источник энтропии может оказаться слишком поганым, в результате чего хакеру окажется слишком легко угадать ключ. А дальше он может взять один сгенерённый блок, расшифровать его всеми ключами, которые он посчитает наиболее вероятными, и таким образом получить набор возможных значений счётчика. Инкрементируя эти значения счётчика и зашифровывая их соответствующими им ключами он получит набор следующих блоков «случайной» последовательности, среди которых с большой вероятностью окажется правильный (если разом было запрошено больше одного блока данных). Таким образом он узнаёт ваш ключ.
Дальше аналогичным образом имея i-ый блок он сможет узнать соответствующее ему значение счётчика и восстановить i+1, i+2,… блоки, если они были запрошены разом. Причём скорость восстановления блоков, запрошенных подряд, будет такой же, как и скорость их генерации. Если они были запрошены с небольшим интервалом, то он может поперебирать счётчик от полученного значения.
На солнечном берегу моря где-нибудь в районе диких пляжей Бали, установить устройство, оцифровывающее выход с очень чувствительного микрофона.

А если вместо солнца будет идти дождь?
К вашему сведению, микрофон, даже очень чувствительный, не реагирует на солнце (по крайней мере на расстоянии 1 а. е.). А шумный дождь только повысит энтропию.
Может не по теме, но когда в университете я изучал c++ — нам преподаватель показал как генерировать случайное число. Сам способ уже не помню, но смысл был в том, что число было random'ное, но одинаковое все время — меня это сильно напрягало.
НЛО прилетело и опубликовало эту надпись здесь
Скорее всего оно просто было инициализировано одним и тем же сидом. Помню в Бейсике рандом выдавал случайные числа, а в Паскале каждый раз одну и ту же последовательность. Потом выяснил, что нужно вызывать randomize для инициализации с другим сидом (подозреваю что от системного времени, но не уверен).
В том Бэйсике, на котором писал я, без строчки «RANDOMIZE TIMER» случайные числа тоже были каждый раз одни и те же.
Запускаем отдельный поток, в котором в бесконечном цикле инкрементим целочисленную переменную
Раз в миллисекунду смотрим из другого потока на её последний бит и сохраняем (не мешая ей инкрементиться)


Столкнулся, как то с тем, что не могу получить случайного числа, правда не на компьютере а на контроллере: два одинаковых контроллера запитанных от одного источника с большой вероятностью генерировали одинаковое число :)
Я пытался добиться, что бы сетевые адреса у них были уникальными. Что я только не предпринимал, считал микросекунды до первого полученного байта + значение байта — все оказывалось детерминированным: несколько контроллеров связанные rs485 вели себя одинаково, и у с большой вероятностью всех оказывались одинаковые адреса ;)
Генератор эти все байтики берет, туда же подмешивает текущий свой ключ шифрования, тоже всё хэширует
А подмешивает он просто по очереди скармливая все эти байты хэшу?
Подмешивание информации из пулов запускается только по набору 64 байт первым пулом? Другие пулы/события в этом не участвуют?
да, срабатывание процедуры reseed происходит только когда у первого накопилось столько, сколько нужно. И про подмешивание тоже вы правильно сказали.
Сегодня в голову пришла мысль, что в качестве генератора случайных чисел можно использовать убитую в ноль флешку, у которой сыпется память из-за очень большого колличества перезаписей… Записываем на флешку псевдослучайную последовательность чисел, а считываем уже случайную…
Надо будет эксперимент провести… как раз нарисовался образец…
Эту флэшку надо всегда таскать с собой, к тому же нет гарантии, что она в один прекрасный момент не начнет выдавать поток из единиц…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.