Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Есть еще вариант.
И выкладывать эти данные в сеть. Их может использовать любой желающих.
На солнечном берегу моря где-нибудь в районе диких пляжей Бали, установить устройство, оцифровывающее выход с очень чувствительного микрофона.
И выкладывать эти данные в сеть. Их может использовать любой желающих.
такое уже есть www.random.org/
> На солнечном берегу моря где-нибудь в районе диких пляжей Бали, установить устройство, оцифровывающее выход с очень чувствительного микрофона.
А потом некий параноик запишет пару лет этого шума, проанализирует — и обнаружит, что он с точностью 99.9% представляет собой сумму каких-нибудь трехсот периодических функций.
А потом некий параноик запишет пару лет этого шума, проанализирует — и обнаружит, что он с точностью 99.9% представляет собой сумму каких-нибудь трехсот периодических функций.
До тех пор, пока сайт, выкладывающий данные, не окажется скомпрометирован и не начнет выкладывать данные, нужные Большому Брату.
Если открыть эти данные, число перестанет быть случайным, т.к. известно время запроса.
Спасибо за интересную статью.
У меня вопрос появился. Так как при накоплении достаточной энтропии происходит постоянное обновление внутреннего ключа, значит если скормишь один и тот же seed получатся разные последовательности? Получается fortuna нельзя использовать в качестве классического поточного шифра?
У меня вопрос появился. Так как при накоплении достаточной энтропии происходит постоянное обновление внутреннего ключа, значит если скормишь один и тот же seed получатся разные последовательности? Получается fortuna нельзя использовать в качестве классического поточного шифра?
И не только Фортуну, но и вообще любой генератор случайных чисел, использующий дополнительные источники энтропии.
Я бы вообще не стал поточные использовать, на примере того же RC4 все вскрывали на раз при дурной реализации криптосистемы. И даже без ключа.
И я все-таки не понял, почему хэши не финализируются. При финализации добавляется длина данных и куча нулей, вряд ли это существенно испортит качество хэша. Единственный довод, который вижу — уменьшение времени выполнения.
Шифрование блочным шифром постоянно увеличивающегося счетчика — основная часть CTR-режима работы блочного шифра.
У меня возника идея: а зачем пулы, зачем усложнять? Берем какой-то даже поганый источник энтропии, хоть бы и системное время. Хэшируем, и используем как ключ для того же AES в том-же CTR-режиме. В отдельном потоке он будет с какой-то периодичностью лопатить, сохраняя последний блок. Как только приходит запрос — отдаем последний сохраненный блок, если не хватило — генерим следующий блок. Запросы на случайные данные будут приходить в случайные моменты времени, то есть чтобы их «угадать» придется от души попроматывать AES-CTR. Умножаем количество проматываний на число «разумных» с точки зрения атакующего значений системного времени при инициализации и получаем очень большое число :-) Дополнительно можно на каждом n-ном проходе шифра ксорить ключ с предыдущим результатом работы шифра и генерить новый блок для выдачи наружу.
Шифрование блочным шифром постоянно увеличивающегося счетчика — основная часть CTR-режима работы блочного шифра.
У меня возника идея: а зачем пулы, зачем усложнять? Берем какой-то даже поганый источник энтропии, хоть бы и системное время. Хэшируем, и используем как ключ для того же AES в том-же CTR-режиме. В отдельном потоке он будет с какой-то периодичностью лопатить, сохраняя последний блок. Как только приходит запрос — отдаем последний сохраненный блок, если не хватило — генерим следующий блок. Запросы на случайные данные будут приходить в случайные моменты времени, то есть чтобы их «угадать» придется от души попроматывать AES-CTR. Умножаем количество проматываний на число «разумных» с точки зрения атакующего значений системного времени при инициализации и получаем очень большое число :-) Дополнительно можно на каждом n-ном проходе шифра ксорить ключ с предыдущим результатом работы шифра и генерить новый блок для выдачи наружу.
Хэши финализируются когда приходит их время, т.е. когда мы сливаем пулы во внутренний генератор. После этого накапливают энтропию заного
Хм… Ну ладно. Финализация, IMHO, там тоже не нужна :-)
Внутреннее состояние хэша != хэш. Там же внутри может быть все что угодно в каком угодно виде. Ну и после того как мы отдали энтропию генератору, она в этом пуле больше не имеет смысла, так что финализация тут само то)
Как делается финализация в MD5 и ripeMD128: к данным подмешивается длина данных и куча нулей, причем при помощи HashUpdate, который же применяется для хэширования самих данных. Потом в ripeMD128 внутреннее состояние выплевывается в результат, БЕЗ преобразований, так что состояние хэша и есть хэш. Я уверен, что в MD5/SHA1 и других ripe-хэшах все делается также.
Благодаря этим нулям и отсутствию преобразования, кстати, md5 сотоварищи уязвимы к length extension attack
А SHA-3 нет ) и там всё по другому
А SHA-3 нет ) и там всё по другому
Заново :)
Видимо, потому что источник энтропии может оказаться слишком поганым, в результате чего хакеру окажется слишком легко угадать ключ. А дальше он может взять один сгенерённый блок, расшифровать его всеми ключами, которые он посчитает наиболее вероятными, и таким образом получить набор возможных значений счётчика. Инкрементируя эти значения счётчика и зашифровывая их соответствующими им ключами он получит набор следующих блоков «случайной» последовательности, среди которых с большой вероятностью окажется правильный (если разом было запрошено больше одного блока данных). Таким образом он узнаёт ваш ключ.
Дальше аналогичным образом имея i-ый блок он сможет узнать соответствующее ему значение счётчика и восстановить i+1, i+2,… блоки, если они были запрошены разом. Причём скорость восстановления блоков, запрошенных подряд, будет такой же, как и скорость их генерации. Если они были запрошены с небольшим интервалом, то он может поперебирать счётчик от полученного значения.
Дальше аналогичным образом имея i-ый блок он сможет узнать соответствующее ему значение счётчика и восстановить i+1, i+2,… блоки, если они были запрошены разом. Причём скорость восстановления блоков, запрошенных подряд, будет такой же, как и скорость их генерации. Если они были запрошены с небольшим интервалом, то он может поперебирать счётчик от полученного значения.
На солнечном берегу моря где-нибудь в районе диких пляжей Бали, установить устройство, оцифровывающее выход с очень чувствительного микрофона.
А если вместо солнца будет идти дождь?
Может не по теме, но когда в университете я изучал c++ — нам преподаватель показал как генерировать случайное число. Сам способ уже не помню, но смысл был в том, что число было random'ное, но одинаковое все время — меня это сильно напрягало.
Скорее всего это был какой-то из стандартных детерменированных генераторов псевдослучайных чисел. Может быть, линейный конгруэнтный метод.
способ был такой
int getRandomNumber() {
return 4;
}
Скорее всего оно просто было инициализировано одним и тем же сидом. Помню в Бейсике рандом выдавал случайные числа, а в Паскале каждый раз одну и ту же последовательность. Потом выяснил, что нужно вызывать randomize для инициализации с другим сидом (подозреваю что от системного времени, но не уверен).
Запускаем отдельный поток, в котором в бесконечном цикле инкрементим целочисленную переменную
Раз в миллисекунду смотрим из другого потока на её последний бит и сохраняем (не мешая ей инкрементиться)
Столкнулся, как то с тем, что не могу получить случайного числа, правда не на компьютере а на контроллере: два одинаковых контроллера запитанных от одного источника с большой вероятностью генерировали одинаковое число :)
Я пытался добиться, что бы сетевые адреса у них были уникальными. Что я только не предпринимал, считал микросекунды до первого полученного байта + значение байта — все оказывалось детерминированным: несколько контроллеров связанные rs485 вели себя одинаково, и у с большой вероятностью всех оказывались одинаковые адреса ;)
Генератор эти все байтики берет, туда же подмешивает текущий свой ключ шифрования, тоже всё хэшируетА подмешивает он просто по очереди скармливая все эти байты хэшу?
Подмешивание информации из пулов запускается только по набору 64 байт первым пулом? Другие пулы/события в этом не участвуют?
Интересная статья и написано неплохо.
Спасибо!
Спасибо!
Сегодня в голову пришла мысль, что в качестве генератора случайных чисел можно использовать убитую в ноль флешку, у которой сыпется память из-за очень большого колличества перезаписей… Записываем на флешку псевдослучайную последовательность чисел, а считываем уже случайную…
Надо будет эксперимент провести… как раз нарисовался образец…
Надо будет эксперимент провести… как раз нарисовался образец…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Fortuna: генератор случайных чисел для параноиков