
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
03.01.2013, 16:27:41
|
|||
|---|---|---|---|
случайные числа - поставляемые от ОС, от пользователей. Недостатки SecureRandom |
|||
|
#18+
Всех с Новым Годом! У меня есть целый набор вопросов по генерации криптографически стойких случайных чисел на Java. 1) Вопрос по инициализации объекта SecureRandom Согласно документации , вот такая инициализация объекта: SecureRandom random = SecureRandom.getInstance("SHA1PRNG"); описана так - "Generates a SecureRandom object that implements the specified Pseudo Random Number Generator (PRNG) algorithm. If the default provider package provides an implementation of the requested PRNG, an instance of SecureRandom containing that implementation is returned. If the PRNG is not available in the default package, other packages are searched." а такая: SecureRandom random = new SecureRandom(); вот так - "By using this constructor, the caller obtains a SecureRandom object containing the implementation from the highest-priority installed provider that has a SecureRandom implementation." Вопрос: Я правильно понял из описания пустого конструктора, что "highest-priority installed provider" может быть таким, что предоставляемый им генератор псевдо-случайных числе (PRNG), окажется SHA1, то есть, оба способа инициализации будут идентичны? Следует ли из этого, что вызов пустого конструктора, предоставляющего провайдер с наивысшим приоритетом, возможно выдаст мне более сильный ГПСЧ, чем заданный явно SHA1? И еще, согласно документации, оба этих вызова не обеспечеивают seed генератора, это происходит при первом вызове nextBytes(). А что лучше - самостоятельный seed(со сбором системной информации для энтропии) или лучше явно задать свое число в методе setSeed? Я так понял, что если задать свое seed-число, то не будет никакого сбора энтропии, а это хуже, но возможно я ошибаюсь, хотелось бы уточниться. 2) В java.security файле, расположенном в path_to_java/jre/lib/security, немного говорится об источниках случайных чисел: # Select the source of seed data for SecureRandom. By default an # attempt is made to use the entropy gathering device specified by # the securerandom.source property. If an exception occurs when # accessing the URL then the traditional system/thread activity # algorithm is used. # # On Solaris and Linux systems, if file:/dev/urandom is specified and it # exists, a special SecureRandom implementation is activated by default. # This "NativePRNG" reads random bytes directly from /dev/urandom. # # On Windows systems, the URLs file:/dev/random and file:/dev/urandom # enables use of the Microsoft CryptoAPI seed functionality. Вопрос: Насколько я понял из последнего абзаца, в случае Винды, независимо от выбора, random или urandom, все равно используется Microsoft CryptoAPI? 3) Для Windows OS в любом случае используется MS Crypto API(если ответ на вопрос №2=="да"), у него источник энтропии (по википедии) - Текущее время, размер жёсткого диска, размер свободной памяти, номер процесса и NETBIOS-имя компьютера. Я читал несколько статей, что Microsoft оставли бэкдоры для американских спецслужб, как раз там что-то связано с ГСЧ. Вопрос: Если даже бэкдоры есть, такие, которые связаны с предсказуемостью генератора случайных чисел, у меня же все равно есть уникальная энтропия, которую нельзя угадать? Или этот набор параметров легко перебрать? Типа варианты текущего времени, свободного пространства и так далее? Были ли в Вашей практике случаи, когда компетентные органы запрещали использовать сторонние криптографические решения в связи с вопросами безопасности? И еще, можно ли заставить этот SecureRandom в качестве источника для энтропии брать взаимодействие между потоками (как он по идее должен делать согласно вики), а не использовать виндовый АПИ, на который, как выясняется из пункта 2, он таки ссылается. А если даже можно заставить не использовать виндовый АПИ, достаточно ли хорошо взаимодействие между потоками как источник энтропии? 4) Если возникнет необходимость самому генерировать случайные числа - а мне надо 256 бит или 32 байта, я планирую написать десктоп приложение, выдающее случайное число, которое является интерпретацией действий пользователя. Например, разбить форму на 256 квадратов, каждый квадрат - число от о до 255, то есть один байт. 32 раза кликнет юзер - вот и получаю случайную последовательность. Вопрос - правилен ли такой подход, равномерно ли будут распределены числа? А вдруг юзер захочет 32 раза кликнуть один и тот же квадратик? как бороться с человеческим фактором? Думал, чтобы не мучить юзера многократными нажатиями, применить ту же идею с выбором квадратиков, только выбираться они будут при движении мыши. Но это точно не равномерное распрделение - потому что выбираться будут только соседние клетки, получится как бы тело змеи, лежащей на форме, то есть вероятность появления такого набора чисел, где есть несмежные квадратики равна 0. Какие есть предложения чтоб и равномерная была вероятность выбора и user-friendly было? 5) Самый важный вопрос: Углубляясь в эти дебри при решении задачи генерации 256 битного ключа, я опирался не на свои знания, а на опыт других разработчиков, поэтому так далеко зашел. а на самом деле моей первой мыслью было в цикле от 1 до 256 сгенерировать простым рандомом цифры, взять их по модулю два, получить нули и единицы и все. Потом уже узнал, что в криптографических целях такое вообше нельзя использовать типа предсказуемость, а если запустят на твоей машине криптоанализирующую программу, тогда вообще смерть. А вот я не понял, может кто-то на пальцах объяснить, почему это не безопасно? Чем лучше, например, последовательность, снятая с какого-то внешнего абсолютно рандомного датчика и последовательность, полученная простейшим рандомом, даже не секьюрным а утильным? Потому что во втором случае кто-то может наперед сказать, что да, у него там по любому будет X1, по модулю два это 0, а потом будет х2 - короче, злоумышленник сразу однозначно воостановить мою последовательность? Иле же так - так у него там по любому в начале или х1 или х2 или хn - всего например, миллиард вариантов. А если есть начало, псевдо-рандом восстанавливается однозначно и значит противник перебрет миллиарл варинтов и все. а если есть бэкдор или источник энтропии слаб, то та же проблема, только вариантов больше да? А если буду реальные природно-физические параметры брать, тогда даже зная один бит, никто не восстановит остальные, потому что нет формулы, как в случае примитивного рандома или нету варинтов угадать закономерность, как было бы в случае слабой энтропии. Я прав? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.01.2013, 17:12:44
|
|||
|---|---|---|---|
случайные числа - поставляемые от ОС, от пользователей. Недостатки SecureRandom |
|||
|
#18+
BaurzhanSИ еще, согласно документации, оба этих вызова не обеспечеивают seed генератора, это происходит при первом вызове nextBytes(). А что лучше - самостоятельный seed(со сбором системной информации для энтропии) или лучше явно задать свое число в методе setSeed? Я так понял, что естли задать свое seed-число, то не будет никакого сбора энтропии, а это хуже, но возможно я ошибаюсь, хотелось бы уточниться.Спасибо. Ну нифигаж-себе ты букв написал! Ну вобщем seed - это некое начальное состояние автомата генератора СЧ. Если его инициализировать одинаково на двух раб.станциях - то мы получим две одинаковые последовательности. Это еще не взлом и не атака но уже повод пристально посмотреть на безопасность. Поэтому его конечно-же лучше инициализировать. За инсточник энтропии к seed можно брать текущее количество милисекунд например или попросить пользователя поелозить мышкой по экрану и собрав координаты перемещения - сгенерировать серию битов. Если текущее состояние автомата сохранять на диск перед shutdown-ом и при загрузке снова устанавливать seed-ом то мы получим хранимый длительно и бесконечно-долгоиграющий генератор СЧ без попыток повторной инициализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=59&tablet=1&tid=2130255]: |
0ms |
get settings: |
8ms |
get forum list: |
24ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
49ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 316ms |
| total: | 483ms |

| 0 / 0 |
