Здравствуйте, netch80, Вы писали:
A>>Кстати, написать реализацию вычисления случайных чисел по времени задержки нажатия на клавиши — задачка не такая простая как кажется. A>>Главная засада там — что стандартный опрос клавиш идёт по системному таймеру с фиксированным(!) интервалом.
N>Ну вообще-то, если речь о клавиатуре типичного современного PC, там нет никакого "опроса клавиш по таймеру" (это Вы в лучшем случае начитались Jourdain'а).
Да, согласен, не совсем точно выразился. Имелось ввиду, что, по результатам анализа, события keydown приходят
в приложение СТРОГО в моменты времени вида t = t0 + k*T, где k — целое, а T — довольно большой фиксированный период (например, на
компьютере, с которого я сейчас пишу, T=15.6 миллисекунд).
С чем именно это связано — с таймером внутри клавиатуры, с обработкой прерываний, с планировщиком задач или ещё с чем-либо — по сути не важно. Главное — что эти числа очень далеки от случайных и "выковыривать" из них энтропию надо очень аккуратно
Здравствуйте, EmmGold, Вы писали:
EG>существуют тесты AES, NIST и т.д. В эллиптической криптографии генератор случайных чисел должен выдать числа случайным образом, но при этом равномерно распределённые по заданной зоне.
Это всего лишь вопрос вероятностей. Если генератор выдал последовательность из 100 единиц подряд, и мы ее обозвали негодной, то с вероятностью 1/(2^100) мы отбросили хороший генератор, а с вероятностью 1 — 1/(2^100) забраковали сбойнувшую аппаратуру или глючную программу. При таких перекосах лучше ошибиться в безопасную сторону.
Здравствуйте, andy1618, Вы писали:
A>>>Кстати, написать реализацию вычисления случайных чисел по времени задержки нажатия на клавиши — задачка не такая простая как кажется. A>>>Главная засада там — что стандартный опрос клавиш идёт по системному таймеру с фиксированным(!) интервалом. N>>Ну вообще-то, если речь о клавиатуре типичного современного PC, там нет никакого "опроса клавиш по таймеру" (это Вы в лучшем случае начитались Jourdain'а).
A>Да, согласен, не совсем точно выразился. Имелось ввиду, что, по результатам анализа, события keydown приходят A>в приложение СТРОГО в моменты времени вида t = t0 + k*T, где k — целое, а T — довольно большой фиксированный период (например, на A>компьютере, с которого я сейчас пишу, T=15.6 миллисекунд). A>С чем именно это связано — с таймером внутри клавиатуры, с обработкой прерываний, с планировщиком задач или ещё с чем-либо — по сути не важно. Главное — что эти числа очень далеки от случайных и "выковыривать" из них энтропию надо очень аккуратно :)
Это скорее всего таки длительность цикла опроса в самой клавиатуре (а не в компьютере). У него действительно цикл опроса, и от этого никуда не деться. (В предыдущем замечании я был не совсем корректен в формулировках — отсутствие опроса факт именно PC, а не внешней стороны.)
Другой вопрос — насколько точно вы меряете момент вхождения в обработчик прерывания. Если это точность до миллисекунд или даже десятков микросекунд, там значения могут соответствовать данной формуле. Если снимаются с большей точностью (например, через счётчик TSR), то там начинают влиять, например, задержки чтения обработчика в кэш, а это вносит существенное шатание в младшие биты и позволяет получать из них прикидку на случайность. Осталось эту случайность правильно применить.
Здравствуйте, ДимДимыч, Вы писали: MS>>Меня вообще удивляет — чего может быть проще встроить в проц один-единственный стабилитрон и снимать с него шум?! ДД>Да есть такое: http://cateee.net/lkddb/web-lkddb/HW_RANDOM.html.
Из текста не совсем понял — оно при наличии используется, например, в /dev/(u)random? Или надо самому что-то делать/настраивать?
MC>Из текста не совсем понял — оно при наличии используется, например, в /dev/(u)random? Или надо самому что-то делать/настраивать?
скажем, в ядре нетбсд в пул энтропии /dev/*random автоматически подмешиваются данные из разных источников -- сеть, диски, и при наличии хардварный генератор. Плюс с помощью rndctl можно более тоноко управлять источниками случайности.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
